IDS vs. IPS deployment feedback

[Sec urity]

I've lurked and watched as some have struggled to put out FUD that is
absurd at best. I feel it appropriate to to respond and I hope there are
no objections to me summarizing and replying in a single mail. WARNING
it is long as a result.

On Mar 30 @ 11:30 it was stated:

"Proxy firewalls make up a small (and shrinking) percentage of the
market of firewalls. And having worked with over 500 different
companies, my experience is that proxy-based firewalls are rarely
deployed in the manner you describe."

While I certainly appreciate the perspective I must humbly disagree. A
proxy based firewall is not only far superior to the stateful firewalls
that exist today, they are aptly suited for the job. A properly
implemented proxy will beat out every stateful firewall in the market
hands down in a security context.

It was later stated in the same paragraph:

"The default deny from unknown or un allowed protocols is almost ALWAYS
turned off because it breaks some important businesses system that was
poorly coded. Furthermore, a proxy validating protocols still cannot
stop a lot of exploits. Plenty of exploits live quite comfortably inside
the RFC-specs for a protocol. And in this case, your proxy-firewall
would do nothing to stop them. "

This is wholly inaccurate as it relates to technology that was available
in the late 90's and even more inaccurate today. Check Point was capable
of blocking CodeRed when it happened if configured properly. This with
Check Point generally being considered a stateful firewall even though
it is far more capable than the designation implies. Every properly
implemented proxy could and does do the same...

It has been my experience, that by and large, the failure is not in the
technology but in the company's choice of technology, choice of product,
available budget, and choice of trusted advisers.

still later in the same mail it is stated:

"Most firewalls have no insight into application-layer content. And most
exploits are application-layer exploits. This isn't just some insane
idea, it's a fact. You can ignore this and tell yourself 10000 times you
don't need no stinkin' IPS, but the cold hard stiff fact is: firewalls
are not sufficient protection for most organizations. "

Which is perhaps accurate of some of the firewalls commonly deployed
today. An example is that a pix will not get you blocking on application
data, this is perfectly acceptable since it should never be deployed
where there is need for that. It is not accurate to state that the IPS
offers any _application_ awareness or state tracking. I am only aware of
two commonly available IPS technologies that can even come close to
ad-hoc application state awareness, without writing code for a
proprietary closed product. Those two IPS technologies are NFR and Snort.

If you want to eliminate NFR and Snort-based products from the
comparison, then you have an IPS which is as ignorant and incapable of
tracking ad-hoc application state as any firewall could be. These IPS
devices are essentially firewalls with default allow policies and fast
regex engines with drop capability hooked in.

On April 5th @ 3:19pm it is stated:

"Dropped packets happen when people try to ram 1000mbps through an IPS
rated at 200Mbps."

Perhaps this is semantics and I am happy to leave it as such but I must
express an opinion.

Any device when pushed beyond its means _will_ come to it's knees. A
proper firewall or IPS should prevent this by design and as a result
there would be no dropped packets, only packets it refused to service.

If a firewall or IPS drops a packet when operating within spec, it
should be because of a device decision as a result of a policy decision
actively made by the administrator of that device. This is completely
different than the IPS refusing to accept the packet in the first place.
Lets not confuse preservation with performance as advertised.

It is later stated in this mail

"Its impossible to defend 100% against the unknown. You HAVE to make
some type of educated guesses as what is PROBABLE and defend against
that which is MOST PROBABLE. And that is exactly what and IPS does. It
can look at a stream and say: "its HIGHLY unlikely that this gargantuan
binary package in the middle of a ISAPI call is normal, so I am going to
block it."

Or it could be a dcom transfer of brain scans by a custom application
designed to enable remote diagnosis of tumors...

While we agree that it is impossible to have 100% perfection and defend
against everything. We do not agree that an IPS that thinks things are
unlikely and should not occur is the right approach. If I had a dollar
for every "unlikely" thing I've seen happen on a network I would
probably own Microsoft.

and then later:

"When you clear away the hype and FUD, the value of an IPS obvious. You
can lower risk by knowing that set number of vulnerabilities are
blocked, thus reducing the number of incidents that need to be
investigated. "

This of course assumes that the IPS has an opportunity to block the
exploitation at a chokepoint. An IPS is the perfect tool for preventing
attacks you already knew about as they traverse a chokepoint in the
network, its value is clearly obvious in that regard. This does not
translate into reducing risk. This translates into reducing expense as a
result of having to respond to the successful exercising of that risk.

On the 7th of Arpil it is then stated:

"Your 500 number is wrong. When you get into the leading commercial IPSs
(TippingPoint, ISS, Juniper, McAfee) these products on average have
2000-3000 signatures. However, in some technologies, one signature
handles an entire class of vulnerabilities. Where Snort needs multiple
signatures for the same vulnerability, ISS can protect against the
vulnerability with 1 signature. TP is the same. I don't know Juniper and
McAfee as well, but I suspect they are similar. "

I must ask, how is it we are to know exactly how many signatures ISS has
to detect something? That there is but one GUI line item does not mean
there are not 200 supporting checks behind it. Same goes for
TippingPoint, Juniper, McAfee... If it is not open and readily available
for independent review it is but the word of the vendor. How do you even
know what the actual triggering conditions are?

Why is it important to know exactly what the conditions are? The answer
is pretty simple. Without the real information and data we have to do an
actual forensics analysis to determine if something was compromised.
This is because we have no context or meaningful audit of what really
happened when using these closed systems.

In the non attack category we get into the case where someone calls you
and says "My widget maker doesn't work any more" and you then have to go
look for the IP involved and tell them you have no events for it.
Fortunately, the networking team placed a sniffer on the link to
diagnose it for you and it turns out that the IPS device was blocking
some multicast state synchronization and you didn't even have a packet
or the real detection method used to compare and refine for the target
network.

and then in that same mail it is stated:

