Re: Practical Firewall Metrics...Was: INtrusion Detection

[Bennett Todd <bet () rahul net>]

1998-02-20-05:45:26 Christopher Nicholls:
> The question has to be asked: Are there any practical metrics for assessing
> the quality of a firewall? 

Sure, we've still got the oldie-but-goodie ``how well does it do the job
we're paying for it to do?''.

Now that naturally means it's the customer's job to decide what they
want their firewall to do. And that's the weak spot. The customer has to
have a coherent security policy to really do a firewall right; you can
install one without a proper security policy but then you can't evaluate
whether it does its job.

I have been known on occasion to recommend a stock config for a place
that has no security policy to speak of; if you can get 'em to adopt
something that's cheap and simple to implement and a good bit more
strict than they probably need, then they can forget about that part for
a while and work on the security policy without getting burgled while
they're trying to straighten things out.

> By this I am *not* meaning: Which is better - proxy, screening or stateful?

Each is better, for its own job.

Simple packet filters are a key building block. Any time you need to be
offering higb bandwidths and negligble latencies --- e.g. in front of a
major web farm --- you use packet filters. E.g. a pair of maxed-put
7513s in HSRP with trivial filters to block IP spoofing and allow
nothing but inbound port 80. That's a lovely building block, delivers
nice tight security right where it's needed, and doesn't hold up the
bits too badly.

Proxies are another key building block; they're the stones from hich you
assemble most bastion hosts, the heart of any tightly-secured internet
connection that offers many and diverse services.

Stateful packet filtering probably has its uses too, though I personally
haven't run into them; it offers some of the speed of simple packet
filtering, while being able to do some tricks that require examining
content streams --- firwalling ftp is the classic example. Problem is,
they have a long history of failing ``open'', a tradition they do not
share with the other two firewall building blocks. (Read the nmap paper
from <URL:http://www.dhp.com/~fyodor/nmap/> for the flavour of things
that have gone through stateful packet filters).

> This automatically decends into highly subjective argument, which - while
> entertaining for a while - is hardly edifying.

It doesn't have to! ``Yes it does!'' ``No it doesn't!''
        - after Monty Python's Flying Circus, the Argument Clinic sketch

:-)

> There is a particularly interesting paper by Marcus Ranum at:
>
> http://www.clark.net/pub/mjr/pubs/fwtest/

Sure is. I'd sum it up by saying the closest you can do to a useful
firewall ``test'' is to have it fully configured and installed to fit
your security policy, give the independant auditors complete access to
the architecture spec, source code, and configuration settings, then
have them try to break it with full knowlege.

> What do the list feel about this - how do we set a criteria for selecting
> the best f/w, ID, etc for our secure networks - is it possible?

Sure! Write a _really_ good security policy, one that takes into account
a detailed knowlege of today's threats and currently-available
techniques for protecting against them --- and the costs, in $$$,
manpower, and inconvenience, for implementing those techniques.

Then use your policy as a shopping list: find the firewalls best-able to
implement that policy. Configure 'em up and test 'em carefully to ensure
that they perform as documented. Throw out and re-do every couple of
years, since over that time span the universe moves enough to completely
obsolete the grounding design decisions of your first firewall
deployment.

Or, set a firewall stance _way_ more strict than necessary to meet your
security needs, don't budge in the face of demands from the users for
more features, and relax behind your secure perimeter, until your users
string you up by your tender bits:-).

-Bennett