RE: Re: Air Gaps vs. Firewalls

[Rick Smith <rick_smith () securecomputing com>]

Before I roar off, let me reiterate my main point:

I don't believe it's practical to create high fidelity choke filters on a 
firewall that are intended to perfectly reflect the "legal" and "illegal" 
formats of a particular application of a general purpose protocol. For 
example, I don't think Amazon could develop detailed regexps that 
distinguished between acceptable transactions from their forms and "out of 
bounds" transactions. It's technically impractical because 1) the specs 
don't generally exist to create the filters and 2) the site will worry more 
about lost business caused by misfiring filters than they will about 
inbound hacker attacks.

Perhaps the proof of the pudding will be in the eating. I know of no 
examples of large scale, complex web sites (Amazon, for instance) that uses 
such filtering as part of their security. I've also had enough experience 
with security specifications (too much of the previous decade) to realize 
how tough a problem we're talking about. It might be possible with the 
right tools, but then I think it's reasonable to apply such tools in 
different ways to yield the same or better results.

To get to specifics, Richard Reiner responded to my earlier comments:

> > In other words you're trying to restrict the URLs *at the firewall*
> to match the anticipated
> > properties of the web applications being restricted on one side or
> the other.
>
> Absolutely.  That's what the whale device tries to do, and it sounds
> VERY desirable to me -- principle of least privilege, and all that :-)

Least privilege is a nice, clean technical objective but it doesn't 
directly address the goals of a web site's proprietor. The proprietor 
generally has some problem to solve ("sell products" or "distribute data to 
the right people") and least privilege only makes it harder, not easier. 
Now, the proprietor might be worried about 'security' and tolerate some 
'least privilege' to get it. But it's never a goal in itself, except for 
technically oriented security people.

> Certainly it's tricky; but least-privilege environments are always
> tricky to work in.  If your risk analysis and your CBA tell you it's
> worth the effort, though, it's nice to have the option, which you don't
> unless you have this level of granularity in the
> firewall-or-other-perimeter-defence-device.

At best, a risk analysis might justify throwing more money at the security 
problem, if the people with money believe the analytical results. But it's 
not going to specify a particular mechanism (like URL filtering) to address 
the identified risks. Even an honest intrusion analysis won't specify a 
particular mechanism.

> > This is a surprise to me. Do web site developers really work
> > with specs that would clearly define the possible values flowing
> through
> > a URL? Is this common anywhere except perhaps the most sophisticated
> > sites?
>
> Well, it's certainly true in some of the environments we work in.  But,
> as above, definitely not in the SME world.
......

> > Even if one has such specs, wouldn't it make more sense to use those
> specs to
> > automatically generate range and type checking code at the server end?
>
> No -- least privilege again.  Content checking should absolutely not be
> automatically generated from the code, or from the spec written by the
> code group.

Bzzt. Wrong answer. You're suggesting that a detailed and 100% accurate 
spec of the Web URL interface is essential, but the Web site implementers 
can't be trusted to write it.

Based on my own experience with security specs, let me tell you a secret: 
it's impossible to get such specs written by a third party for anything 
more complex than a toy problem or perhaps for a nuclear weapon control 
mechanism.

The practical solution used by my favorite paranoids was to review the 
bejesus out of our specs or, even better, "machine check" them. In 
practice, of course, humans proved to be the most effective checkers.

Rick.
smith () securecomputing com


_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards