Hey all,
Just wanted to quickly introduce myself (I'm sure Matt will do the same
soon). I've just finished reading most of the archives for this list and
I've had a look at the CVS checkins thus far. Since this project is fairly
important (Matt and I were working on similar before we heard of OWASP),
I've gotten permission from my employer to work on this "on the clock".
I have a couple of thoughts right off the bat, and I expect them to be
contentious, so please hear me out before flaming me into oblivion.
1.) IDMEF is more trouble than it's worth. IDS reporting integration might
be a good thing (debatable for a first version), but IDMEF is absolutely
the wrong way IMO to deal with that eventuality. The spec is vage,
unimplementable (not that that's going to keep people from trying), and in
reality doesn't buy us much. If we are hell-bent on doing IDS integration
right off the bat, I suggest we look at SnortML's DTD, as it's
significantly more sane. Better yet, let's just use syslog for the time
being. It's there for a reason, it works, it can be network transparent,
and it's used/understood by thousands of security professionals.
2.) filter categories. Developers aren't security people (by and large).
Yes, they could figure out every corner case and come up with their own
"filter" rules where they need them, but I think that if we put the onus on
them to come up with match/reject classes, then we've done nothing more
than give them a slower regexp engine. I honestly beleive we have a chance
to enshrine best-practice filtering rules in code that people can just call
based on what the "threat category" they are trying to avoid is. So, say
someone is concerned about cross-site scripting and wants to store their
data in a SQL database, we might provide a set of functions that they could
composite like this (using python for example):
def myFilter(str):
str = OWASP_filter_xss(str)
return OWASP_filter_db(str)
obviously there might be some (optional) arguments to these functions that
constrain their behaviour, but we should go for sane defaults and not
provide more options than are strictly necessaray to safely strip out
offending input.
This can be thought of as a Huffman encoding problem to some extent: if we
define an entire grammar that developers have to wrap their head around,
then we're not lowering the bar any in providing secure input to their
internal systems. Trickier things should have longer names, etc, but
filtering on a basic set of threat classes should be made drop-dead simple.
3.) default behaviour. Reject everything by default, accept what matches.
Doing things any other way says some very unflattering things about our
understanding of what building secure software is all about.
4.) simplicity. Let's put togeather some _really useful_ filters right off
the bat in the prototype language (whatever that might be) and start
using/improving them. Once we've got some experience with what works and
doesn't we can iterate and improve things as it fits. No need to engineer a
solution to problems that might not even exist (except in our heads).
--
Alex Russell
al...@se...
al...@ne...
|
