Re: [Owasp-input-api-developers] Re: considerations with regards to development

[Gabriel L. <ga...@bu...>]

Alex, 

I think these principles are very good. I totally agree with them. 

But, I think in some ways we are still stuck in the vision thing. One of
the key problems with the vision side of things is that I think we are
all close to each other but slightly different so we are having a
communication issue where we are just missing each other.

I think what I'd like to do is take Mark's suggestion to heart about
looking at requirements. In fact, I know this turns the rational model
on its head a little, but I'd like to pull together a list of very high
level requrements first and foremost and use that to help us drive the
vision thing. Why? Primarily because I don't think we have developed a
common vocabulary yet, and so we are like trains passing in the night.

Here's some examples of what I mean of very high level requirements and
I'm going to pick on the topics of the earlier vote and some of the
earlier discussions.

Canonicalization has been a big part of our discussion and is generally
agreed upon as something we need to do. But, in my mind this is really
just a solution to solve a requirement that seems to be going unspoken.
This requirement is that attackers shouldn't be able to obfuscate an
attack so that we cannot block it. The way we are looking at solving
this is by normalizing all input so that we can apply a single set of
tests to any input... I have no bones to pick with this as the solution,
but I'd like to get us to look at the higher level requriements first so
that we can get a full coverage idea of what kinds of things we need to
think about and our approach to things.

I think this should be conducted in a brainstorming fashion, and I think
it probably makes sense to do it on this email list. What I will do is
be the note taker. I'd like to see people put together emails that run
through their high level requirements for what they think this thing
needs to do, along with a little bit of explanation so we all can start
to get a grip on what each other is talking about and what each others
terminology is. Lets not eliminate anything at this point.

Once we have all these in place I think we can look at them and try and
organize them. My hope is that out of this process we can come up with
goals, long term and short term and requirements for different releases
of the software. But, that these basic requirements are the building
blocks of these larger concepts.

-gabe

On Wed, 2002-06-26 at 19:06, Mark Curphey wrote:
> Alex
> 
> You're a man after my own heart ;-)
> 
> Models like Biba and Bell la Padula should have taught us far more than
> appears to have been the case !
> 
> 1. Monolithic kernels - great example  
> 
> 2. Agreed. remember you don't have to feed the world from day one. Why
> not define requirements and then prioritize them ? lower priorities can
> be dealt with in release 2.0 etc
> 
> 3.  Agree. I would have thought that something more than good
> documentation seems appropriate. I can get you help with that when the
> time comes.
> 
> So why not take this approach ?
> 
> (This is based on the RUP - Rational Unified Process). 
> 
> 1. Develop a Vision Document
> 
> http://www.rational.com/media/worldwide/singapore/introducing_processes.pdf is one example on the web but you'll find lots. The vision document include features not requirements. It includes short sections on the problem we are trying to solve, objectives, risks, resources etc
> 
> 2. Develop a set of prioritized requirements
> 
> 3. From the requirements develop your use cases and move on.
> 
> Remember iterative development works better than waterfall development
> as well.
> 
> I can help with this sort of stuff if you want. 
> 
> I can certainly take a first step at a Vision document on Friday. Just
> let me know !