Re: Categorisation of SFRs for the TOE and for the IT environment
I think that formally, in CCv2.1 you cannot create a PP that has
objectives or SFRs that can be assigned to the TOE or the environment in
Application Notes are intended to provide additional information notes
and not allowed to change the criteria themselves.
The refinement is also illegal (it fails work unit ASE_REQ.1-12 item c)
One of the ideas that did not make in CC v2.4 (the proposed new ASE/APE)
would be to have "unassigned security objectives" in a PP. An ST should
then assign these security objectives to the TOE, the operational
environment or both.
The only solution I see that meets v2.1 is to write a family of three
YOKOTA HIROFUMI wrote:
> IMHO, how about to specify SFRs for both the TOE and the IT environment?
> Additionaly, you could put Application notes in the appropriate sections of
> Security objectives, TOE security functional requirements and Security
> requirements for the IT environment.
> In the Application notes, you could state the acceptance of combinational
> Does this deviate CC concept ?
> "Application notes" are defined as:
> CC Part1 B.2.7 Application notes ( PP )
> This optional section may contain additional supporting information that is
> considered relevant or useful for the construction, evaluation, or use of
> the TOE.
> CC Part1 C.2.8 Application notes ( ST )
> This optional part of an ST may contain additional information considered
> relevant or useful for the understanding of the ST. Note that if the ST
> claims compliance with the requirements of a PP, it may be appropriate that
> certain informaiton contained in a potential application notes section of
> the PP is incorporated into other sections of the ST. For example,
> information concerning the construction of the TOE is probably more
> appropriately preserved in the TOE summary specification or the ST rationale
> than in a separate application notes section. To ease evaluation of the ST,
> and given that the structure for the presentation of an ST outlined in this
> annex is not normative, an application note containing evaluation relevant
> material should be a part of the section of the ST that provides the
> evidence for that evaluation aspect.
> ----- Original Message -----
> From: "Agievich Sergei V." <email@example.com>
> To: "Multiple recipients of list" <firstname.lastname@example.org>
> Sent: Thursday, April 01, 2004 7:17 PM
> Subject: Categorisation of SFRs for the TOE and for the IT environment
>>We plan to develop a PP for software cryptographic modules that run under
>>a general-purpose operational system. During the preliminary analysis,
>>we encounter a problem with categorisation of SFRs for the TOE (software
>>and for the IT environment (operational system, OS).
>>Let us illustrate this problem with an example.
>>Let the τοε implement role-based access control policy.
>>Before using the TOE functionality, an end-user must be identified and
>>The following implementations of I &A are possible:
>>a) the OS identifies and authenticates end-users, and maps their identity
>>to an OS role. The TOE roles are equivalent to the OS ones;
>>b) the OS identifies and authenticates end-users, and maps their identity
>>to the OS role "TOE User". Members of this role have access to the TOE
>>authentication service. The TOE identifies and authenticates members
>>of the role "TOE User", and maps their identity to a TOE role;
>>c) the TOE identifies and authenticates all users of the OS, and maps
>>to a TOE role.
>>We suppose that any of the scenarios above can be implemented.
>>Developers can choose a target scenario during the ST creation and their
>>yields some combination of SFRs for the TOE and SFRs for the IT
>>Now, how to declare all such combinations in the PP?
>>In our opinion, the most flexible solution consists in the series of
>>"The TSF shall..." --> "The [selection: TSF, IT environment, TSF and IT
>>Does this solution meet the concept of the CC?
>>P.S. We have been embarrassed by the following paragraph
>>(CC, part 1, section 4.3.2):
>>The intent of determining security objectives is to address all of the
>>and to declare which security aspects are either addressed directly by the
>>TOE or by
>>its environment. This categorisation is based on a process incorporating
>>judgement, security policy, economic factors and risk acceptance
>>National Research Center for Applied Problems of Mathematics and
>>Belarusian State University
>>Fr. Skorina av. 4, Minsk 220050, Belarus
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
Date Index |
Thread Index |
Problems or questions? Contact email@example.com