RE: [was] WAS Protect

["Mark Curphey" <mark.curphey@foundstone.com>]

Ivan,

This is excellent. I am not qualified to provide commentary of any value
but let me add my comments to your "process" questions. 

I agree on the simplicity and iterative development. Lets focus on a
scope that we can describe, document and deliver a reference
implementation for August. The complex tasks can be added for Version 2.
I know there are some very cool things that can be done with Test but in
the same vain I think we can define the basic structure and then work on
updates in a later version that explores the clever stuff.

I am working in getting a WAS repository funded (leveraging Ingo's
VulnXML Database) in some way where people can create, submit, explore
etc signatures. I think it would be very feasible to write a web app
that simplifies the XML creation. I will explore this with the
developers. But on that point I think both Test and Protect needs to be
able to reference a vendors proprietary signature. This will allow
vendors to adopt and consume the Meta and Profile data as part of
business processes, whilst still maintain their own optimizations of
signature formats. Others could consume and process all the data a WAS
signature would / could provide.

I am trying to put together a document that describes a full lifecycle
WAS process and where each piece fits in and how it would work.

As a reminder next Tuesday we are holding the face to face meeting in DC
in order to complete the Core work and start documenting it. This will
allow us to build the WAS repository application etc and publish the
classification scheme. 


Mark Curphey
Consulting Director
Foundstone, Inc.
Strategic Security

949.297.5600 x2070 Tel 
781.738.0857 Cell
949.297.5575 Fax 

http://www.foundstone.com 

This email may contain confidential and privileged information for the
sole use of the intended recipient. Any review or distribution by others
is strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies of this message. Thank you. 
-----Original Message-----
From: Ivan Ristic [mailto:ivanr@webkreator.com] 
Sent: Tuesday, March 16, 2004 7:11 PM
To: was@lists.oasis-open.org
Subject: [was] WAS Protect


Hi all,

I've finally managed to compile my notes on WAS Protect (and the HTTP
server side protection in general). I also now have time in my schedule
to work on this element - I expect we can have it completed in time. I
can start and finish the work on my own but, for things like this, I
prefer to have input from other people - it's always useful to consider
various points of view.

The document is a result of my woon mod_security, its limitations,
analysis of other similar attempts, and various server side programming
APIs. Mod_security limitations were particularly useful.

In my opinion, WAS Protect should consist of a specification of an
execution engine, with a data model and a (simple) programming language.
The capabilities of the engine are specified in the document.

I have the following concerns:

1) The scope of the effort

   On one level, WAS Protect can and should be used to protect
   from known and unknown threats. On the next language, it can
   also be designed to be a more generic server-side protection
   language, which people can use to secure their web servers
   and applications. I've done both for mod_security but generic
   protection may not make sense for WAS Protect. It would be
   cool but would it serve a purpose? Would anyone implement it?

   Personally, I prefer iterative development and wouldn't
   mind leaving the fancy stuff for later. Another thing to
   consider is that a simpler standard will be more likely
   to be accepted, or accepted faster.

   Some of the features mentioned in the document are an order
   of magnitude harder to implement. For example, stateful
   operation. This functionality is a good candidate for a
   later version.

   Stateful operation is necessary for these:

   * Detect brute force attacks
   * Session fixation detection
   * Session hijacking detection
   * IP address / user blacklisting

2) Overlap with WAS Test

   There's a large overlap in functionality between Test and
   Protect. Test creates requests, and analyses responses. Protect
   analyses requests, and responses, possibly creates responses.
   Therefore a single language should be used for both. From
   what I've seen, VulnXML cannot support Protect. So we need
   to resolve this issue.

3) The question of format

   XML is obviously the flavor of the day, for good reasons. But
   is it a good choice to store engine statements/instructions?
   XML is good for storage and parsing, but it's not very
   user friendly. And if we use XML it is unlikely anyone will
   want to write Protect by hand. Is having more than one
   representation a good way of solving this problem?

PS. In case the attachment does not go through the email, I've
   uploaded it here:

   http://www.webkreator.com/download/was-protect-1.pdf

--
ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web
applications ]