Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-IDS
[Top] [All Lists]

RE: IDS alerts / second - Correlation - Virtualization

Subject: RE: IDS alerts / second - Correlation - Virtualization
Date: Mon, 25 Jul 2005 17:34:55 -0400
David writes: "You have to detect before you can block."

While I agree that this is generally true in practice, it is not
required to be true. I believe that SYN-cookies are a good example of
attack protection (prevention?) prior to detection. If the IPS is an
inline product with the capability to potentially modify (not just drop)
any packet on the wire, a whole new world of possibilities opens up
beyond "inspect and drop".

Paul

-----Original Message-----
From: Swift, David [mailto:dswift@ipolicynetworks.com] 
Sent: Sunday, July 24, 2005 4:31 PM
To: Frank Knobbe; Nathan Davidson
Cc: focus-ids@securityfocus.com
Subject: RE: IDS alerts / second - Correlation - Virtualization


Actually, I disagree with the restated number of alerts (though a common
scale was not used).

By nature, any IPS has to do IDS first. 
You have to detect before you can block.
Therefore the number of IDS events will dramatically exceed the number
of IPS events. IPS will always be a subset of IDS.

Also, please note than many vendors (iPolicy included), are using
correlation tools to tune the system to the deployed network.

We work with EEye's Retina product. Retina scans the internal hosts (by
IP), and creates a database of OS, Application and Ports that are open
on the given network. 

Then the data is fed back into the IPS engine and Firewall to
intelligently turn on signatures to block events that the protected
network is vulnerable to, firewall unwanted ports, and ideally to turn
off alerting for events the protected network is not vulnerable to.

With virtualized products like the iPolicy Intrusion Prevention
Firewall, a security domain with policies for each type of network
(Windows, Unix, Mac...), can be created with different applied
IDS/IPS/FW rules on the same box based on the internal network to be
protected in order to reduce the number of false positives in IDS and
increase IPS effectiveness.

David Swift   Sr. Systems Engineer   dswift@ipolicynet.com
CISSP, MCSE, MCNE, CCNA, AIX-CSA, SUN-CSA

-----Original Message-----
From: Frank Knobbe [mailto:frank@knobbe.us] 
Sent: Friday, July 22, 2005 4:39 PM
To: Nathan Davidson
Cc: focus-ids@securityfocus.com
Subject: RE: IDS evaluations procedures

On Sat, 2005-07-16 at 12:42 -0400, Nathan Davidson wrote:
To make things easier to compare let us say that the IPS and IDS have 
the SAME signatures/policy and they both identify all of the malicious
traffic:
 
The IPS will create 10 alerts/sec
The IDS will create 100 alerts/sec

Uhm... then the IDS is not configured properly.

IPSes seem to filter proactively, that means based on assumptions. It
assumes that your server is vulnerable against xyz and blocks it. But
the server doesn't have to be vulnerable.

You can deploy an IDS as an ADS, that is, Attack Detection System. As
such it would alert on every xyz packet that look suspicious and which
the IDS thinks may cause harm to your server.

But you can also deploy an IDS as an ...well... Intrusion Detection
System. Configured like that, it doesn't make assumptions and doesn't
care if it sees xyz hitting the server. It cares what the server
responds with to xyz. If it detects an abnormal response, or outright
hostile traffic (i.e. signature of a botnet c&c channel join), then it
issues an alert, and only then.

Given that, the math is as follows:

ADS: 100 alerts /sec
IPS: 10 alerts /sec
IDS: 1 alert /incident

I think the IDS has a much higher security ROI (oops, I said the evil
word) than an IPS.

The IPS is a broad-sword. The IDS, properly deploy and managed, is a
sensitive detector, not a noisy alarm bell. It doesn't alert on every
thrust of a sword, it only alerts when you bleed.

Regards,
Frank

PS: I sometimes wonder if the I-have-more-alerts-than-you-stick-waving
in the IDS market contributed to the misuse of IDS systems....

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708

to learn more.
------------------------------------------------------------------------


------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>