Re: Protocol Anomaly Detection IDS - Honeypots

[Bob Radvanovsky <rsradvan () unixworks net>]

See comment embedded below...  -r

At 12:58 PM 2/20/2003 -0600, you wrote:
> On Wed, 19 Feb 2003, Robert Graham wrote:
>
> > People have been hoping that there is some sort of magic-pill 
> technology that
> > solves the problem of IDS. "Protocol-anomaly detection" is one of those
> > buzzwords that promises a magic pill.

What'ya mean "magic pill"?  As in "here -- take 2 of these, and 1 of those, 
and call me in the morning..."?  No -- ain't no such 'ting there 
Wally.  Problem is -- is that executives are not technology savy, so they 
rely on the technical people in providing effective solutions, sometimes 
going to outside vendors for their solutions.  Remember: vendors are in the 
business to "sell product", and nothing more -- whether that is a service 
or a manufactured product (hardware, software or some combination 
thereof).  So -- if a security vendor tells your networks needs "XXX" and 
this will be taken care by our "Super Duper Fast-Acting  RED Pill", in many 
cases, they're blowing smoke and mirrors.

In my humble opinion, such products do exist, but might not in their 
entirety or are so cost-prohibitive, that it wouldn't make any sense to 
implement them in the heterogenous environments that exist today (Novell 
[yes, there are many places that still use this operating system], Windows, 
UNIX and LINUX, with a smidgen of mainframe for flavor) -- because 
implementing these so-called "quick fix" solutions might be 
architectually-interdependent.

> Okay, I'll admit, to me alot of the security problems I see are nothing
> more then nails, and honeypots are the hammer.

Wouldn't a honeypot/honeynet *show* how someone actually *thinks* based on 
how they are interacting with the target server or network???  If so, then 
yes, this would be a much more cost-effective method for anomalous 
detection IDS.

> However, seriously, have folks considered the detection capabilities of 
> honeypots?  The reason I bring this up in this thread, is for honeypots, 
> everything is an anamoly.  The concept of a honeypot is it has no 
> production or authorized activity.  Everything it captures its way is most 
> likely malicious activity.  Not only that, but you dramaticaly reduce 
> 'noise'.  Instead of dealing with 5,000 alerts a day (not that high of a 
> number for many organizations) a honeypot in the same environment could 
> only generate 5 or 10 alerts a day, alerts you most likely need to take 
> action on.  These small data sets can make it far easier and cost 
> effective to identify and act on
> unauthorized activity.

Here, here -- I completely agree that installing honeypots or honeynets 
would help aggregate the detection process.

Some companies that I have dealt with in the recent past are reluctant to 
implement such technology, or in using some sort of honeypot/honeynet 
configuration.  Not only does it bring the intruder closer to your 
doorstep, but it is costly to maintain, difficult to configure, and 
difficult to make any changes to it once implemented -- at least -- this is 
what these companies have stated.

Personally, I think that they're afraid of any legal implications or risks 
that might (or could be) associated with such an implementation.  I don't 
see what the negative implications could be for such an implementation -- 
at least -- legal implications of risk(s).

Besides -- isn't the whole idea or point of implementing a honeypot or 
honeynet to isolate the intrusions as much as possible?  Theoretically, it 
*should* work; however, I have seen too many network engineers misconfigure 
their switches or routers and place "convenience doors" for their use when 
they need to perform network configurations or maintenance.  In doing so, 
they're created a "backdoor" for intruders to gain access to companies real 
networks, or demonstrated to the would-be intruder that the network is an 
illusion.  Either way, I think that this is where the greatest risk lies 
with such an implementation.

> I'm in no way suggesting that honeypots replace any existing detection
> technologies, I'm suggesting that can contribute.

Agreed -- provided that networking engineers or networking groups of 
companies implementing these solutions internally don't install "backdoors" 
for their networking products for "maintenance purposes". ;)

> Personally, I feel the concept of deception has overshadowed the value of 
> honeypots, when one of their true values lies in detection.

Ironically, isn't it interesting how 10 years ago -- all of this was NOT 
considered "mission critical"???   To recap -- we have "critical", 
"business critical" and "mission critical".  What's the next level *after* 
"mission critical" -- "extremely mission critical"?  If so, shouldn't 
companies *NOW* start to consider using honeypots or honeynets?  When does 
the justification for the use of such technologies justify its 
means?  Answer: when it's too late. ;)

-r

DISCLAIMER: The IMF will disavow any knowledge of my *official* 
whereabouts. This email message will self-destruct in 5 seconds.



-----------------------------------------------------------
Does your IDS have Intelligent Attack Profiling?
If not, see what you're missing.
Download a free 15-day trial of StillSecure Border Guard.
http://www.securityfocus.com/stillsecure