"Snort also has a lot of unique signatures that people have designed for
highly specialized purposes. That is definitely a benefit to some
organizations. But, those signatures are only useful in those unique
situations. And all the commercial products support custom signatures -
so you can do the same thing for your TP or ISS box."

Interesting opinion. Try to write a set of detection signatures for
those closed products that will track a valid login to a custom
application and then the exploitation of an vulnerability. You cannot do
it because they do not allow the tracking of application state in the
signature engines. The ability to create a regex in these products is
hardly the same capability you get in an advanced rules engine like
Snort. Try writing a signature for some custom protocol that rides over
TCP and looks a lot like telnet but is not and does not conform to an
RFC in the slightest.

It is later stated in that same mail:

"Furthermore, Snort rules are developed by volunteers (or Sourcefire).
As such, SNORT is usually behind the curve on new signatures. ISS, for
example, does their own independent security research an has signatures
to protect against things that Snort people don't even know about. Other
vendors buy exploits from the hacker market - again giving them access
to vulnerabilities long before it hits the public and subsequently the
people who develop SNORT signatures. "

Lets clarify that a little and please do not confuse professionally
developed detection with the rules put out by the hobbyists in the
market. Snort rules can be written by anyone and as a result there are
many organizations and people that write rules. The premier organization
that writes rules is Sourcefire. Sourcefire purchases information from
the various vulnerability information warehouses like every other vendor
does and has a dedicated research team that is toe to toe if not better
than the other groups out there. That Sourcefire is the premier writer
of rules is no strange coincidence since Sourcefire also writes Snort
and focuses on detection of the exploitation of _vulnerabilities_ not
the transmission of _exploits_

Sourcefire is most definitely ahead of the curve and has detection out
before the threat. Snort by itself may be behind the curve if you choose
not to subscribe to the Sourcefire VRT updates and instead decide to
play the risk game. This is a decision that people are free to make and
often do. This is not a fault of Snort, the technology, community, or
companies that produce professional high quality rules for Snort. This
is a failure of the administrator and nothing you do with technology
will eliminate that failure.

It is later stated in this same mail:

"The 90% thing you're coming up with is just false. You're assuming that
all those signatures represent a serious attack. And you're also
assuming that quantity of signatures is the measure of effectiveness."

Is there an attack that is not serious? Is there a policy violation that
is not serious? Have you looked at the scope and depth of the rules
available for Snort? This statement is simply baseless FUD.

and then it is stated:

"A poorly maintained, tuned or implemented Snort sensor is just as
useless as a poorly maintained, tuned, or implemented ISS sensor."

We certainly agree here. Without maintenance all products are useless.

On April 7th at 12:05pm it is stated:

"I maintain my position that most businesses lack the analytical
capabilities to deploy resource intensive technologies (like SNORT).
Hence, commercial IPS that can filter off a set of known vulnerabilities
reduces the overall workload and offers a layer of protection."

Snort can just as easily filter off these attacks. When backed by a
capable company like Sourcefire the resource intensive challenge is also
significantly reduced. Automatic updates can even be configured to
maintain detection capabilities without ever touching the system.
Combine the detection with contextual awareness of RNA and you get
impact assessments that prioritize your efforts. Snort is but a piece of
the larger security puzzle and anyone that spends this much time trying
to discredit the technology is clearly feeling the pain of Snort.

It is then stated:

"Also, the majority of attacks in the wild are well-known and easily
detected and blocked."

This is completely subjective and I wish people would stop trying to
push an opinion on the market. What is a risk to one company may well be
a nuisance to another.

Looking back on some of the previous mails in this thread I have to ask.
Would any of those attacks happen to be considered one that is not serious?

And finally on April 10th at 3:54pm it is stated:

"Yes...SOURCEFIRE customers get those signatures early. They get handed
out to the Snort world well after the fact. SourceFire is a commercial
company and you must PAY to get their product."

Firstly, "Well after the fact" is only 5 days. You can also subscribe to
get the rules for Snort in real-time. I don't see how having to pay
matters since the alternatives are all commercial as well. If you have
the need for protection and not the budget then you can run Snort and
become a subscriber.

"In other words - Sourcefire is no different than TP, ISS or any other
commercial vendor in this regard. As such, we're all just selling what
we know."

Being a Sourcefire employee, major contributor to Snort, and general
gear head that likes to beat on these things I can definitely say that
Sourcefire and Snort are absolutely different than ISS or TP or any
other commercial vendor.

The next time anyone wants to get on the bandwagon and start throwing
FUD around I would like them to take a moment to realize that Snort is
deployed and runs in more networks than all of the other commercial
vendors combined.

Andrew Plato wrote:

> Yes...SOURCEFIRE customers get those signatures early. They get handed
> out to the Snort world well after the fact. SourceFire is a commercial
> company and you must PAY to get their product.
>
> In other words - Sourcefire is no different than TP, ISS or any other
> commercial vendor in this regard. As such, we're all just selling what
> we know.
>
> ___________________________________
> Andrew Plato, CISSP
> President/Principal Consultant
> Anitian Enterprise Security
>
>
>
> -----Original Message-----
> From: Richard Bejtlich [mailto:taosecurity@...]
> Sent: Monday, April 10, 2006 10:36 AM
> To: Andrew Plato
> Cc: Basgen, Brian; focus-ids@...
> Subject: Re: IDS vs. IPS deployment feedback
>
> You are not familiar with modern Snort signature development by the
> Sourcefire Vulnerability Research Team. See:
>
> http://www.sourcefire.com/services/sf_vrt.html
>
> For one example:
>
> http://www.sourcefire.com/news/press_releases/pr121504.html
> _________________________________________________
> NOTICE:
> This email may contain confidential information,
> and is for the sole use of the intended recipient.  
> If you are not the intended recipient, please reply
> to the message and inform the sender of the error
> and delete the email and any attachments from
> your computer.
> _________________________________________________
>
>
> ------------------------------------------------------------------------
> 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.
------------------------------------------------------------------------

[Palmer, Paul (ISSAtlanta)]

