Re: firewalls and the incoming traffic problem

[mcnabb () argus-systems com (Paul McNabb)]

>  From: Jeromie Jackson <jeromie () garrison com>
>  
>  At 10:22 PM 10/1/97 -0500, Rick Smith wrote:
>  >On the other hand, we *do* face an integrity problem, which brings us back
>  >around to the start of this discussion thread. This is where MLS comes in
>  >handy -- since a "higher" level isn't allowed to modify files belonging to
>  >"lower" levels, you place the big bad Internet at a "higher" level and
>  >install the files you don't want modified at a "lower" level. This lets the
>  >Internet processes read the executable files and the configuration files,
>  >but prevents them from modifying them. This is sort of using Bell LaPadula
>  >to implement Biba, if you see what I mean. And, of course, it all works
>  >much more cleanly with Type Enforcement (tm).
>  
>  I would also inject that Sidewinder uses independant "domains" for each of
... clipped ...

>  In another note, the National Information Assurance Partnership (NIAP)
>  currently has a single level for firewall assurance.  Since a few firewalls
>  in the market deploy DTE or other MAC based mechanisms, this is truely an
>  injustice.  Comparing the compartmentalization between DAC only, and those
>  products containing DAC & MAC obviously there are levels of security.  I
>  hope that others will agree, and express their opinion to the working
>  group.  I am working on a paper for submittal in hopes to change this
>  obnoxious flaw in their ratings.  It is not fair to the commercial
>  community to not have some showing within the NIAP firewall profile that
>  there are a range of security levels.  Firewalls do not all have the same
>  level of assurance, or compartmentalization of vulnerabilities.

I agree.  Argus has done the same thing with Checkpoint's firewall.
We have it running on B1 Solaris boxes (both x86 and SPARC) with
various parts in different compartments.  We have a second hardened
firewall set using the Decaf product -- it does compartmentalization
but not using the Bell LaPadula model.

Although these extra security measures can be significant under some
configurations (but not all), they are seldom if ever reflected when
someone is assigning a security "certification" to the end product.

paul

---------------------------------------------------------
Paul McNabb                     Argus Systems Group, Inc.
Vice President and CTO          1809 Woodfield Drive
mcnabb () argus-systems com        Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433                "Securing the Future"
---------------------------------------------------------