RE: New FW architecture? (longish)

[John McDermott <jjm () jkintl com>]

--- On Mon, 01 Dec 1997 15:57:56 -0500  "Stout, William" <StoutW () pios com> 
wrote:

[I'm sorry to include so much from Bill's earlier message, but it may be 
necessary to help understand where we are on this...]

> (Forgive my ramblings).

Mine, too.

<stuff deleted>

> If we forced a 'DMZ backbone' on corporations they'd puke, due to the
> need to completely redesign their network architecture.  So let's
> compact it.  Collapse the backbone into a switch.  Rack of proxy
> servers.  Security management station.  Multiport IDS box.  Dynamic
> rules.  Direct access requirement for privileged admin, remote access
> for departmental admin.  'Spanning tree' or loop detection (to prevent
> cross-departmental lines).  Here:
>
>                         
>      To management      ----------
>      bus/net     -> x---| FW & IDS|
>                         | Mgt Sys |
>    Monitor   +----------|         |--->other places as required
>      port -> |          ----------
>     -----------     x---|         |         
>     |         |---------| FW-a    |---------Department a (MIS)
>     | 'VPN'   |         ----------          
>     | Switch  |     x---|         |---------Department b 
>     |         |---------| FW-b    |         
>     |         |         ----------          
>     |         |---------|         |         
>     |Collapsed|     x---| FW-c    |---------Department c
>     |backbone |         ----------          
>     |  'DMZ'  |---------|         |---------Department d
>     -----------     x---| FW-d    |         ...etc...
>              |          ----------
>              +----------| (weak)  |
>                         | FW-I    |--->Internet 
>                         ----------

I think, in essence, this is the same concept I desribed earlier. 
Collapsing the backbone into a switch is even more effecient and probably 
more like some organizations' architectures.  [ One client of mine has a 
large corporate backbone which could esily be an 'internal DMZ', but not 
everyone is structured like that.]  As I see it, what we're trying to 
suggest here is the notion that a department cannot connect into the 
organization without a firewall of some sort.  This is good for 
department<-> Internet communication as well as interdepartment 
communication.

In some organizations, a 'rack of proxy servers' may not be feasable, 
particularly if departments (or zones, see below) are distributed over a 
wide geographic are.  In those cases some combination of a collapsed DMZ 
and a DMZ backbone may be in order.

When I teach firewall courses I find an incredible resistance to internal 
firewalls.  There appear to be two causes to this resistance: 1) cost of 
implementation and management, and 2) misunderstanding of trust.

These two issues are really one.  Medium companies tend often to trust 
everyone (if he has a badge, he's one of us...).  Very large companies 
trust virtually nobody and for them internal firewalls are a given [ take a 
large company just bought out by another large company as an example].  The 
cost of protecting against 'friends' is usually perceived as too high in 
all but the largest companies.

Once we sell the world on internal firewalls then the concept of 
distributing the trust/rules comes in.

The overall question I have to go back to is, "Does this architecture make 
it significantly easier to implement policy?" and the corollary, "Even if 
it does, does some other architecture make it even easier?"  IMHO it seems 
to make it easier, but that's only one person's opinion.

As Bill Stout said in another message (in response to Adam Safier):
> > The distributed control concepts need to be expanded further to include
> > hierarchical levels of control.  A central IC might set the high level
>
> > You're right.
> I've seen e-commerce systems designed for two levels of access, then
> patched for additional levels of access.  It would've been better if
> they used a multi-level security system from the start, and initially
> used two levels of that.  I haven't yet dwelled on 'role'/'function'
> security (set-set-set-superset) vs. the hierarchical model
> (set-subset-superset) security issue either.

I agree.  Two may look like enough on the surface: organizational and 
departmental, but in reality, especially for larger sites, multiple levels 
are necessary.  I don't see how it would be much more difficult to 
implement.

This issue of role/function vs heirarchical is interesting in this context. 
I think it must be at least somewhat heirarchical.  Consider a company with 
a large corporate headquarters and mulitple sites scattered throughout the 
world.  This company connects many of the sites to the Internet at a single 
(US) point and interconnects the HQ with the distant sites via VPNs or 
dedicated links.

The HQ site sets general rules governing, say, Internet access, but the 
remote sites set local rules.  The HQ has a policy of not interferring with 
remote site rules, so long as they do not violate corporate policy.

In such a case a role based paradigm would be nice, but some heirarchical 
structure is necessary to implement the levels of control necessary, I 
think. Correct me if I'm wrong.


> The IDS and management station could potentially be combined.  With
> enough horsepower, the group could be combined into a single system
> running multiple O.S. partions.  (Gee, this almost looks like a IBM SP
> system).  

Yeah, I think they could be, but I think, personally, that the functions 
should be distinct.  This way the combination could be a site-specific 
implementation detail.  Combining them in a design might provide 
unnecessary restrictions (or it might provide added functionality, but I'm 
not sure what that might be).

> It would be interesting if the IDS system could control the DMZ switch.

I'm not sure about "control".  Maybe the management station (I called it 
the IC before) could actually control the switch, with the IDS "advising" 
the IC.  Is there a benefit of having the IDS control the switch instead of 
going through the IC?  I do understand that this makes the IC a single 
point of failure, which I am normally against, but sometimes a single point 
of control is a benefit. [ I hate it when that happens...]

> It would be interesting if the FWs were also IDS probes (clients).

I think they probably should be.  The departmental firewalls (DIs I called 
them) seem ideal locations for IDS probes. In large organizations, there 
might be multiple IDS "servers".

> One could rename 'Department' to 'zone' so one could visualize 'zoning'
> the corporation by building, location, etc, rather than divide it along
> departmental lines.

I really like this idea of using the term 'zone'.  It needs to be clear 
that either a) zones could be nested or b) zones could be aggregated.  That 
is, we need some way of subdividing one of many buildings into multiple 
departments, for instance.

How does policy tend to be divided in your (the list's) experience?  Mine 
favors departmental, but that may not be the case always.  Regardless, zone 
is a less restrictive term.

> The Internet firewall could be more than one for high bandwidth/failover
> needs.

Of course.

> BTW - I do like the idea of making the IS department an internal ISP.
> That potentially opens a whole new competitive market of service
> providers who might be able to provide better service than an IS
> department.

[BTW, This seems to wrap around to the discussion of outsourcing in another 
thread.]  So are you suggesting that ABC corp might hire Joe's Internet 
service to run their internal net?  That is an interesting idea.

> Bill Stout
>
> PS - John McDermott's idea of CI, DI, OI nomenclature is good, but I get
> confused too easily by multiple terms.

Thanks.  What I dislike is using one term for multiple things 
(overloading), so I thought these terms might make discussion easier.

>

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