Matthew,

Matthew Watchinski wrote:

> You state that Snort uses 300 rules to cover one vulnerability while
> claiming that ISS uses 1.  While this my be true, it is also
irrelevant.

Andrew Plato was trying to make the point that you cannot judge the
completeness of coverage based solely upon signature count, since some
products use more than one signature for coverage. Brian Basgen then
asked for an example in which Snort used more signatures to provide
coverage than ISS did. So, I have to disagree. What I wrote was in
support of this dialogue and was completely relevant to the topic of the
thread.

That being said, it seems that to some degree you support Andrew's
position. That is, signature count is an irrelevant measure of
vulnerability coverage.

> What we do with our rules language, ISS does with their MSRPC / SMB
parsers.
> These parsers have just as many or more code paths to handle exactly
what
> the Snort rules are doing.

I agree. The parsers have as many or more code paths. However, I do not
agree that they handle exactly what the Snort rules are doing. In this
specific context of MSRPC and SMB, the parsers  are doing much more than
what the Snort rules are doing.

> It also covers a number of possible evasion techniques.
>
> 1. Bind padding
> 2. Alter Context
> 3. Write and Read ANDX
> 4. Unicode Non Unicode
> 5. Little endian big endian
> 6. etc...

> About the only thing it doesn't cover is SMB and DCERPC fragmentation,

> which will be available in snort 2.6.1.

I suspect that we strongly disagree on the efficacy of this coverage.

> >
> > It is interesting to note that once a proof of concept exploit
became
> > available, the 300 signatures disappeared and were replaced by a
small
> > number of signatures to just provide coverage for the known proof of

> > concept exploits.
>
> Incorrect. The initial set of rules included all of the potential
> connection methods that Microsoft stated the vulnerable service
> could bind to.  During the initial release, we chose to release
> rules for those connection methods even though our research did
> not agree.  After further research,  we were more confidant that
> Microsoft's initial announcement overstated the connection methods,
> and therefore reduced the ruleset to the appropriate connection
> methods.

I agree that I was incorrect with respect to the VRT rulesets. My facts
were derived from competitive research we had performed some number of
months ago. I believe the information came from examining the Bleeding
Snort rulebase. I just checked the latest VRT certified ruleset for
registered users. It does NOT appear that all of the rules were replaced
by a small number of rules for just proof of concept exploits. It shows
that there are still 256 rules for MS05-039.

> In the end it's all about methodology.  ISS puts all its logic
> into C modules, while Snort places its functionality in its rules
> language. ISS handles DCERPC/MSRPC/SMB in C modules that can't be
> modified by the user or easily validated, while Snort uses open
> rules and open code to handle the same problems.

Wow. Great marketing spin. However, if you create an SMB and MSRPC
preprocessor to handle the fragmentation issues in those protocols,
won't you have validated that ISS' decision to place significant parts
of its IP in C modules instead of rules was likely correct?

Paul

-----Original Message-----
From: Matthew Watchinski [mailto:mwatchinski@...]
Sent: Wednesday, April 12, 2006 6:06 PM
To: Palmer, Paul (ISSAtlanta)
Cc: Basgen, Brian; focus-ids@...
Subject: Re: IDS vs. IPS deployment feedback


Paul,

I am the Director of the Vulnerability Research Team at Sourcefire. This
puts me in a somewhat unique position to actually respond with facts to
the speculation below.

You state that Snort uses 300 rules to cover one vulnerability while
claiming that ISS uses 1.  While this my be true, it is also irrelevant.
What we do with our rules language, ISS does with their MSRPC / SMB
parsers.  These parsers have just as many or more code paths to handle
exactly what the Snort rules are doing.

In addition Snort's model of using rule-drive vulnerability base,
detection provides the end-user with the power to determine exactly what

they want to do and the ability to turn on and off individual
sub-sections of the detection to suit their networking environment.
Additionally you can see and modify any piece of this detection that one

sees necessary to modify, giving the end-user a very flexible solution
to the problem.

Additional Comments In-line

Palmer, Paul (ISSAtlanta) wrote:
> Brian,
>
> I work in ISS' research department. This puts me in a somewhat unique
> position to answer your question.
>
> One example is the signature coverage for MS05-039/CVE-2005-1983. When

> the vulnerability was initially announced, the SNORT community (I do
> not know which exact group created these signatures) added
> approximately 300 different signatures to provide vulnerability-based
> coverage for the vulnerability. That is to say, these were not 300
> different overlapping signatures from a variety of sources all
> designed to solve the same problem. These were a single group of 300
> signatures designed to work in concert to provide protection against
> unknown exploits (no known exploits existed at the time that these
> signatures were added.)


These 300 rules were created by the Sourcefire VRT and were added to
detect the possible attack vectors for MS05-039.  These rules are auto
generated by our MSRPC/DCERPC/SMB rule generator which understands and
creates rules for the following:

1. NETBIOS DCERPC NCADG-IP-UDP
2. NETBIOS DCERPC NCACN-IP-TCP
3. NETBIOS SMB DIRECT
4. NETBIOS SMB-DS
5. NETBIOS DCERPC NCACN-HTTP
6. NETBIOS DCERPC DIRECT
7. etc..

It also covers a number of possible evasion techniques.

1. Bind padding
2. Alter Context
3. Write and Read ANDX
4. Unicode Non Unicode
5. Little endian big endian
6. etc...

About the only thing it doesn't cover is SMB and DCERPC fragmentation,
which will be available in snort 2.6.1.

