Зарубежные нормативные документы и критерии на английском / cem-p2v10

4:ADV_IMP.1-4

The evaluator shall examine the implementation representation subset to

determine that it accurately instantiates those TOE security functional

requirements relevant to the subset.

1429

For those portions of the implementation representation subset that provide

security functions directly, the evaluator determines that the implementation

matches the TOE security functional requirement. The remaining portions of the

implementation representation subset may support some TOE functional

requirement. In making a determination about these remaining portions, the

evaluator makes use of the low-level design to assess if the portions in the

implementation representation subset, in combination with other portions as

described in the low-level design, work together to instantiate a TOE security

functional requirement.

1430

The remaining portions of the implementation representation subset, if any, can

generally be ignored because they are unrelated to any of the TOE security

August 1999

CEM-99/045

Page 271 of Version 1.0

Version 1.0

1431

The objective of this sub-activity is to determine whether the low-level design is

sufficient to satisfy the functional requirements of the ST, and is a correct and

effective refinement of the high-level design.

1432

The evaluation evidence for this sub-activity is:

1433

This sub-activity comprises two CC Part 3 evaluator action elements:

1436

For guidance on consistency analysis see Annex B.3.

ADV_LLD.1.3C

Page 272 of 373

CEM-99/045

August 1999

Version 1.0

1439

For the purpose of this analysis, modules are viewed as interacting in two ways:

a)

to provide services to one another, and

b)

to cooperate in support of security functions.

1440

The low-level design should include specific information on these

interrelationships. For example, if a module performs calculations that depend on

the results of calculations in other modules, those other modules should be listed.

Further, if a module provides a service intended for other modules to use in

supporting security functions, the service should be described. It is possible that

the description of the purpose of a module, as analysed in the preceding work unit,

is sufficient to provide this information.

ADV_LLD.1.6C

August 1999

CEM-99/045

Page 273 of 373

Version 1.0

1442

It is this description in the low-level design that is key to the assessment as to

whether the low-level design is sufficiently refined to permit an implementation to

be created. The evaluator should analyse the description from the point of view of

an implementor. If the evaluator, using the implementor’s viewpoint, is unclear on

any aspect of how the module could be implemented, the description is

incomplete. Note that there is no requirement that a module be implemented as a

separate unit (be it a program, a subprogram, or a hardware component); but the

low-level design may be sufficiently detailed to permit such an implementation.

ADV_LLD.1.7C

TSF modules.

1443

The low-level design should include, for each module, the name of each of its

entry points.

1445

The module interface descriptions may be provided in general terms for some

interfaces, and in more detail for others. In determining the necessary level of

detail of effects, exceptions and error messages, the evaluator should consider the

purposes of this analysis and the uses made of the interface by the TOE. For

example, the evaluator needs to understand the general nature of the interactions

between modules to establish confidence that the TOE design is sound, and may be

able to obtain this understanding with only a general description of some of the

interfaces between modules. In particular, internal entry points that are not called

by any other module would not normally require detailed descriptions.

1446

This work unit may be performed in conjunction with the evaluator’s independent

vulnerability analysis, which is part of the AVA_VLA sub-activity.

1447

Detailed descriptions would include details of any input and output parameters, of

the effects of the interface, and of any exceptions or error messages it produces. In

the case of external interfaces, the required description is probably included in the

Page 274 of 373

CEM-99/045

August 1999

Version 1.0

1451

The evaluator analyses the low-level design to determine that each TOE security

function is completely described by the module specifications, and that there are

August 1999

CEM-99/045

Page 275 of 373

Version 1.0

1453

The evaluation evidence for this sub-activity is:

1454

This sub-activity comprises one CC Part 3 evaluator action element:

Page 276 of 373

CEM-99/045

August 1999

Version 1.0

1455

The evaluator’s goal in this work unit is to determine that all security functions

identified in the TOE summary specification are represented in the functional

specification and that they are represented accurately.

1456

The evaluator reviews the correspondence between the TOE security functions of

the TOE summary specification and the functional specification. The evaluator

