Re: FW-1, etc.

[Ed Strong <ems @ ccrl . nj . nec . com>]

I hesitated in replying to this, for fear of adding to the religious wars,
but I felt a few things should be pointed out.

On Thu, 2 Mar 1995, Bryan D. Boyle wrote:

> On Mar 2, 10:58am, Ed Strong wrote:
> > Subject: Re: FW-1, etc.
> >
> > David is not telling the whole story. If, like in many orgranizations, a
> > small fraction of one person's time is devoted to the firewall issue,
> > FW-1 gives good security at low overhead. Proxy-type firewalls are much
> > more labor intensive, and much less flexible, for relatively little
> > improvement in security. If you don't have time/resources to install special
> > client software on every machine (as required by most proxy firewalls), or
> > develop custom proxies wherever needed, then FW-1 is the best solution.
> 
> Oh?  I don't seem to recall having to install special software on any end-user
> machine in an environment of over 1500 users to get thru the SEAL/TIS firewall
> here.  I also don't have to worry about a 'black box' software package running
> on a known-insecure operating system that has a failure mode of "everything
> open".  All of the >useful< tools know about application proxy firewalls, and
> security schemes in use today.  If they don't, then the producer of the
> software is not interested in business uses of their wares, and should probably
> concentrate on the education and non-profit markets where security is not a
> concern.

I didn't get beyond talks/visits with the DEC SEAL people (pricing $$ scared
me off) The number of proxy apps is necessarily limited, the number of 
transparent proxies even more limited. And many of us do not have the option
of dismissing all software not written with security in mind.
 
> If anyone thinks there is a simple, plug-in and forget about it approach to
> security and network access, then they are deluding their management.  If you
> don't have time to do it to an auditably correct position, then perhaps you
> shouldn't be doing security.  Security is a full-time mind set.  FW-1 is a
> panacea for companies that think you can put in equipment and software and
> trust it blindly without understanding the principles or threats, since it is
> sold as a 'you just click on this, doodle that, and you are secure'.  That
> scares me.

You make a number of dogmatic statements here. Who says net security must 
ever remain an incredibly labor-intensive task? Why? Does the ease-of-use
of a well-designed GUI (opinion here of course) automatically make a product
unfit to use? FW-1 is simply a security tool that works, if used properly.
I won't pretend that I haven't studied a lot about security to date, but I
won't count that effort as wasted just because a simpler tool becomes
available.

> > Of course the trusted users inside can tunnel out through FW-1 if they want
> > to. But trusted users who want to leak information will not be stopped
> > by an application level firewall either, unless you body search everyone for
> > bootleg media and also cut off all modem access. (Pretty draconian.)
> 
> We control both here.  We have policies in place for both of those instances.
>  I know some government sites that do a pat search on the way out the door
> while they rifle your briefcase/pocketbook/whatever.  Depends on the company
> and their view of the threats.
> 
One of my working axioms is "Security policy without enforcement is no
security policy at all." Telling employees they mustn't smuggle media is not
actually controlling such media. Only an actual frisk does this. Since your
company apparently does not frisk, then you cannot be controlling media.

Referring to government sites where they actually perform the frisk, is not
too germane, except to show their security levels are consistent, while 
yours is not. My main point is that actual control of information, which
many firewalls seem to aim at, is quite difficult. (Yes, I've worked in
government places where they locked you into a vault, etc. So what?) Our
policy is aimed at the much more modest goal of keeping outside hackers,
pirates, and snoopers out of our network. FW-1 does this admirably.

> >
> > You have to decide what level of security is right for your organization
> > and apply the same level consistently. FW-1 may be right for you.
> >
> You get what you pay for.  A packet filter is not a firewall.  UDP can not
> be handled securely (or with anything approaching predictable security
> anyway...) with the current technology or the base protocol itself (upd was
> designed to not depend on predictable connection capabilities, which makes it
> incredibly easy to intercept or spoof, not that tcp is necessarily without its
> vulnerabilities...).  IMHO, you start with the basic services you want to
> provide, and allow only those.  Shut off everything else.  Log everything,
> provide a demilitarized zone, and _then_ slowly open the spigot.
> 
FW-1 is more than just a packet filter, and does a good job of handling udp,
I've got the logs to prove it. It handles spoofing as well. Your methodology
for developing a firewall makes the assumption you are using proxies.

> Oh, yeah, make sure the base operating system has a history of being able to
> be secured.  Isolate, seperate, and delegate.
> 
> Or else, what you have, in essence, is a fancy router with filtering.  And
> that provides minimal security.
> 
> Just my $.02.
> 
> -- 
> Bryan D. Boyle        |Physical: ER&E, Clinton, NJ (908) 730-3338
> #include <disclaimer> |Virtual: bdboyle @
 erenj .
 com
> World-Wide-Web: http://www.digimark.net/bdboyle/index.html
> http://www.digimark.net/bdboyle/pubkey.html for pgp public key
> 

You may want to reconsider some of your assumptions, for instance, assuming
that FW-1 is equivalent to something you know is insecure, without knowing
it's actual capabilities. I won't pretend FW-1 does everything, if you
won't pretend laboriously-designed proxy-type firewalls do everything. The
job of security can get easier.

-----------------------------------------------------------------------
Ed Strong                                    EMAIL: ems @
 ccrl .
 nj .
 nec .
 com
-----------------------------------------------------------------------