>
> The fact that 300 signatures were necessary was due to weaknesses of
> the SNORT engine itself (it doesn't have a proper MSRPC parser), not
> the research community. Even so, judging from what is lacking in the
> 300 signatures, it seems extremely likely that the SNORT research
> community is unaware of all of the different vectors through which the

> vulnerability can be exploited since they could have easily added
> coverage for these had they been aware of them. It also seems likely
> that the research community is unaware of all of the evasion
> techniques available via MSRPC and SMB as there are evasions for which

> I have never seen SNORT signature coverage.

Interesting.  Of course, there is no documentation in ISS's PAM
documentation about these additional evasion techniques. Your customers,
and the Internet as a whole might like to know about these evasions you
describe. Sounds like a good CanSec or BlackHat talk.

>
> It is interesting to note that once a proof of concept exploit became
> available, the 300 signatures disappeared and were replaced by a small

> number of signatures to just provide coverage for the known proof of
> concept exploits.

Incorrect. The initial set of rules included all of the potential
connection methods that Microsoft stated the vulnerable service could
bind to.  During the initial release, we chose to release rules for
those connection methods even though our research did not agree.  After
further research,  we were more confidant that Microsoft's initial
announcement overstated the connection methods, and therefore reduced
the ruleset to the appropriate connection methods.

>
> ISS, which has proper SMB and MSRPC parsers, needed to add only one
> signature to provide vulnerability-based coverage for the buffer
> overflow attack (there is another signature for a related, but
> different DoS-only vector). Other vendors vary in the number of
> distinct signatures they require for coverage. However, I have seen
> none that come close to the ~300 fielded by SNORT.
>
> Paul

In the end it's all about methodology.  ISS puts all its logic into C
modules, while Snort places its functionality in its rules language. ISS
handles DCERPC/MSRPC/SMB in C modules that can't be modified by the user
or easily validated, while Snort uses open rules and open code to handle
the same problems.

Thanks
Matthew Watchinski
Director, Vulnerability Research
Sourcefire, Inc.

>
> -----Original Message-----
> From: Basgen, Brian [mailto:bbasgen@...]
> Sent: Friday, April 07, 2006 12:28 PM
> To: focus-ids@...
> Subject: RE: IDS vs. IPS deployment feedback
>
>
> Andrew,
>
>
>>some technologies, one signature handles an entire class of
>
> vulnerabilities. Where Snort
>
>>needs multiple signatures for the same vulnerability, ISS can protect
>
> against the
>
>>vulnerability with 1 signature. TP is the same.
>
>  
>  Interesting. Can you show me an example of this? I'd like to
> understand the design differences that lead the snort signature base
> to be as ineffecient as you describe.
>
>
>>ISS, for example, does their own independent security research an has
>
> signatures to
>
>>protect against things that Snort people don't even know about.
>
>
>  I don't understand how this differs from the Sourcefire Vulnerability

> Research Team. Can you provide some details, specific examples, of
> where the Sourcefire VRT has failed and the ISS research has
> succeeded?
>
> ~~~~~~~~~~~~~~~~~~
> Brian Basgen
> IT Security Architect
> Pima Community College
>
> ----------------------------------------------------------------------
> --
> 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.
------------------------------------------------------------------------

[Frank Knobbe]

On Tue, 2006-03-21 at 11:58 +0000, nightelfhunter@... wrote:
> I to a degree tend to sympathise with many CSO/CTO's in our industry
> today. They have the tough job of managing complex information systems
> added to that the responsibility of ensuring that these systems run
> seamlessly and without hinderance....

Sorry for the late reply, but this comment struck a chord. I think
CSO/CTO folks are partly at fault. Part of their job should be to
decomplexify (or call it simplify if you like ;) todays information
systems.

It seems to me that the whole industry is suffering from feature and
complexity bloat, much to the expense of security and productivity. It
should be a goal to a) realize that bloat exists, and b) take measures
to simplify the IT infrastructure/operations. You *can* achieve the same
results with a less complex system if you just try. The problem is that
most "applications" these days are far more complex and bloated than
what they need to be. Be carefully selecting and redesigning IT
infrastructure and operations/use, a lot of the current problems in IT
can be eliminated.

Regards,
Frank


Musing: The avalanche is already in progress. Folks should try to move
to the sidelines instead of staying ahead of the flow... it will catch
up with you eventually.

--
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

[Stefano Zanero]

Andrew Plato wrote:

> experience. Dropped packets happen when people try to ram 1000mbps
> through an IPS rated at 200Mbps.

Really ?

And how is the thing "rated" in the first place ?

Throughput depends on service time. Service time in a router is of very
limited variability, in a firewall may very, in a complex thing such as
an IDS/IPS it varies wildly, depending on the traffic mix. So, you
should specify WHAT TRAFFIC the IPS is being validated and measured on.
Something that most companies won't do.

> They simply do not have the time or resources to baby an IDS and perform
> intricate security analysis.

And so they have the resources to put in-line an unknown device which
needs tuning and which could cut off, accidentally, customers from
revenue generating services ?

> And complex IDSs that generate 10000s
> of alerts and stop nothing are quickly ignored when the staff gets busy.

Instead, when each of those false alerts turns into a lost customer, no
one complains. That's right :)

> This is just false. Firewalls and IPS assume much different things. A
> firewall is a static set of rules that say what is allowed and what is
> not allowed. That's it.

A misuse-based IPS is exactly the same thing. There's actually no
difference.

> An IPS, on the other hand, lets everything through unless it does
> something that it knows is bad.

Aha ! GREEEEEEEEEAT IDEA !

One of the BESTEST in computer security !

BLACKLISTING !

Slide 1 of "Perimeter security 101" course: always begin from default
deny and WHITELIST. Look it up on the CISSP books, Andrew, it's in there
somewhere, I'm sure :)

> that is exactly what and IPS does. It can look at a stream and say: "its
> HIGHLY unlikely that this gargantuan binary package in the middle of a
> ISAPI call is normal, so I am going to block it."

This is what a good anomaly based, intelligent IPS would do.
Unfortunately, there's a shortage of good anomaly based IPS products out
there :)

Stefano

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Stefano Zanero]

Andrew Plato wrote:

> Furthermore, Snort rules are developed by volunteers (or Sourcefire). As
> such, SNORT is usually behind the curve on new signatures.

I suppose you have actual figures for this ? Because I'd have to claim
it FUD otherwise. Compare with the response time of commercial and open
source anti viruses, and you'll see that this claim is at best unproven.

