RE: New FW architecture? (was RE: Time for a new FWTK?)

["Safier, Adam (GEIS)" <Adam.Safier () geis ge com>]

The distributed control concepts need to be expanded further to include
hierarchical levels of control.  A central IC might set the high level
corporate policy for each department but then each department needs an
IC, or limited access to the IC, to control it's own rules.

Case:  An ISP insists on valid source addresses and no SYN attacks.  A
business using that ISP sets a policy that all users must use IPSec to
the Internet, one time authentication mechanism and all users must be in
the employee HR database or "partners" database, and blocks HTTP.  The
departments actually assign department group access permissions and can
block departed employees/partners from accessing the department subnet,
even though the employee may have simply moved to another department.
The employees' manager can assign access to specific hosts, permitting
only telnet, and block that access when the employee moves out.

Adam

---------------
Adam Safier,  Network Engineering Security Consultant
GE Information Services, Inc.
401 North Washington St., Rockville, Md. 20850
Ph: 301-340-5737    Internal: 8*273-5737   Fax: 301-340-4005
Adam.Safier () geis ge com        http://www.geis.com

The opinions above may not be shared by my employer.
---------------



> -----Original Message-----
> From: John McDermott [SMTP:jjm () jkintl com]
> Sent: Saturday, November 29, 1997 3:20 AM
> To:   'Firewall-wizards'; Stout, William
> Subject:      New FW architecture? (was RE: Time for a new FWTK?)
>
>
> --- On Wed, 26 Nov 1997 13:05:16 -0500  "Stout, William"
> <StoutW () pios com> 
> wrote:
>
> <stuff deleted>
> > ...  The next step up for
> > Wheelgroups' IDS system was to dynamically adjust the filter rules in
> a
> > firewall (NGC Borderguard/NetSentry).  You can control a group of
> > firewalls with an IDS 'non-proprietary standard' and NFR.  
>
> > Gee, if corporate has an IDS system, and you can figure a way to
> control
> > firewalls that way, you can then implement corporate dictatorship
> over
> > departmental firewalls.  Maybe even delegate or offload a subset of
> > control to the departmental admins.
>
> This sounds like a good mostly-new paradigm.
>
> > Hmm, that would do some fine-detail of control.  Protocol and
> > application control on a per departmental basis.  Security by
> > compartmentalization, aka 'zoning'.
>
> This sounds very useful, especially in larger organizations.
> > A corporation would have a semi-open DMZ 'backbone'.  This would put
> an
> > IS group into the ISP and 'service provider'-server (SQL, App, etc)
> > business for the corporation.  Departments could buy their own
> > firewalls, and corporate can dictate that a firewall must be used for
> > backbone/internet access, and that firewalls meet the NFR standard
> for
> > centralized control and IDS.
> >
> > Another thought.  AFA 'expert analysis', that can be put in a central
> > box, and the departmental firewalls could in effect, ask the dictator
> > box, "Is this O.K. to pass?".  Client/server distributed firewall
> > architechture.  NC firewalls.  Other proxy people responsible for
> 'suck
> > brain-damaged protocols'.
>
> OK, Here goes somewhat of a formalization of this (maybe I changed it
> a 
> bit, maybe not) so we can talk more about it.  This is intended as a 
> starting point for discussion.
>
>
> Here is a sample structure (abbrevs below):
>
>                               [Department B computers]
>                               |
>                               DI        DI---[Department C computers]
>                               |         |
> Outside--Router--DMZ*--OI=====================
>                            |       |
>                            IC      DI
>                                    |
>                                   [Department A computers]
>
> Components
> Outside       The outside network, maybe, e.g. the Internet
> Router        The border router for the organization
> DMZ   (optional, perhaps) Similar to today's DMZ
> OI    Organizational Interconnect. Connects an organization to the
>       outside possibly via a DMZ.  This is similar to today's bastion
>       host.  It may be proxy based or it may be a stateful filter.  It
>       may even be something new. Could be a "dedicated box" such as
>       routers are today.
> DI    Departmental Interconnect. This is also like today's bastion
> host,
>       but connects a department to the 'semi-open DMZ backbone'
>       (=== above).
> IC    Interconnect Controller.  This is Bill's 'central box'.  This 
>       computer controls the OI by providing filter rules (for lack of
>       a better term) and the DIs by validating their filter rules (or
>       by downloading rules to them).  The IC also includes some
>       monitoring and detection of intrusion. This is
>       possibly (see below) the only true "host" on the backbone.  
>
> Some thoughts:
> 1. In a large organization, with departments and subdepartments, a DI
> on 
> the organizational backbone could be a OI as far as a department was 
> concerned and DIs could be interconnects for subdepartments.  In other
>
> words, the structure could be heirarchical.
>
> 2. Some protocols would need to be developed to communicate rules
> between 
> the IC and OI/DIs.  It would be Real Nice if these were open
> protocols, but 
> designing them might be "difficult".
>
> 3. The DMZ could be omitted and those services placed in a DMZ now
> could be 
> placed behind a DI.  [Or one could choose some other architecture in
> common 
> use: connecting the DMZ to the router or OI, for example.]
>
> 4. Some research would have to be done in how to validate DI rules.
> These 
> rules could a) refine rules in the OI (by, for example, providing
> extra 
> restrictions on web sites accessible by the department, or eliminating
> web 
> access altogether) and/or b) create access not allowed by other 
> departments. This is more tricky.  A policy could be "Department A is
> the 
> only department allowed to use RealAudio".  In this case the backbone
> would 
> have to carry RealAudio (the OI would have to allow it), but only A's
> DI 
> would allow it to pass.  That means that Department B would not be
> allowed 
> to reconfigure its DI to pass RealAudio.
>
> 5. The key here is whether or not this makes policy implementation
> easier.  
> It seems to because or the greater control.  Also it provides another
> layer 
> of depth, which is good in general.
>
> 6. It seems at first glance that the OI contains the union of what is 
> allowed for all departments.
>
> 7. Since the IC controls configuration of the OI and DIs, some 
> authentication between the IC and OI/DIs is in order.  At least
> IPSEC's AH.
>
> 8. The entire backbone could easily be encrypted.
>
> 9. Some servers could be on the backbone, but that may be risky.
>
> 10. The DIs could either do filtering autonomously or ask the IC about
> what 
> to allow.  That latter is Bill's 'dictator box' scenario.
>
> 11. The DIs (or other hosts within the departments) need to do some
> traffic 
> watching as does the IC. 
>
> Anyway, I offer this as a starting point for discussion.  I just
> thought 
> I'd try to formalize my interpretation of Bill's message. 
>
> > Bill Stout
> --john
>
>
> -----------------End of Original Message-----------------
>
> -------------------------------------
> Name: John McDermott
> VOICE: 505/377-6293 FAX 505/377-6313
> E-mail: John McDermott <jjm () jkintl com>
> Writer and Computer Consultant
> -------------------------------------