RE: Application TOE SFRs

["Michelle A. Ruppel" <maruppel@saffiresys.com>]

I agree with Jim's opinions below.
Jim, Sorry I don't have any different opinions to offer you.


-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Arnold, James L.
Jr.
Sent: Friday, September 17, 2004 9:33 AM
To: Multiple recipients of list
Subject: RE: Application TOE SFRs



Let me follow up with some more data. Note that I am particularly interested
in other opinions about whether TOEs embedded in other IT products should be
able to claim SFRs as stated in the CC. 

CC Facts (as opposed to opinions):

1) A significant part of a TOE's security can be achieved through
organizational, personnel, physical, and procedural controls - such security
measures are treated as Secure Usage Assumptions where they have an impact
on the ability of an IT security measure to counter identified threats.

2) Dependencies define a relationship where the depending requirement cannot
usually meet its security objectives unless the dependency is satisfied.
Dependencies on the IT environment are specifically supported within the CC
(without apparent limitations).

3)  A TOE is responsible to substantiate its claims only at its own
interfaces (i.e., the TSFI). 

These facts are readily evident in the definitions and other text scattered
throughout the CC. I am unaware of conflicting CC statements on these
topics, but it seems as though decisions are being made contrary to these
basic CC concepts. In particular, it is claimed that there can be no
reliance of the TOE on another product to meet a claim and that a TOE must
answer for the potential of its IT environment (which is likely trusted by
CC definition) to allow the TOE to be attacked.

However, there is nothing in the CC that states that the TOE has to meet its
requirements 100%. Rather, the CC states that SFRs must be substantiated
within the TOE and its TSFI and that the TOE can make significant
assumptions about and impose requirements on its environment that must be
met in order that it can meet its own objectives. 

Similarly, there is also nothing in the CC to indicate that the TOE must
defend itself from its 'trusted' environment components. 'Trusted' IT
environments certainly do not represent 'untrusted subjects' (per
FPT_SEP.1), for example. And while it has been argued that the TSF must
include all software, firmware, and hardware that must be relied upon for
the correct enforcement of the TSP, it seems the caveat 'of the TOE' is
being ignored. In other words, the TSF are those parts of the TOE that must
be relied upon to enforce the TSP, leaving open the possibility that other
non-TOE components (presumably trusted) might be needed to support the TSP
(such as an underlying operating system).

The net result here is that it is critical to clearly, accurately, and
completely define the TOE since all claims are relative to the TOE. Without
a clear, concise understanding of the TOE, it is unlikely that claims about
it can truly be understood. It is quite simply not the case that all claims
(with the same words) always mean the same thing. Any SFR could be
implemented in a probabilistic manner and might be subject to different SOF
claims. Alternately, the set of subjects, objects, operations, services,
etc. can vary substantially among TOEs with the same claims.

In any case, given that the U.S. Scheme has been making more and more
decisions about which requirements can be claimed by applications or in the
absence of hardware, I am concerned that understanding of the CC is
diminishing or has been lost. And I am particularly concerned about the
potential direction of v3 of the CC.

----------------------------------------------------------------------------
--------------

Based on the CC itself, it is perfectly reasonable (and the CC even seems to
intend) for an application to claim virtually any SFR defined in the CC. 

In the case of FPT_SEP.1, the application is expected to explain how that
requirement is met within the TOE and the TSFI, but the TOE is free to
demand of its environment that it also protect itself (indirectly assisting
the TOE in protecting itself). This seems reasonable to me, since the CC is
clear that IT environment requirements and assumptions about the environment
need to be true in order for the TOE to be secure.

In the case of FPT_STM.1, it has been claimed that hardware is required
since that is the only possible source of time. However, the notion of
reliability is up to the ST/PP writer. In at least one U.S. gov't PP it is
claimed that reliability is related to the ability to sequence events. As
such, it seems an application could readily instill reliability into an
arbitrary time stamp simply by comparing each time with the previous time to
ensure it is always increasing.

How about FIA_SOS.1? While an OS might perform authentication for an
application, the application could collect a user id and password to be
submitted to the OS for verification, but could additional impose delays and
also impose password construction requirements (e.g., length and
composition) beyond those required in the OS. Note that based on the CC, I
would claim that an application that simply assumes a user has been
authenticated by the OS and accepts any request cannot claim authentication
for the TOE. But if the TOE actively requests authentication services of the
OS (which must be represented in an IT environment requirement) then the TOE
can claim authentication at its interfaces.

What about FAU_STG.1? While an application might store audit records in an
OS file (along with its own binary code and configuration data), it can
claim this requirement if it offers appropriately controlled access to the
audit records via its own TSFI. Again, there would likely need to be
requirements asserted on the IT environment to support this. On the other
hand, if the TOE simply dumped the audit data into the IT environment and
offered no access to the audit data, then it should not be able to claim to
protect the audit trail. Note that there are many CC requirements of this
nature that should be handled in a similar manner.

While it has apparently been suggested that the clause 'initiating actions
through its own TSFI' should be added to SFRs (allegedly rendering them
explicitly stated) claimed by application TOEs, I think there are two
problems. The first is that all TOE requirements are evaluated against the
TSFI and as a result every requirement effectively implies this already. The
second is that, as a result of the first issue, this is actually simply a
refinement and not an explicitly stated requirement at all. However, it is
not clear to me why this should not be applied to monolithic TOEs as well.
After all, most of them don't protect themselves at non-TSFI interfaces such
as physical access might allow.

I tend to think a common problem related to this topic is that TOEs are
often not well and clearly defined. This should be addressed in evaluation
of the TOE identification, but should not drive misuse of SFR claims. Also,
if it is believed that users don't understand that assumptions and IT
environment requirements need to be addressed, perhaps some education is in
order since I believe that a clearly stated external assumption or
requirement is much better (as it is more direct) than to subtly change the
words of some SFR claim or TSS statement to imply those assumptions or
requirements.

Note that if it is truly believed that users don't understand about
assumptions or environment requirements, I wonder why one would assume that
a user would understand subtle SFR changes? Similarly, I tend to think that
things like explicitly stated requirements, interpretations of various
flavors, similar products making different claims, etc. are also culprits in
spreading confusion.