> ISS, for
> example, does their own independent security research an has signatures
> to protect against things that Snort people don't even know about.

And I suppose people who work for Sourcefire, or people who contribute
rules to the Snort signatures base, don't do vulnerability research ?

I know that many researchers develop signatures along with their
advisory. We've seen that.

Are you implying that ISS knows about zero-day vulnerabilities it hasn't
alerted vendors to ? I think that ISS always claimed to be for
responsible disclosures of their findings. Has this changed, recently ?

> vendors buy exploits from the hacker market - again giving them access
> to vulnerabilities long before it hits the public

Same as above applies. Buying vulnerabilities and exploits and not
publishing them is highly unethical. I wouldn't buy anything from a
vendor who claimed to do that.

Besides, "good" zero days stay in the closet for a long time. They get
sold when they already leaked to the outer circles of the scene.

As far as the "who has the rules first", in fact, I remember Snort
implementing a way to import the so-advanced, bleeding-edge ISS rules...
oh wait, or was it the other way round ? :)

Stefano

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Biswas, Proneet]

Hi Brian,
Another good method to qualify a system would be to judge if a
particualr signature is targetting the exploit or the vulnerability
which the exploit is targetted for.
Example:
Lets take a simple buffer overflow case where a particular FTP user name
if more than 200 characters would allow user to execute code. The code
which would be executed would depend on the actual code which is passed
on after the buffer of 200 characters.

False negative side
----------------------
If the user has written specific signatures for the executabel shell
code, then the chances are his false positive is very low, but then
there are so many exploit code combinations, that he could miss out on
one of them and thus miss out an actual exploit. Tools like metasploit
allow you to test the combination of vulnerability plus payload to
detect what kind of IPS signature is impelmented.

False postive side
--------------------
If the user has written a singature to actually test the buffer
overflow, then the chances of his getting false negative are low as he
would catch all the buffer overflow cases irrespective of the executable
code. However, this would increase his false positive scenario as even
if the code after the 200 characters is not executable code, it would
still block or generate an alert as configured.


Thanks
Proneet Biswas.
-------------------------------------------------------------
I find that the harder I work, the more luck I seem to have


-----Original Message-----
From: Basgen, Brian [mailto:bbasgen@...]
Sent: Monday, April 10, 2006 3:10 PM
To: focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback


Paul,

 Thanks for your response. I'd love to hear you qualify differences a
bit more.

 Every IPS ships in "silver bullet" mode with a certain set of
recommended protections activated -- the understanding being that these
signatures have extremely low false positives. Yet, these IPS have a
larger signature base that, if enabled, can stop both threats and normal
traffic. Naturally, they aren't enabled because the product is, after
all, a silver bullet; like your ISS Proventia claims. ;)

 I think metrics would be interesting here -- whether numeric or
qualitative. You explained poor SMB and MSRPC parsers in snort, and that
is interesting data. While I'm interested in getting the details as to
where Snort is imperfect, I'm also interested in getting better
qualitative data on the IPS/IDS divide. How much can the IPS drop
without false positives, versus how much can an IDS detect (with, of
course, false positives). Put in another way, how many false negatives
can get through a default IPS?

~~~~~~~~~~~~~~~~~~
Brian Basgen
IT Security Architect
Pima Community College

-----Original Message-----
From: Palmer, Paul (ISSAtlanta) [mailto:PPalmer@...]
Sent: Monday, April 10, 2006 1:38 PM
To: Basgen, Brian; focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback

Brian,

I work in ISS' research department. This puts me in a somewhat unique
position to answer your question.

One example is the signature coverage for MS05-039/CVE-2005-1983. When
the vulnerability was initially announced, the SNORT community (I do not
know which exact group created these signatures) added approximately 300
different signatures to provide vulnerability-based coverage for the
vulnerability. That is to say, these were not 300 different overlapping
signatures from a variety of sources all designed to solve the same
problem. These were a single group of 300 signatures designed to work in
concert to provide protection against unknown exploits (no known
exploits existed at the time that these signatures were added.)

The fact that 300 signatures were necessary was due to weaknesses of the
SNORT engine itself (it doesn't have a proper MSRPC parser), not the
research community. Even so, judging from what is lacking in the 300
signatures, it seems extremely likely that the SNORT research community
is unaware of all of the different vectors through which the
vulnerability can be exploited since they could have easily added
coverage for these had they been aware of them. It also seems likely
that the research community is unaware of all of the evasion techniques
available via MSRPC and SMB as there are evasions for which I have never
seen SNORT signature coverage.

It is interesting to note that once a proof of concept exploit became
available, the 300 signatures disappeared and were replaced by a small
number of signatures to just provide coverage for the known proof of
concept exploits.

ISS, which has proper SMB and MSRPC parsers, needed to add only one
signature to provide vulnerability-based coverage for the buffer
overflow attack (there is another signature for a related, but different
DoS-only vector). Other vendors vary in the number of distinct
signatures they require for coverage. However, I have seen none that
come close to the ~300 fielded by SNORT.

Paul

-----Original Message-----
From: Basgen, Brian [mailto:bbasgen@...]
Sent: Friday, April 07, 2006 12:28 PM
To: focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback


Andrew,

>some technologies, one signature handles an entire class of
vulnerabilities. Where Snort
>needs multiple signatures for the same vulnerability, ISS can protect
against the
>vulnerability with 1 signature. TP is the same.
 
 Interesting. Can you show me an example of this? I'd like to understand
the design differences that lead the snort signature base to be as
ineffecient as you describe.

> ISS, for example, does their own independent security research an has
signatures to
> protect against things that Snort people don't even know about.

 I don't understand how this differs from the Sourcefire Vulnerability
Research Team. Can you provide some details, specific examples, of where
the Sourcefire VRT has failed and the ISS research has succeeded?

~~~~~~~~~~~~~~~~~~
Brian Basgen
IT Security Architect
Pima Community College

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Palmer, Paul (ISSAtlanta)]

