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

[marko <chrome () liquidinfo net>]

> This is an interesting thread IMHO

Yes indeed..

> I have always been of the belief that you should perform security
> > decisions at the same place as you perform other business logic 

This is true, but "rarely" it is looked at, from security point of view.
The application is done and afterwards the bad stuff is found via an
application audit. Then people create a workaround to the issue, but
never really deal withi it.

It would be nice if security is taken into account from the beginning of
application development, via inspecting the real business logic that is
needed. This would then take in account encryption amongst other
things..

> 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 

It would make sense that everything is taken into account from the
beginning in an application, but unfortunately that is not many times
the name of the game. It would be best to go from bottom-up with
security, in a project and from the beginning, taking every "thinkable"
exploit into account when designing the application itself. Then you
could implement the protecting SSL-layer on top of it to protect the
information itself.

Security-needs must be taken care of from the beginning of the contact
or one would find himself in a nasty situation when security issues are
found, as the vendor could state that they were not supposed to take
into account X-related issues as it was not mentioned in the contact...

> 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. 

Security should be considered from ground up, with especially security
in mind, tackling session promblems, impersonation etc... security
should be thought from the beginning, but that is rarely the case with
fast emerging projects, where party X wants product Y in as little $$$
as possible from party Z... But you are right that by proper planning
one would actually be able to create a simple reporting-mechanism to the
application that would probably detect attacks (unexpected things) much
better than an IDS.

> 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 ?

I am far from guru, but I try to give my view-point with earlier and
following comments... I see the only possibility to create the
application to be as strict as possible. If there is encryption taking
care of the sensitive transaction, that is only a good thing, but the
responsibility in the end should stand with the business logic, how the
"views" etc are implemented.

> .......why an app level firewall and not a software component ? Apart
> > from 

If you build an app to be secure from the beginning and accept only
certain type of input and output that is expected (while disregarding
other kind of output), why would you need an application firewall, as
you could make your application to generate error logs that indicate 
the access violation/attempt? (as an example ;)

> 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 ?

An application should always atleast to attempt to keep track on what is
allowed and what not (ie, user A shouldn't be able to view user B
information, even if cookie X is changed to Y) etc...

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

I don't know of vendors, but I know of some customers that have created
reusable input validation components that can be used in other projects.
This kind of re-use lowers the cost, and makes us in certain areas
obsolete, but then you serve the customer best if you can provide
information that is beneficial.. not just a piece of software that
claims of being able to do XYZ..

It might actually be very nice if some major vendors would push out
input validation compontents for their major platforms, like asp/jsp
etc.. That would in my opinion atleast make the builders to first think
about security, before putting it through a validator..

-m-
-- 
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--