RE: I-0451: When To Use IFF/IFC And ACC/ACF

["Daniel P. Faigin" <faigin@solarium.aero.org>]

On Thu, 21 Nov 2002 11:56:41 -0800, "Knoke, Jim" <Jim.Knoke@getronicsgov.com>
said: 

> I would prefer if the wording of this interpretation shed more light on
> whether an "in-between" policy should be defined as IFC or ACC. For
> example, if I have a policy where objects have a "domain" and subjects
> have a list of accessible domains, a subject could read
> container/information from one object and then write the information to
> an object with a different domain. This looks like ACC in that the
> attribute of the information does not necessarily stay with the
> information, but it looks like IFC in that the subject is very
> restricted in which domains it can write the information.

Although I'm sure this will be discussed at the next NIB meeting in February,
I think it is very important to remember that this is NOT the TCSEC. One is
not constrained to shoehorn a particular policy into a component where it
doesn't really fit. If it is not quite IFC or not quite AFC, then don't try to
squeeze it in. Write an explicitly specified component that clearly states
what the policy is to be, and to what it is to apply.  Remember that clarity
of specification is much much more important than fitting something into an
artificial category.

[And this applies no only to your question, but many of the other questions
recently that try to shoehorn existing implementations into some
component. The CC teaches us to work from the needs down: to define the
threats, assumptions, etc., let those drive the security objectives, and from
there determine the protections to be implemented. Don't let your products be
hardware/software looking for a solution; find a problem that hasn't been
solve (or that you can solve better), and let your product solve it.]

Daniel