Re: PD-0091: Dependencies of Requirements on the IT Environment

["Dr.Ir. D.J. Out" <out@itsef.tno.nl>]

Ken Elliott III wrote:
> 
> I'm one of the (apparent) minority that interprets the words in CC
> Part 1 differently from previous responders on this thread.  The first
> paragraph of Part I, section B.2.6.b has two sentences, the first of
> which uses "optional".  In my opinion, the second sentence clarifies
> was "optional" means: SFRs on the IT Environment do not need to be
> included if the TOE doesn't depend on the IT environment in order to
> enforce any of the claimed functionality.  This also means (IMHO) that
> if there *is* such functionality provided by the IT environment, it
> must be specified using SFRs on the IT environment.
> 
> I believe that this is not a big burden on developers (since they have
> to run on something, and they know what properties those things have),
> and its specification is very useful to end users that want to perform
> some manner of testing or verification that the IT product or products
> that satisfy the IT environment requirements.

I'm not sure at all on this burden (having been on the receiving end).

Suppose my TOE is an application running on an OS. This OS will have to 
do some access control for me.

This means that I have to start with FDP_ACC/ACF. Is it then 
sufficiently to state just "I need ACC/ACF?, without completing most/all 
of the operations". No, that is useless. So I need to define the exact 
access control rules.
And then the next stop: dependencies. If my application users can modify 
the attributes that the AC depends on at will, that's no good. And that 
meands adding some FMT_MSA stuff (Completely filled in), and some 
FMT_SMR (completely filled in), and before you know it I have the 
complete CA-PP in my ST. And the question comes up: how sure do I need 
to be about this environment. What are the SARs?

And this OS then probably also makes assumptions on the hardware it runs 
on (more requirements), and on having Internet access to it being 
regulated (more requirements) and on I&A and on....

Then after I have written all of this down...since my OS is NT running 
on an old Dell model, I have to wonder. What good does this do me? How 
can I determine whether NT on Dell meets all these rules?

It gets even harder with smartcards: here the hardware relies on the 
software for protection (e.g. against DPA), but at the same time the 
software relies on the hardware for protection.

> The issue that Dirk-Jan brings up is interesting.  The claim appears
> to be that if the TOE runs on something that is likely not to be
> evaluated, then it's likely SFRs on the IT Environment would not be
> useful.  I think that specifying in a rigorous way (such as through
> SFRs on the IT Environment) the dependencies of such a TOE would be
> useful; perhaps as useful as if the underlying thing were evaluated.
> 
> If the SFRs on the IT Environment are specified in such cases, an end
> user can determine with high accuracy the extent to which the TOE
> relies on the underlying system, and then assess whether the risk of
> combining the TOE with the unevaluated underlying platform is
> acceptable.  If the TOE depends on one kind of functionality the user
> may decide to accept the risk, but if it depends on something
> different they may not.  Given the rigor and specificity of SFRs on
> the IT Environment, the end user may also be able to devise tests that
> would provide them with adequate assurance that the underlying product
> provides the required functions, which is a good thing.

More assurance is always better if you disregard the cost. The CC 
defines the minimum. There are a number of "mays" in there that will not 
apply to all developers, but are now forced upon them.

> There would also be the "bonus" that the evaluation team (if they are
> doing their job) would have looked at such requirements in a rigorous
> way and determined that they were accurate.  I do not believe the
> evaluation team would pay as much attention if they had to look only
> at objectives, which are almost always written in much less detail
> than SFRs.
> 
> So, summarizing, I believe that the CC requires that SFRs on the IT
> Environment be specified whenever TOE security functionality depends
> on the IT environment, and I also believe that such specification is
> useful in most, if not all, cases.

My opinion is that I see the usefulness for it in some cases, but not in 
all. An optional ASE component for it would be the furthest I'd be 
willing to go. So people concerned with integration could have it, while 
others could choose not to have it.



-- 
TNO ITSEF BV
P.O. Box 96864          tel +31 70 374 0304
2509 JG The Hague       fax +31 70 374 0651
The Netherlands         www.commoncriteria.nl