[Owasp-appsensor-project] World Summit - AppSensor Results

Colin Watson colin.watson at owasp.org
Sun Mar 6 12:14:15 EST 2011


John

Yes, sorry I perhaps wasn't quite answering your original question,
but I thought I should share where I had got to with logging ideas
last year.  The ESAPI security event logging was the original
inspiration, but I found I wanted more structured details.

The other sources of information I looked at regarding application logging were:

   How to Do Application Logging Right,  Anton Chuvakin and Gunnar Peterson
   http://arctecgroup.net/pdf/howtoapplogging.pdf

   OWASP Logging Project
   http://www.owasp.org/index.php/Category:OWASP_Logging_Project

   NIST SP 800-92
   http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

You'll see ideas drawn from all of those.

Your description of different handlers sounds good.  I know not
everyone will want or require the same level of logging, but it would
be nice to have a wide range of options built in, even if we allow
NULL for most fields.

The logs will be important for the user and system trend detection
points, hence the ideas of recording a unique request number, the
particular URL, the particular module/function, the target, the user's
identity and the results.

Happy rumination!

Colin

On 6 March 2011 03:51, John Melton <jtmelton at gmail.com> wrote:
> Colin,
> Wow - a lot to digest, but fantastic ideas and detail :>.  I'm definitely
> going to look into this more closely, but wanted to get a response out
> quickly.  My short response would be yes and no (I love that response :>).
> Basically, I would agree 98 % of apps probably write to a DB, and I also
> agree that a mechanism like this would be the most logical in my opinion,
> but not everyone does everything the same way.
> I'm ruminating on the idea a bit more, but I'm thinking of refactoring the
> "logging" to be a bit more simple, at least logically.  I'd like to get it
> to the point where we have the intrusion object self-contained with all the
> necessary data (several data points you have below are missing in the
> current implementation) and that gets passed to some output/response
> mechanism.  From there we should have a collection of handlers.  These
> handlers logically look the same (follow something like the command pattern)
> and get passed an intrusion.  We'll have a standard DB style handler, maybe
> a set for different DB's, and a log handler, and a CEF handler, etc.  Since
> we're building a "framework", we have to make it easy enough for folks to
> plug in their system, or at least see how it should plug in.
> I've not coded much on appsensor lately, and am looking back now to try to
> analyze (with fresher eyes) some weak spots that can be worked a little
> better. I'll try to keep everyone posted as I make any progress.
> As always, if anyone on the list wants to jump into the java piece of the
> project, ping me and I'll try to get you setup.
> Thanks,
> John


More information about the Owasp-appsensor-project mailing list