RE: Security Policy methodologies

[Rick Smith <smith () securecomputing com>]

At 4:22 PM -0500 12/29/97, Hal wrote:

> Security of  another types of systems was defined as a correspondance
> between the target architecture and one of the OB stand alone machines.
> A complete mapping (or less formally a correspondance) was necessary to
> demonstrate a secure design (since the TCSEC security model was secure
> [by definition]  and the mapping "sound"  then the target must also be
> secure .
> This is a very interesting  headgame. ....

And if it so happens that the TCSEC model is insufficient (for example,
allowing viruses to flow from low to high) then the headgames get weird
indeed. You can end up proving a set of properties that do not achieve your
security objectives. The evaluation process is tailored to verify the
published properties. If those properties are insufficient, then results
are insufficient if you follow the process to the letter. On the other
hand, if you tailor the process to address other objectives, then you have
to construct and validate a new security model. The OB doesn't have a
process in place to do that.

In short, the top down approach is always vulnerable to changes in the
threat model. When the threat evolves (as it usually does) the system is
vulnerable again. Perhaps this is the big challenge here -- how do you
handle policy development in a dynamic environment?


Rick.
smith () securecomputing com