RE: TCSEC and firewalls

["LeGrow, Matt" <Matt_LeGrow () NAI com>]

> -----Original Message-----
> From: Magosanyi Arpad [SMTP:mag () bunuel tii matav hu]
> Sent: Monday, June 28, 1999 4:08 AM
> To:   firewall-wizards () nfr net
> Subject:      TCSEC and firewalls
>
> Hi!
>
> I have just read the TCSEC interpretation for a networked environment.
> (The document called NCSC-TG-005)
My condolences :-)  I'll bravely step forward and offer some interpretation,
having skimmed Red and Orange once or twice a few years back....

> There are some questions left (maybe I was not read carefully enough):
>
> -What is the DAC functionality regarding a firewall? Is the ability of
> the firewall administrator to define the access list for a communication
> channel is the DAC functionality? Or is it completely outside the
> scope of network perimeter defense?
Discretionary Access Control (as I understood it) involves more or less the
partitioning of privilege.  If you want to abstract the concept then you
could simply regard it as the privilege of turning a stream on or off
depending on how hard you squint.  As for partitioning, through firewall
proxy filtering you have the flexibility to partition privilege even on a
communication channel.  For example, you can turn off particular FTP
commands such that individual users can only perform certain operations
through the proxy depending upon the privilege given to them by the policy.

The firewall doesn't have to be outside of the scope of the defense, on the
contrary I would assume that it would be a major part of enforcing an NTCB
policy.   Remember a NTCB consists of multiple elements that work to enforce
the totality of the NTCB, even if each *particular* element does not adhere
to all policies enforced by the total NTCB.   

> -Is it sensible for a data to have different labels in different points
> of the transmission path depending on the properties of the transmission
> medium?
That depends on whether or not you are passing your traffic through
untrusted areas, in which case its sensible but complicated.  I don't see
any other reason to mess with the labeleing, wouldn't that undermine the
integrity of the NTCB anyways?  BUT If all parts of your NTCB are working
together to enforce the policies of the whole than data labeled "sensitive"
would be recognized as such and would either be dropped completely before it
enters inappropriate areas of the network or not get sent there at all.

> -How would you define the MAC labels' non-hierarchical categories part
> in a corporate environment? Should they refer to the organizational units?
> Should they refer to some aspects of the IT infrastructure (and then how
> they
> glued into a comprehensive representation in the level of the corporate
> NTCB)?
If I understand what you are asking here, its probably sufficient to
categorize them as you see fit in the total model.  If you  want more
granularity its probably easiest to use the aspects of the organizational
units since they will probably be how you define access in general anyways.

> -There are only vague references to cryptography in the document. How
> should
> I express (in the terms of TCSEC) the need that the protection of the 
> transmitted data should be proportional to its sensitivity label in the
> whole transmission path either by cryptography or phisical security?
This was a problem for me as well - I could never understand why there
wasn't more detail.  I believe its because TCSEC is designed with
partitioning of privilege to attain security in mind more than obfuscation.
Maybe they realized how fast computational technology was advancing and had
the foresight to realize it would be infeasible to enforce encryption as
part of any security policy.


Just a personal rant here, I made an attempt (and a very lackluster one, at
that ;-) at an independent study in college to define TCSEC concepts in
terms of commercial firewall policy.  The problem is the spec isnt very
well-written or coherent, and most people that implement Secure OSes or
networks ignore TCSEC as antiquated and irrelevant anyways.  TCSEC OS
certifications for example, limit the certification to a particular
installation and revision of the OS running on specific hardware.
Additionally, if you are connecting to a public data network like the
Internet, you have to take the time to ensure that your entry points don't
violate the spirit of the NTCB.  So you don't really get the flexibility
that you generally need in the heterogenous and often ad hoc corporate
network.  

This is not to say that TCSEC concepts like DAC or MAC aren't useful at an
OS level - Linux, for example, implemented a subset of Posix capabilities
which work towards achieving this goal.  And the NT OS security model uses
data labelling to define user privilege on the local machine and the
network.

If you're using TCSEC as a general guideline for an abstract way of looking
at the network and designing it securely thats a different matter and it
might be useful.   But its much easier to simply define a coherent and
complete security policy based upon hard realities such as users and
services and protocols than attempt to adhere to the nonsense in the
"rainbows."   If you have a firewall capable of adhering to policies (99% of
the current market) you should have no problem translating that directly
into practice.

In any event - good luck and hope my blathering helped!

Matt LeGrow
Network Associates,Inc