Brian,

I cannot speak for other vendors, but I suspect that many of the vendors
share much of our experience on the topic of what to block and what not
to block by default. Here are a few of the criteria:

- ISS, like every vendor, have certain QA processes that they go through
to vet their "signatures" (ISS does not like to use the term signature
as people tend to incorrectly assume that our protection is based upon
simple strings or regular expressions). However, no amount of lab
testing and trial deployments can match the feedback you will get once
your signature is widely deployed. Corporate networks are a much
stranger place than you could ever possibly imagine. Therefore, we
prefer to recommend blocking for a signature after it has been in the
field for a month or two. Although false positives are an issue, ISS has
also discovered over time that at some locations routine use of a
vulnerability has become institutionalized. You never want to interfere
with a customer's network in your default configuration, so if there is
any doubt you do not recommend blocking.

- ISS also has anomaly based signatures. You can think of these as
having a signal to noise ratio. Indeed, many require customer tuning to
be truly effective. Therefore, these tend not to be candidates for
default blocking, but, nevertheless, are quite suitable for blocking
once tuned.

- ISS is getting more and more into "behavioral signatures". This is a
slight departure from our vulnerability based signatures as these
clearly trigger on any traffic attempting to exploit a specific
vulnerability. The behavioral signatures match on consistent elements of
malware that we see repeated regardless of the vulnerability exploited.
These require a lot of tweaking to get just right (several months from
deployment to blocking). However, they can be amazingly effective
against 0-days. Over the last year, Proventia has blocked approximately
90% of all of the 0-day viruses crossing the network using these
"signatures".

- ISS also provides some policy enforcement signatures. That is, we have
signatures that can be used to block peer to peer or instant messenger
traffic for example. Since customer policies vary widely, these are not
candidates for a default blocking policy.

- ISS provides a large number of audit signatures. These are very handy
when you need to collect a lot of forensics during an incident, but
generally blocking is a bad idea with these as they trigger on normal
traffic by design.

- In some cases, signatures are disabled by default (and therefore have
no blocking) for performance reasons. ISS has only a small number of
these. However, the design of some IDS and IPS systems causes them to
degrade significantly as you enable more signatures. For these vendors,
they must also choose to "retire" some older signatures to make room for
newer ones.

Let's skip talking about where Snort may be imperfect. I really am
uncomfortable publicly bashing other vendors and I already feel like I
have strayed a bit across that line in recent messages. I think this
list is at its best when it maintains a more positive note. There is no
one "complete" product in this industry currently. For example, I know
of many customers that have both ISS and Sourcefire products.

You ask how many false negatives can get through a default IPS
configuration? This varies tremendously between products in the
industry. This is a relevant question for ISS products given their
pedigree (ISS started as an IDS company). For us, it is currently very
small, although it did not start out that way. It is now easily less
than 10% (probably less than 1%). Since ISS made the transition to IPS
products, it has been a focus for us. With each content update we add
blocking to more signatures than there are new signatures in the update.
So, our percentage blocked increases with each update. With our focus on
false positive reduction and our focus on adding blocking to the
signatures where it will do the most good, the rate spread between those
signatures that block and those that do not is easily several orders of
magnitude. I know this to be true because I receive a summary report
every morning showing the trigger rates for all signatures from a
collection of special sensors placed throughout the Internet.

Even though I believe that ISS' numbers in this category are likely the
best in the industry, I would not be surprised if all of the IPS vendors
(that is, those companies whose primary source of income is from IPS
installations and not IDS installations) can also boast very good
numbers on this metric. The nature of the business drives them to
constantly reduce this number.

Paul

-----Original Message-----
From: Basgen, Brian [mailto:bbasgen@...]
Sent: Monday, April 10, 2006 6:10 PM
To: focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback


Paul,

 Thanks for your response. I'd love to hear you qualify differences a
bit more.

 Every IPS ships in "silver bullet" mode with a certain set of
recommended protections activated -- the understanding being that these
signatures have extremely low false positives. Yet, these IPS have a
larger signature base that, if enabled, can stop both threats and normal
traffic. Naturally, they aren't enabled because the product is, after
all, a silver bullet; like your ISS Proventia claims. ;)

 I think metrics would be interesting here -- whether numeric or
qualitative. You explained poor SMB and MSRPC parsers in snort, and that
is interesting data. While I'm interested in getting the details as to
where Snort is imperfect, I'm also interested in getting better
qualitative data on the IPS/IDS divide. How much can the IPS drop
without false positives, versus how much can an IDS detect (with, of
course, false positives). Put in another way, how many false negatives
can get through a default IPS?

~~~~~~~~~~~~~~~~~~
Brian Basgen
IT Security Architect
Pima Community College

-----Original Message-----
From: Palmer, Paul (ISSAtlanta) [mailto:PPalmer@...]
Sent: Monday, April 10, 2006 1:38 PM
To: Basgen, Brian; focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback

Brian,

I work in ISS' research department. This puts me in a somewhat unique
position to answer your question.

One example is the signature coverage for MS05-039/CVE-2005-1983. When
the vulnerability was initially announced, the SNORT community (I do not
know which exact group created these signatures) added approximately 300
different signatures to provide vulnerability-based coverage for the
vulnerability. That is to say, these were not 300 different overlapping
signatures from a variety of sources all designed to solve the same
problem. These were a single group of 300 signatures designed to work in
concert to provide protection against unknown exploits (no known
exploits existed at the time that these signatures were added.)

