Where do You Architect Security in An Application (Was HTTPS Security Moniting Tools)

This is an interesting thread IMHO

I have always been of the belief that you should perform security decisions at 
the same place as you perform other business logic decisions i.e. in the 
application itself. Of course your architecture will compartmentalize 
components and fucntionality but it makes more sense to do this at a business 
logic tier IMHO. In an enterprise architecture you also normally have a 
component that controls authn, authz and session management etc so why would 
you not peform the input validation and other security functions there as well 
? Why push it outside of the application. You then don't have to deal with SSL 
visibility, bandwidth, load balancing etc because at this point those things 
have been factored into the application architecture. 

I have always wondered how they deal with things like paramater manipulation 
attacks or plain old bad application logic and so on that are not obvious from 
the data stream. Any gurus on the list that can explain / help ?

It seems like there is a good place in a defense in depth strategy and I can 
certainly see how some traffic is easy to filter out but .......why an app 
level firewall and not a software component ? Apart from performance having it 
on an ASIC but thats only an issue cause its a box not a software component. If 
you can process the stream to do a business logic decision then you can process 
it to make a security decision right ? What am I missing here ?

Does anyone know of any of the vendors building reuseable security software 
components ?

I am amazed at the amount of app level firewall / ids's out there. I counted 18 
commercial companies in the space the other day. I also know of very few people 
who have bought them but I am sure that can't be true with the amount of VC 
invested and companies out there.

---- Gary Flynn <flynngn@xxxxxxx> wrote:
> lists AT dawes DOT za DOT net wrote:
> 
> > The organisation is providing a service on their web server, and 
> > consequently have a need/right to see the data in clear. In 
> > particular, they may wish to do multiple things with the data, such as 
> > performing IDS, tracking users, etc, apart from providing the service.
> 
> Very good point. NIDS/NIDP, deep inspection firewalls,
> network based content management and rate limiting will all
> go the way of the dodo as applications increasingly all start looking
> like HTTPS unless the encryption border is in the network instead
> of each individual host.
> 
> 
>