RE: I-0463: Hardware Inclusion In A TOE With FPT_SEP
- Subject: RE: I-0463: Hardware Inclusion In A TOE With FPT_SEP
- From: "Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>
- Date: Wed, 17 Jul 2002 08:15:05 -0400
- Content-Type: text/plain; charset="iso-8859-1"
For those who might be interested in alternate GUIDANCE on this topic,
consult the Oracle DBMS PP from the UK. It includes FPT_SEP and FPT_RVM and
specifically excludes the OS from the TOE using assumptions about the
underlying IT environment. This approach seems reasonable and meaningful and
does not, practically speaking, limit certain requirements to a very small
percentage of security-related products.
In any case, it is not true that assumptions in a PP or ST address only
usage and connectivity. Part 1 indicates physical, personnel, and
connectivity assumptions. Part 3 indicates "The statement of TOE security
environment shall identify and explain any assumptions about the intended
usage of the TOE and the environment of use of the TOE." While the
informative part offers three topics, the normative part offers no such
restriction or guidance.
My SUGGESTION is that FPT_SEP be interpreted such that it is more useful,
such as the UK apparently did. If there is some driving need to force
hardware to be included in TOEs, then some other requirements should be
invented to dictate certain architecture restrictions.
>From Part 3 of the CC:
433 "The components of this family ensure that at least one security domain
is available for the TSF's own execution and that the TSF is protected from
external interference and tampering (e.g. by modification of TSF code or
data structures) by untrusted subjects. Satisfying the requirements of this
family makes the TSF self protecting, meaning that an untrusted subject
cannot modify or damage the TSF."
434 "a) The resources of the TSF's security domain ("protected domain") and
those of subjects and unconstrained entities external to the domain are
separated such that the entities external to the protected domain cannot
observe or modify TSF data or TSF code internal to the protected domain."
435 "FPT_SEP.1 TSF domain separation, provides a distinct protected domain
for the TSF and provides separation between subjects within the TSC."
"FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution
that protects it from interference and tampering by untrusted subjects."
These statements should not be taken to mean that the TSF must actually
implement the mechanism that provides execution domains. Rather, the TOE
must be architected (including features of its IT environment) to ensure
that the execution domain of the TSF is distinct from the execution domains
of untrusted subjects. Hence, an application-type TOE that spawns additional
processes to embody its subjects might be able to qualify for this claim
(provided that there are appropriate assumptions, or requirements on the IT
environment, about process domain restrictions that must be provided by the
IT environment). Note that the IT environment is not an untrusted subject
and is also not an "unconstrained" external entity provided that appropriate
constraining assumptions have been crafted. In general, a TSF is going to
protect itself from tampering by untrusted subjects by controlling the
services/features it offers at its external interfaces. Naturally, some TOEs
have more complex interfaces than others.
Note that this topic is disturbing because 1) it is being strongly suggested
(by the CCEVS and its reps) that hardware is required when requirements such
as FPT_SEP are claimed and 2) the CCEVS is participating in the development
of PPs for application-type (and other) TOEs and is insisting that FPT_SEP,
for example, must be included as TOE requirements. It seems as though CCEVS
and its reps to not share the same ideas. This guidance can only serve to
render FPT_SEP and any associated PPs to be largely unusable.
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org