The fact that 300 signatures were necessary was due to weaknesses of the
SNORT engine itself (it doesn't have a proper MSRPC parser), not the
research community. Even so, judging from what is lacking in the 300
signatures, it seems extremely likely that the SNORT research community
is unaware of all of the different vectors through which the
vulnerability can be exploited since they could have easily added
coverage for these had they been aware of them. It also seems likely
that the research community is unaware of all of the evasion techniques
available via MSRPC and SMB as there are evasions for which I have never
seen SNORT signature coverage.

It is interesting to note that once a proof of concept exploit became
available, the 300 signatures disappeared and were replaced by a small
number of signatures to just provide coverage for the known proof of
concept exploits.

ISS, which has proper SMB and MSRPC parsers, needed to add only one
signature to provide vulnerability-based coverage for the buffer
overflow attack (there is another signature for a related, but different
DoS-only vector). Other vendors vary in the number of distinct
signatures they require for coverage. However, I have seen none that
come close to the ~300 fielded by SNORT.

Paul

-----Original Message-----
From: Basgen, Brian [mailto:bbasgen@...]
Sent: Friday, April 07, 2006 12:28 PM
To: focus-ids@...
Subject: RE: IDS vs. IPS deployment feedback


Andrew,

>some technologies, one signature handles an entire class of
vulnerabilities. Where Snort
>needs multiple signatures for the same vulnerability, ISS can protect
against the
>vulnerability with 1 signature. TP is the same.
 
 Interesting. Can you show me an example of this? I'd like to understand
the design differences that lead the snort signature base to be as
ineffecient as you describe.

> ISS, for example, does their own independent security research an has
signatures to
> protect against things that Snort people don't even know about.

 I don't understand how this differs from the Sourcefire Vulnerability
Research Team. Can you provide some details, specific examples, of where
the Sourcefire VRT has failed and the ISS research has succeeded?

~~~~~~~~~~~~~~~~~~
Brian Basgen
IT Security Architect
Pima Community College

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Mark Teicher]

There are other several other issue not discussed in this thread.  Some of the easier to deploy products may not produce user-friendly, pointy haired management type reports as compared to the commercial products.  But again, some commercial products miss the boat on reporting on concentrate mostly on speed or number of signatures it is in the product, whether speed or number of signatures in an organization's mind is the checkbox why the bought the particular flavor of IDS/IPS.  Speed and number of signatures does not necessarily mean that the particular flavor of IDS/IPS will catch the new fangled vulnerability that has just been released to the wild or trigger on a Sun-RPC port mapper.

-----Original Message-----

>From: Andrew Plato <andrew.plato@...>
>Sent: Apr 11, 2006 11:53 AM
>To: Eric Hines <eric.hines@...>
>Cc: focus-ids@...
>Subject: RE: IDS vs. IPS deployment feedback
>
>As I said to Alan: we all sell what we know.
>
>I sell what I know. You sell what you know. Commercial, open source,
>closed, open, lost, found, black, white - whatever. Organizations should
>pick the best solution for their environment.
>
>That much said, I realize it is pretty much high treason to speak badly
>of an open source product on the Internet. I have angered the Gods of
>Open Source before. This time is no different.
>
>An unanalyzed IDS/IPS isn't very useful. That is the core problem.
>Without analytical capability, the value and effectiveness of any
>security product is reduced.
>
>Many organizations have scant IT resources. As such, any technology that
>has significant resource requirements is usually passed over for those
>that can simplify security while extending the capability of a small IT
>staff. Nobody is arguing the technical merits of Snort, but its an
>established fact that it tends to be more resource intensive than its
>commercial partners. This is true of all open source products. They tend
>to be more "raw."
>
>That is why there are COMMERCIAL companies, like yours Eric and like
>SourceFire that have made Snort more palatable to enterprises. In this
>sense, you are no different than 3com, McAfee, ISS, etc. You're simply
>making a technology easier to use.  
>
>Eric, you and Alan are no different than me. You're just hawking a
>different product. Doesn't matter if the sensor is Snort or Proventia.
>You sell what you know, I sell what I know.
>
>Furthermore, the "I can see a signature so its better" argument just
>doesn't fly at a lot of businesses. Again, most IT people do not have
>the time to analyze and write signatures. Just as companies outsource
>their PC manufacturing, phone centers, and Internet connection - they
>outsource their security protections. They trust a commercial vendor to
>handle this problem. I can't see that the jet fuel Delta puts in a
>plane, but I trust Delta to use real jet fuel. So, I can trust Delta
>with my life, but I can't trust ISS or McAfee to write a IPS signature?
>
>Yeah. Whatever.
>
>If you feel better seeing the signatures and their content, then by all
>means - get thee to a Snort box. But, for many IT groups, this just
>isn't a significant selling point. Ease of use, timeliness of new
>signatures and reliability are typically more important factors.
>
>___________________________________
>Andrew Plato, CISSP
>President/Principal Consultant
>Anitian Enterprise Security
>
>
>
>-----Original Message-----
>From: Eric Hines [mailto:eric.hines@...]
>Sent: Monday, April 10, 2006 3:13 PM
>To: Alan Shimel
>Cc: Andrew Plato; 'Will Metcalf'; focus-ids@...; Applied
>Watch Development; sales@...
>Subject: Re: IDS vs. IPS deployment feedback
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I agree with Alan here.
>
>Andrew, I've watched several of your posts now over the past months and
>on several occasions bit my tongue, but I do have to step up here. You
>represent several COTS (Commercial off-the-shelf) IPS vendors and have
>admitted to, so please be careful when posturing them against open
>source tools such as Snort -- know what you're talking about when it
>comes to Snort's capabilities if you are going to make claims as to what
>its unable to do when compared to COTS solutions.
>_________________________________________________
>NOTICE:
>This email may contain confidential information,
>and is for the sole use of the intended recipient.  
>If you are not the intended recipient, please reply
>to the message and inform the sender of the error
>and delete the email and any attachments from
>your computer.
>_________________________________________________
>
>
>------------------------------------------------------------------------
>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.
------------------------------------------------------------------------

[Randal T. Rioux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Gary Halleen (ghalleen) wrote:
> With the exception of a select few, all Cisco IPS signatures are open,
> and can be cloned, edited, added-to, or edited.  Signatures are stored
> in an xml format inside the .pkg file which is applied to a Cisco IPS
> sensor.  
>
> Gary
>

I couldn't find the 'open' Cisco IPS signatures anywhere on the site.
Does the Cisco definition of the word 'open' mean the same as HP's (ie
OpenVMS... not really open)?

