RE: FPT_SEP in an Application TOE

[Nir Naaman <nir.naaman@metasec.com>]

On Monday, October 25, 2004 Yokota Hirofumi wrote:

> Do you find values in the following assumptions?
> 
> - The TOE is physically protected.
> - The administrator is trusted.
> - The users will be trained sufficiently in order to operate the TOE.
> 
> There might be a bit.
> But, who does worry when those descriptions are removed from
> the ST? Those assumptions look just bothersome formality.
> 
> Similarly, it is difficult for me to find values in the
> following threats, when they are translated from assumptions.
> 
> - The TOE might be physically attacked.
> - An untrusted administrator may violate the security of the TOE.
> - Untrained users may misoperate the TOE.
> 

There is value in defining such threats, traced to security objectives for
the environment, in order to clearly state what security problems the TOE
does NOT solve. Nobody is under any illusion that any TOE provides total
security, but sometimes TOEs do not provide security functionality that you
might expect them to if you read the TOE description. For example, a smart
card without physical tamper resistance, a firewall that does not claim
protection from bypass, tampering and interference (doesn't claim FPT_SEP
and FPT_RVM), a consumer operating system that is not designed to withstand
attack potentials rampant on the Internet, etc. There is a market for each
of these, but the ST should make it clear that these threats are not being
addressed by the TOE.

> I tend to see values of threats when they are written
> specific as the following.
> 
> - The log records may lost when the size of log records
> exceeded the available disk space.
> - The administrator may forget to start log function, then 
> the log records might not be saved in the disk space.
> 
> The CC does not mandate the level of detailness of threats
> description. This means that they are useful or not is 
> another matter from they are successfully evaluated or not.
> 

You should take note that the CC has changed in this regard from CCv2.1 to
CCv2.4 and beyond. CCv2.4 threats are a function of threat agent, protected
asset, and an adverse action performed by the threat agent on the asset.
Attack methods and vulnerabilities have been taken out of the Security
Problem Description (they're still relevant for the vulnerability analysis,
though). Although you have some flexibility in qualifying the threat agent
(in terms of motivation, proficiency, opportunity, and resources), I think
this really means that threat statements should be much more abstract than
your given examples.
(Another point - I hope the log you're describing is a protected asset, not
an artifact of the TSF implementation - for FAU_GEN. It is not good form to
describe threats to the TSF.)
Threats and OSPs make up the SPD. The SPD is essentially a statement of
security policy that must be enforced by the TOE. Threats are a statement of
what interactions should NOT be allowed to occur; OSPs are more flexible
because they have an informal syntax, and can describe either interactions
that MUST occur or that should NOT.
Threats are NOT at the same level of abstraction as vulnerabilities. See
http://easyweb.easynet.co.uk/~iany/consultancy/needs_or_specs/needs_or_specs
.htm for an enlightening discussion.
I've found that consumers are very happy with the more abstract CCv2.4 SPD,
because it is something that the system owner can deal with. It focuses on
the business assets and what may or may not happen to them, as a function of
threat agent. It is up to the technical people to make sure that these
business needs are satisfied by the system. Evaluators have the role of
trusted (third-party) security experts - they are employed to ascertain for
the consumer, to a given level of assurance, that the SPD is "solved" by the
TOE.


On Tuesday, October 26, 2004 Yokota Hirofumi wrote:

> I prefer that the threats are purely related to the TOE( the 
> functionality and the usage), not to the operational and 
> development environment.
> 
> Althoug the Part-3 assurance requirements might be deduced 
> from hundreds of each specific threats, and it seems 
> theoretically true and structurally neat that those threats 
> are listed in the ST, I oppose that. They would cloud the 
> focus on the interest of the final recipient of the ST (e.g. 
> consumers and integrators ).

To the consumer, all threats to business assets are relevant, throughout the
TOE lifecycle, from development, through deployment, operation, and
maintenance. I believe many of the Part 3 security requirements are not
really "assurance" requirements, but functional requirements that are
allocated to lifecycle phases other than development. I use the following
rule-of-thumb: if a requirement "improves" your security, it is functional.
If it is intended to provide grounds-for-confidence that the TSP is
enforced, then it is an assurance requirement. With this thought in mind, it
does make sense to trace functional Part 3 requirements to the SPD. However,
OSPs are a powerful tool you can use in the SPD for this purpose; P.EAL4+
says it all.

   Nir