Padgett writes:
>Reasonable question. The problem with a multilevel protection at the firewall
>is that the external gateway is not a good place to try to separate comingled
>functions e.g. HR and Finance on the same backbone. If instead the separation
>exists between equally trusted/equally untrusted levels then a binary function
>works, for multilevel networks the only real answer is encryption.
Yes, this is a very interesting question: Should you run unsecure traffic on
secure networks, should you run secure traffic on unsecured networks, and is
there any advantage to doing both at the same time?
So, this is not a good idea (unless using secure traffic):
--------- secure net A info only
|
Comingled info --------[ BOX ]----- secure net B info only
|
--------- secure net C info only
whereas this is one solution to consider:
Outside --- [ext fw] - [net A] - [int fw] - [net B] - [int fw]- [net C]
| |
---------------------------------
Here, net C could be finance, for example.
This can be considered in case you use encryption:
Type A machine Type B machine Type C machine
| | |
Outside -- [ext fw] -------------------------------------------
| | |
Type C machine Type C machine Type A machine
where type Z machines can en/decrypt only traffic running on the virtual Z
network.
I like the virtual secure network idea, which you obviously also recommend,
very much. Have you ever tried to implement this setup in real life? What's
involved in terms of e.g. en/decryption overhead? The more I think about
this the better I like it: Very high virtual fences with strictly controlled
gates, things to which I'm quite partial :). If correctly set up and
enforced this philosophy should also be able to solve the eternally
discussed problem of catching vira attached to mail, because the encryption
process on the internal nets can be totally centrally controlled, meaning
that the only way to ex/import data is through gateways that can be secured
as required. Nifty...
>You mean like changing the third byte in the FBR from a 90h to "something
>else" so that DOS refuses to read it ? Change "BATCOMEXE" to BBBCCCEEE ?
>Wouldn't know about that 8*).
A bit more elaborate, I'm afraid. Ever since I first attached a (8") floppy
drive to my Rockwell M65 microcomputer in 1979 thorugh a 6522 VIA component
(integrated floppy controllers were not yet available, or I couldn't aford
one, I no longer recall which), and wrote a suitable file handling system to
control it, I have derived a perverted pleasure from re-arranging the way
info is stored on floppies :-). Incidentally, the little Rockwell computer
first had a large Revox tape recorder as its mass storage device, because
the Revox had a plug allowing you to control it be means of relay switches.
And it had 4 kB of RAM. Later I upgraded it to 32k and wrote a full-featured
floating-point math library for it. Apologize for rambling. Seems to come
with age...
Rgds,
Niels
Follow-Ups:
|
|
