RE: Application level IDS?

["Drew Copley" <dcopley () eeye com>]

> -----Original Message-----
> From: Dug Song [mailto:dugsong () monkey org] 
> Sent: Thursday, June 19, 2003 7:43 AM
> To: focus-ids () securityfocus com
> Subject: Re: Application level IDS?
>
>
> On Wed, Jun 18, 2003 at 09:26:19PM -0400, Eric Greenberg wrote:
>
> > Or if there were a profile of the application (a 
> dynamically developed 
> > sandbox "profile") and an application stepped out of those 
> bounds, a 
> > system could perhaps detect it.  I tend to think of it as 
> an operating 
> > system level function in an ideal world. No doubt though, 
> > application-level IDS's nearly become operating system overlays.
>
> systrace allows you to interactively (or automatically) 
> permit/deny syscall-level rules per application (or for all 
> child processes). it already ships with OpenBSD and NetBSD, 
> and has been ported to Linux and MacOS X. a Solaris port 
> would be most welcome.
>
> see http://www.systrace.org/ for details...
>
> -d.

Systrace is, in fact, an OS overlay, in this sense, and the most excellent example. However, with SQL injection attacks 
[as the
writer noted] you have various problems such as the fact that your SQL engine very well may be requesting these apis in 
the context
of the SQL engine. 

The original poster noted numerous applications which used these types of syscall gating:

"When I think of application-level IDS, wherein some level of knowledge of correct or allowable application-level 
behavior is known
and controlled, I think of products such as those from Okena (recently acquired by Cisco), Entercept's products 
(acquired by Network
Associates), RealSecure Server Sensor and Desktop Protector (formerly the bBlackICE product), and primarily at the 
desktop,
ZoneAlarm.  These application-level IDS's focus on managing network-level actions based on application-level knowledge. 
"

You can make a "pre-defined" sandbox, but the SQL administrator still has to ensure that whatever he blocks, he does 
not use.

On a more microscopic level, though, it should be possible to make such gating software that hooks into the SQL engine 
itself which
would allow a greater focus on potential abuse... then what could be gotten at the Kernel level.

Partly, anyway, this would be useful because SQL is so robust. The same injection attack might be presented in numerous 
different
ways, for instance, you may use various combinations of variables and boolean operators to say the same thing in a 
different way. It
would probably be most productive, therefore to first parse what is being said, then gate it after it has been parsed.



> ---
> http://www.monkey.org/~dugsong/
>
> --------------------------------------------------------------
> -----------------
> Attend the Black Hat Briefings & Training, July 28 - 31 in 
> Las Vegas, the 
> world's premier technical IT security event! 10 tracks, 15 
> training sessions, 
> 1,800 delegates from 30 nations including all of the top 
> experts, from CSO's to 
> "underground" security specialists.  See for yourself what 
> the buzz is about!  
> Early-bird registration ends July 3.  This event will sell 
> out. www.blackhat.com
> --------------------------------------------------------------
> -----------------


-------------------------------------------------------------------------------
Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the
world's premier technical IT security event! 10 tracks, 15 training sessions,
1,800 delegates from 30 nations including all of the top experts, from CSO's to
"underground" security specialists.  See for yourself what the buzz is about!
Early-bird registration ends July 3.  This event will sell out. www.blackhat.com
-------------------------------------------------------------------------------