From: Frank Willoughby <frankw@in.net>
Date: Wed, 24 Jan 1996 14:01:14 +0800
To: Ben <adept@minerva.cis.yale.edu>
Subject: Re: IPSEC == end of firewalls
Message-ID: <9601240513.AA22267@su1.in.net>
MIME-Version: 1.0
Content-Type: text/plain


At 06:56 PM 1/23/96 -0500, Ben <adept@minerva.cis.yale.edu> allegedly wrote:


>Because this has Cpunks relevance in the use of crypto, I'm going to keep 
>it on this list...
>
>> remain relatively secure.  However, I am I'm not saying that adding
>> firewalling capabilities would make the system invincible.  I *am* 
>> saying that it would provide the system with more security than it 
>> currently has and would help to reduce (not eliminate) some risks 
>> associated with networking.  
>
>But what does it mean to add 'firewalling capabilities' to an O/S?  By 
>definition, a firewall is supposed to stop the spread of 'fire' by being 
>the sole mechanism for the interchange of packets.

Essentially, adding protective mechanisms that would filter incoming 
network connections (incoming to the O/S) rendering potential risky
connections harmless or rejecting them.  Steve Bellovin has a very 
well-written paper called "Security Problems in the TCP/IP Protocol
Suite" which addresses a number of these.  If memory serves correctly
at this late hour (midnight), then it can be ftp'ed from research.att.com
and it is in the /pub/dist/smb directory (or somewhere around there).



>If you're referring to making a hardened OS that can protect itself 
>through the use of well written code, memory protections, etc. then, yes 
>by all means add it to your OS, but these shouldn't be luxuries in that 
>they're thought of as 'firewalling' features.  Rather these things should 
>be compulsory in the development of OS's.
>

I agree with you 100%.  Eventually, I think the market will demand it and
the vendors will have to begin delivering hardened O/S's.



>> Of course, it would be terrific if the vendors would produce Operating 
>> Systems which are secure AND usable.  (I think the market will eventually 
>> demand this from vendors, but this probably won't happen in the next year 
>> or two.)
>
>Even if OS's could be secure(lets not get into Orange Book here) they 
>would need constant updating.  Most users have problems printing, let 
>alone installing patches and tweaking afterwards to deal with conflicts.  

Good points.  As stated above, the systems should be secure AND usable.


>And you can't expect IS to micromanage the corporation's entire fleet of 
>machines.

True.  However, the systems can be monitored for compliance to Corporate
Security policies and the non-compliant (read insecure) systems can be
quickly brought back into compliance - frequently using automated scripts.

NOTE:  Implementing a high level of Information Security should be as 
user-friendly, as non-intrusive to business operations as possible, and
as cheaply as possible.  (Yes, it is possible to achieve all three objectives).


>This would be nice, and would be a good start, but like I said above, 
>these things shouldn't be considered to be luxuries.  Rather they should 
>be compulsory.  That doesn't mean that they will obsolete firewalls by 
>any stretch of the imagination.

I agree with you 100%

Nice posting, BTW.  (And not just because I agree with you).  8^)


>Ben.


>(I'm starting to think Frank may have been right to move this to 
>firewalls.  I think I'll crosspost this message too)
>____
>Ben Samman..............................................samman@cs.yale.edu
>"If what Proust says is true, that happiness is the absence of fever, then
>I will never know happiness. For I am possessed by a fever for knowledge,
>experience, and creation."                                      -Anais Nin
>PGP Encrypted Mail Welcomed        Finger samman@suned.cs.yale.edu for key
>Want to hire a soon-to-be college grad? 		Mail me for resume
>
Fortified Networks Inc. - Management & Information Security Consulting
Phone: (317) 573-0800   - http://www.fortified.com/fortified/

<standard disclaimer>
The opinions expressed above are of the author and may not 
necessarily be representative of Fortified Networks Inc.