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

[John McDermott <jjm () jkintl com>]

--- 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
-------------------------------------