I'd like to download and take a peek at them.

Thanks,

Randal T. Rioux | Procyon Labs
IT Security R&D and Consulting
Virtual: www.procyonlabs.com
Physical: DC / Baltimore
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0xD08D1941


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEQJSdRrGMQdCNGUERA+m8AKCmH6X+0ufmaZ5zetybgYJIQ+AffwCdEMsu
YdKozXHP+GsUDLoz3OGzBPg=
=lZAC
-----END PGP SIGNATURE-----

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Stefano Zanero]

Aaron wrote:
> To add to (or take away) from this thread, I would further mention that
> IDS/IPS regardless of make or implimentation, will only see the past,
> not the future.  

You may wish to notice that this is true, but a problem only for misuse
based devices. Anomaly based devices, on the contrary, use the past as a
way to detect anomalies into the future, and therefore are less
sensitive to the zero-day/unforeseen attack problem.

Stefano

------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Thomas Choi]

Stefano Zanero wrote:
> Anomaly based devices, on the contrary, use the past as a
> way to detect anomalies into the future, and therefore are less
> sensitive to the zero-day/unforeseen attack problem.

Yes but at the cost of high false positive rates.   :)

IMO, until we can come up with a way to accurately define/learn what
'normal 'behavior actually is, anomaly based systems will be pain for
any corporate IT security officer to use.





------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[Aaron-25]

I completely agree.  If you are doing anomaly/heuristics
based detection then you would need to have a baseline.

Just in my own experience (*points at the bags under the
eyes*), I don't really bother with IDS/IPS.  Others I work
with still do and that is fine, but it is a full time job
to chase ghosts.  To each their own. :)

I sleep better knowing I audit my stuff and lock things
down.  It actually kills several birds with one stone
(aspca wont like that analogy).  I find things that I did
not know people installed.  I fix sysadmin boo-boo's and
can further document what is running where.  It also helps
me find ahead of time applications that were not coded
well and can not withstand a lightweight audit.  I can
then work with developers to improve their applications
and dig deaper into application security.  This in my not
so humble opinion is a more efficient approach, as it
catches weaknesses that network devices can not predict or
safely negate without impacting business flow.

But hey, selling network devices means more money changing
hands and more jobs so I won't complain.  Funny money is
still money. :)

--Aaron



On Sun, 16 Apr 2006 17:31:37 +0200
  Stefano Zanero <zanero@...> wrote:

> Aaron wrote:
>> To add to (or take away) from this thread, I would
>>further mention that
>> IDS/IPS regardless of make or implimentation, will only
>>see the past,
>> not the future.  
>
> You may wish to notice that this is true, but a problem
>only for misuse
> based devices. Anomaly based devices, on the contrary,
>use the past as a
> way to detect anomalies into the future, and therefore
>are less
> sensitive to the zero-day/unforeseen attack problem.
>
> Stefano
>
> ------------------------------------------------------------------------
> 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.
------------------------------------------------------------------------

[PPowenski]

From my understand this is the most significant difference that
sourcefire and Ron Gula's tenable security products provide.
Understanding of the enviornment in which they are operating.
For my environment their boxes are cost prohibitive, but if I had any
choice to make it would be to look at these products in preference to
many commercial products..

I have inherited two mainstream IDS solutions and they have far too much
management (SYSTEM, DATABASE, AND Event management) baggage to consider
an effective IDS. Pretty log spitter, definately, usefulness -- as much
as snort, activworx policy manager, and base for analysis.


-----Original Message-----
From: Thomas Choi [mailto:tchoi@...]
Sent: 17 April 2006 22:28
To: Focus-Ids Mailing List
Subject: Re: IDS vs. IPS deployment feedback


Stefano Zanero wrote:
> Anomaly based devices, on the contrary, use the past as a
> way to detect anomalies into the future, and therefore are less
> sensitive to the zero-day/unforeseen attack problem.

Yes but at the cost of high false positive rates.   :)

IMO, until we can come up with a way to accurately define/learn what
'normal 'behavior actually is, anomaly based systems will be pain for
any corporate IT security officer to use.





------------------------------------------------------------------------
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.
------------------------------------------------------------------------
This e-mail is intended for the named recipient(s).  It and any attachments may contain privileged and/or confidential information. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient.  If you are not one of the intended recipients, or this email is received in error, please immediately either notify the sender or contact OAG Worldwide Limited on [phone] quoting the name of the sender and the email address to which it has been sent and then delete it and any attachment(s).
While all reasonable efforts are made to safeguard inbound and outbound e-mails, OAG Worldwide Limited and its affiliate companies cannot guarantee that attachments do not contain any viruses or are compatible with your systems, and does not accept liability in respect of viruses or computer problems experienced. Neither OAG Worldwide Limited nor the sender accepts any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments.  
OAG Worldwide Limited may monitor or record outgoing and incoming e-mail to secure effective system operation and for other lawful purposes.  By replying to this email you give your consent to such monitoring.
Thank you.
OAG Worldwide Limited is a company registered in England and Wales (registered number 4226716), with its registered office at Church Street, Dunstable, Bedfordshire, LU5 4HB, United Kingdom.


------------------------------------------------------------------------
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.
------------------------------------------------------------------------

[virtuale]

Paul,

>we prefer to recommend blocking for a signature >after it has been in the field for a month or >two.

For a critical vulnerability, would you disagree that waiting a month or two to test a signature in the field before deploying it is unacceptable?

>vulnerability. The behavioral signatures match on >consistent elements of malware that we see >repeated regardless of the vulnerability >exploited.

So the behavioural signatures detect malware and not vulnerabilities. Are there any behavioural signatures for vulnerabilities?

V

------------------------------------------------------------------------
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.
------------------------------------------------------------------------