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

["Jeff Williams" <jeff.williams () aspectsecurity com>]

The right place to make a security decision is 1) at a nonbypassable
decision point (any of you old Orange Book reference monitor types who want
to point out tamperproof and verifiable -- let's just get first things first
here for now), and 2) where you have the right information (access control
policies, input validation rules, etc...)

So let's work in from the outside of your network.

A) The application proxy is very attractive on point 1, because all the
traffic has to go through the proxy and you can make a decision there.  The
problem is with point 2.  It's very difficult to get the "right information"
into the application proxy, since you have extract all that knowledge from
the code, put it into some format, and poke it into the proxy. This is why
you have to have some kind of "learn mode" -- but there's a lot you CAN'T
learn by watching traffic.

B) Moving in, you might have a plug-in to your web-server like mod_security.
These are great on point 1, but also have a point 2 problem.  You can go a
long way in customizing them for your custom application, but again it's a
lot of work to get the right information into them. This definitely seems
like a good place to enforce the simple rules, though.

C) Going up to the app layer, a J2EE filter does well on point 1 and has
access to some of the configuration information necessary for point 2. This
is probably a nice compromise location, but I haven't seen any filters built
with any support for this type of checking. That's why I'm adding it to
Stinger -- to be released sometime soon.

D) Heading into the application now, you could use a common secuirty
component to do validation (like the current Stinger) and access control.
This is where point 1 starts to be a problem. It's difficult to prevent a
programmer from going around your little component and skipping your
security checks. There's NO support in J2EE for forcing this type of
checking to be mandatory, so you have to rely on coding standards and good
developers.

E) The last approach is the one I see the most often (unfortunately). Bury
security checks all over the place in the code. This is terrible on point 1.
Developers will consistently forget or botch the checks.  But this is GREAT
on point 2.  The developer has all the right information right at their
fingertips to make the perfect security decisions. But it's just too hard to
get them done consistently.

Whoops, I just realized I should have probably put one in before A for the
"deep packet inspection" approach. Oh well, it's not real good on either
point, is it?

--Jeff

Jeff Williams
Aspect Security
http://www.aspectsecurity.com

----- Original Message ----- 
From: Mark Curphey
To: Gary Flynn ; webappsec () securityfocus com
Sent: Saturday, February 28, 2004 12:13 PM
Subject: 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 () 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.