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

[Mark Curphey <mark () curphey com>]

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 () jmu edu> 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.