RE: I-0461: Definition Of TSF: Relied Upon For The Correct Enforcement
- Subject: RE: I-0461: Definition Of TSF: Relied Upon For The Correct Enforcement
- From: "Knoke, Jim" <Jim.Knoke@GetronicsGov.com>
- Date: Thu, 21 Nov 2002 15:54:57 -0500
- content-class: urn:content-classes:message
- Content-Transfer-Encoding: 8bit
- Content-Type: text/plain; charset="us-ascii"
- Thread-Index: AcKM6dM8yO8X3m5MRzOyZ2/t5SPnzwEtajLw
- Thread-Topic: I-0461: Definition Of TSF: Relied Upon For The Correct Enforcement
Should the wording be generalized to address which TOE components must
be included in the TSF, or to address which assurance requirements apply
to a component only if the component is part of the TSF?
> -----Original Message-----
> From: NIAP Interpretations Board [mailto:firstname.lastname@example.org]
> Sent: Friday, November 15, 2002 3:55 PM
> To: Multiple recipients of list
> Subject: I-0461: Definition Of TSF: Relied Upon For The
> Correct Enforcement
> This transaction consists of a proposal for a NIAP
> Interpretation of a
> Common Criteria document. It is being posted in accordance with the
> procedures of the IWG.
> Comments on this proposal are welcomed and should be posted to this
> transaction chain. If any party wishes to post a comment
> the comment should be mailed to email@example.com in a form
> suitable for
> posting. All comments should be posted no later than
> Monday, January
> 27, 2003.
> CCITSE/CEM GUIDANCE (PROPOSED)
> I-0461: Definition Of TSF: Relied Upon For The Correct
> TYPE: Guidance
> NUMBER: I-0461
> STATUS: Ready for External Review
> TITLE: Definition Of TSF: Relied Upon For The
> Correct Enforcemen
> COMMENTS DUE BY: Monday, January 27, 2003 to firstname.lastname@example.org
> SOURCE REFERENCE: CC v2.1 Part 1 Subclause 2.3
> RELATED TO: <None>
> In the definition of TSF, what does the phrase "relied upon for the
> correct enforcement of the TSP" mean? What is the
> interaction of this
> phrase with respect to FPT_SEP and FPT_RVM: in particular, does
> "relied upon" have any implications with respect to
> or benign-ness.
> The phrase "relied upon for the correct enforcement of the
> TSP" means
> that the failure of a particular SFR cannot result in a bypass of a
> TSP enforcement mechanism, based on the knowledge available at the
> time of evaluation.
> There are two aspects of this question. The first revolves
> around the
> definition of the term "TSP". The second revolves around the
> definition of reliance.
> The TSP is defined as the "set of rules that regulate how
> assets are
> managed, protected, and distributed within a TOE.". Asset
> rules are covered under FMT; and asset protection under
> classes such
> as FAU, FIA, FDP, FCS, FPR, FTA, and FTP. FPT is a mixed
> bag: whether
> a particular rule falls under the protection category varies.
> Distribution rules are unclear.
> Turning to the question of reliance. Websters' has two
> definitions for
> "rely": to be dependent, and to have confidence based on
> Although the latter might apply to the assurance aspects
> of a system,
> the former appears to be more applicable.
> It is clear that the enforcement of rules depends on the correct
> implementation of those mechanisms that underlie classes
> such as FDP,
> FAU, or FIA. Again, FPT is unclear.
> The components in FPT can be divided into three groups:
> 1. Those that explicitly provide a protection function
> for TSF data.
> Examples of these are FPT_ITT or FPT_ITC. This class is clearly
> part of the TSF.
> 2. Those that verify the TSF or its platform is operating
> FPT_TST and FPT_AMT are examples of these. This class may fall
> into "support" code, and is explored in I-0453. Note that the
> components in this category, at the time of evaluation, can be
> analyzed to be working correctly. However, they may identify an
> unanticipated hardware or software failure later
> during operation.
> 3. That that ensure the enforcement of functions "behind
> the scenes".
> FPT_SEP and FPT_RVM are examples of these. This class is the
> source of problems.
> To explore the issue further: If FPT_SEP or FPT_RVM
> failed, would the
> protection mechanisms be enforced? After all, if their
> failure would
> cause enforcement to fail, then said enforcement is
> dependent on the
> In the case of FPT_RVM, enforcement would fail, for the failure of
> FPT_RVM would imply there are circumstances where the enforcement
> function is not invoked, indicating that enforcement is bypassed.
> If the case of FPT_SEP, whether or not enforcement fails depends on
> whether software takes advantage of the vulnerability in the TSF's
> protection to bypass it. Hence, if FPT_SEP is present, one needs to
> have confidence that either the mechanism is working, or
> none of the
> software in the TOE is malicious.
> To know that the FPT_SEP mechanism is working means knowing that no
> software can go around or disable the mechanism. If
> analysis can show
> that the design of the TSF precludes any ability to go around the
> FPT_SEP mechanism, there is no requirement to show
> in the code. However, if the design of the TSF is such that the
> potential exists to violate FPT_SEP, then it must be shown that any
> code with the potential is non-malicious.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com