looks for consistency and accuracy in the correspondence. Where the

correspondence analysis indicates a relationship between a security function of the

1458

The evaluator uses the correspondence analysis, the functional specification, and

the high-level design to ensure that it is possible to map each security function

identified in the functional specification onto a TSF subsystem described in the

high-level design. For each security function, the correspondence indicates which

TSF subsystems are involved in the support of the function. The evaluator verifies

that the high-level design includes a description of a correct realisation of each

security function.

design that are refined in the implementation representation.

1460

Since the evaluator examines only a subset of the implementation representation,

this work unit is performed by assessing the correspondence analysis of the subset

of the implementation representation to the relevant parts of the low-level design

rather than attempting to trace each TOE security function into the implementation

representation. The subset may provide no coverage for some functions.

August 1999

CEM-99/045

Page 277 of 373

Version 1.0

1461

The objectives of this sub-activity are to determine whether the security policy

model clearly and consistently describes the rules and characteristics of the

security policies and whether this description corresponds with the description of

security functions in the functional specification.

1462

The evaluation evidence for this sub-activity is:

1463

This sub-activity comprises one CC Part 3 evaluator action element:

4:ADV_SPM.1-1

The evaluator shall examine the security policy model to determine that it

contains all necessary informal explanatory text.

1464

If the entire security policy model is informal, this work unit is not applicable and

is therefore considered to be satisfied.

1465

Supporting narrative descriptions are necessary for those portions of the security

policy model that are difficult to understand only from the semiformal or formal

description (for example, to make clear the meaning of any formal notation).

ADV_SPM.1.2C

Page 278 of 373

CEM-99/045

August 1999

Version 1.0

(and hence what policies must be modeled), the evaluator analyses the ST

functional requirements for those policies explicitly called for (by FDP_ACC and

FDP_IFC, if included in the ST).

1467

Depending upon the TOE, formal/semiformal modeling might not even be

possible for access control. (For example, the access control policy for a firewall

connected to the internet cannot be formally modeled in a useful manner because

the state of the internet cannot be completely defined.). For any security policy

where formal or semiformal models are not possible, the policy must be provided

in an informal form.

1468

If the ST contains no explicit policies (because neither FDP_ACC nor FDP_IFC

are included in the ST), this work unit is not applicable and is therefore considered

to be satisfied.

4:ADV_SPM.1-3

The evaluator shall examine the security policy model to determine that all

security policies represented by the security functional requirements claimed in the

ST are modeled.

1469

In addition to the explicitly-listed policies (see work unit 4:ADV_SPM.1-2), the

evaluator analyses the ST functional requirements for those policies implied by the

other functional security requirement classes. For example, inclusion of FDP

requirements (other than FDP_ACC and FDP_IFC) would need a description of

the Data Protection policy being enforced; inclusion of any FIA requirements

would necessitate that a description of the Identification and Authentication

policies be present in the security policy model; inclusion of FAU requirements

need a description of the Audit policies; etc. While the other functional

requirement families are not typically associated with what are commonly referred

to as security policies, they nevertheless do enforce security policies (e.g. non-

repudiation, reference mediation, privacy, etc.) that must be included in the

security policy model.

1470

In cases where the security policy model presentation is informal, all security

policies can be modeled (i.e. described), and so must be included. For any security

policy where formal or semiformal security policy models are not possible, the

policy must be provided in an informal form.

1472

The rules and characteristics describe the security posture of the TOE. It is likely

that such a description would be contained within an evaluated and certified ST. In

order to be considered a clear articulation, such a description should define the

notion of security for the TOE, identify the security attributes of the entities

controlled by the TOE and identify the TOE actions which change those attributes.

August 1999

CEM-99/045

Page 279 of 373

Version 1.0

1476

In determining completeness, the evaluator reviews the functional specification,

identifies which functions directly support the security policy model and verifies

that these functions are present in the functional specification correspondence

demonstration of the security policy model.

Page 280 of 373

CEM-99/045

August 1999

Version 1.0