Kevin Lahey commented:
>
> I'd like to expand the question a little bit. We've seen months of
> discussion of the virtues of MLS (and TE) systems on the list.
Obviously
> there are plenty of people who believe that there are advantages to
> using trusted systems to build firewalls.
>
> I wonder, though, whether those advantages are significant enough
> to warrant the extra effort required to come up to speed on trusted
> systems. I can understand why people who already have trusted systems
> experience (and products) think that they have a very fine hammer
> for firewall building. I'm not sure though, that it is such a wonderful
> hammer that we all need to throw away our current hammers and replace
> them (at considerable expense).
>
> I'd like to hear from people (without previous trusted systems
experience)
> who have decided to build firewalls on top of trusted systems...
The firewalls list tends to generate technical discussion and vendors
naturally wish to promote the benefits of their particular products and
approach. That unfortunately avoids some very basic issues on which the
merits of a particular technology has to stand.
The sole function of a firewall is to provide a protective barrier between
two environments of different perceived trust. There is an assumption,
growing in popularity, that every organisation connecting its private
networks to the public domain needs a firewall.
In talking of sledghammers and nuts one does need to be able to identify
what each is - and thats risk analysis. What may be a walnut for one
person may be a hand grenade for someone else.
At one extreme, there are people who have absolutely no need to fit a
firewall between them and the outside world because the potential risks
are acceptable without moderation.
At the other extreme, there are people who should never have any form of
connection with the outside world.
In between there is every shape and flavour you could possibly imagin.
If you accept that a particular organisation does have a need to connect
with public networks, or just with some other organisation via a private
link, the potential risks generation has to be looked at.
The most human reaction is either to fit the cheapest solution, or to fit
the strongest solution, without looking at the real requirements.
Sometimes its a horrible compromise between the two.
Buying a new machine and fitting a trusted operating system, just to dump
typical firewalling products on top may not buy you anything because the
firewall products could very well subvert counters provided in the trusted
OS. That was the reason for moving TCSEC painfully from just OS
evaluations to evaluations of environments and applications and that is
one area where TCSEC is better for the novice user than ITSEC.
ITSEC allows virtually anything to be evaluated. Thats good because its
flexible and a skilled practioner has greater choice to make informed
decisions on system design. Unfortunately it does allow someone to kluge
together a cocktail of trusted products and claim that the highest
certified level of one component is what the system achieves.
TCSEC may have been a pain, but a vendor could only claim certification
for exactly the configuration evaluated, down to minute detail of printer
cables.
Dumping typical untrusted firewall products on top of a trusted OS could
result in a firewall where the door is now twice the thickness of armour
plate, but still has the three foot gap underneath that most firewalls
have and there is not even a basic lock on the back door. The only thing
which has been achieved is that a particular vendor is that much richer.
If you analyse risks adequately and conclude that you must have a link to
the outside world, you should have graded all of the perceived risks
against your specific organisation. That allows you to decide in an
objective and logical manner what your counter measures have to consist
of. That will allow you to compare those requirements with an evaluation
matrix for a particular criteria. From that you should be able to specify
what level of trust you need from components and systems and what
administrative and personnel actions are necessary.
For many people who do not even logically assess their software
applications, that is all a giant leap into the darkness. Some IT
'professionals' could require considerable retraining to be able to cope
with the concepts and some enterprises could require considerable
restructuring to operate at acceptable risk levels once the full range of
risks has been identified and ordered.
That all raises very fundamental questions.
Far too many firewalls provide little protection but they do let people
feel that the hole is not on their side of the boat. They generate
additional activity on the part of the systems administration folk who are
comfortable because the firewall is run in the same lax manner they ran
things before it went live.
Every firewall addresses only a small percentage of the enterprise risk.
Risk addressed by a firewall may have a very low impact in a particular
organisation.
Therefore a more effective firewall may only be address the same small
percentage of risk, slightly better and at a greater cost. If that is the
basis of argument, it could equally be argued that there was no cost
justification for implementing any form of firewall.
Typical untrusted firewalls have very limited ability as barriers and
virtually no ability to improve risk containment on either side. A risk
containment system which includes a barrier based on a trusted OS may
employ other trusted system techniques to provide an enterprise-wide
protection and address most of the risks rather than a small percentage.
Ian J-B
References:
|
|
