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

513

The purpose of the configuration management activity is to assist the consumer in

identifying the evaluated TOE.

514

The configuration management activity at EAL1 contains a sub-activity related to

the following component:

515

The objectives of this sub-activity are to determine whether the developer has

clearly identified the TOE.

516

The evaluation evidence for this sub-activity is:

517

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

August 1999

CEM-99/045

Page 81 of 373

Version 1.0

519

The evaluator should seek to examine more than one version of the TOE (e.g.

during rework following discovery of a vulnerability), to check that the two

versions are referenced differently.

ACM_CAP.1.2C

reference.

520

The evaluator should ensure that the TOE contains a unique reference such that it

is possible to distinguish different versions of the TOE. This could be achieved

through labelled packaging or media, or by a label displayed by the operational

TOE. This is to ensure that it would be possible for consumers to identify the TOE

(e.g. at the point of purchase or use).

521

The TOE may provide a method by which it can be easily identified. For example,

a software TOE may display its name and version number during the start up

routine, or in response to a command line entry. A hardware or firmware TOE may

be identified by a part number physically stamped on the TOE.

523

The evaluator also verifies that the TOE reference is consistent with the ST.

524

For guidance on consistency analysis see Annex B.3.

Page 82 of 373

CEM-99/045

August 1999

Version 1.0

525

The purpose of the delivery and operation activity is to judge the adequacy of the

documentation of the procedures used to ensure that the TOE is installed,

generated, and started in the same way the developer intended it to be.

526

The delivery and operation activity at EAL1 contains a sub-activity related to the

following component:

527

The objective of this sub-activity is to determine whether the procedures and steps

for the secure installation, generation, and start-up of the TOE have been

documented and result in a secure configuration.

528

The evaluation evidence for this sub-activity is:

529

The installation, generation, and start-up procedures refer to all installation,

generation, and start-up procedures, regardless of whether they are performed at

the user’s site or at the development site that are necessary to progress the TOE to

the secure configuration as described in the ST.

530

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

August 1999

CEM-99/045

Page 83 of 373

Version 1.0

531

If it is not anticipated that the installation, generation, and start-up procedures will

or can be re-applied (e.g. because the TOE may already be delivered in an

operational state) this work unit (or the effected parts of it) is not applicable, and is

therefore considered to be satisfied.

Page 84 of 373

CEM-99/045

August 1999

Version 1.0

535

The purpose of the development activity is to assess the design documentation in

terms of its adequacy to understand how the TSF provides the security functions of

the TOE. This understanding is achieved through examination of a functional

specification (which describes the external interfaces of the TOE) and a

representation correspondence (which maps the functional specification to TOE

summary specification in order to ensure consistency).

536

The development activity at EAL1 contains sub-activities related to the following

components:

537

The CC requirements for design documentation are levelled by formality. The CC

considers a document’s degree of formality (that is, whether it is informal,

semiformal or formal) to be hierarchical. An informal document is one that is

expressed in a natural language. The methodology does not dictate the specific

language that must be used; that issue is left for the scheme. The following

paragraphs differentiate the contents of the different informal documents.

538

An informal functional specification comprises a description the security functions

(at a level similar to that of the TOE summary specification) and a description of

the externally-visible interfaces to the TSF. For example, if an operating system

presents the user with a means of self-identification, of creating files, of modifying

or deleting files, of setting permissions defining what other users may access files,

and of communicating with remote machines, its functional specification would

contain descriptions of each of these functions. If there are also audit functions that

detect and record the occurrences of such events, descriptions of these audit

functions would also be expected to be part of the functional specification; while

these functions are technically not directly invoked by the user at the external

interface, they certainly are affected by what occurs at the user’s external interface.

539

Informality of the demonstration of correspondence need not be in a prose form; a

simple two-dimensional mapping may be sufficient. For example, a matrix with

modules listed along one axis and subsystems listed along the other, with the cells

identifying the correspondence of the two, would serve to provide an adequate

informal correspondence between the high-level design and the low-level design.

540

The objective of this sub-activity is to determine whether the developer has

provided an adequate description of the security functions of the TOE and whether

August 1999

CEM-99/045

Page 85 of 373

Version 1.0

541

The evaluation evidence for this sub-activity is:

a)

the ST;

b)

the functional specification;

c)

the user guidance;

d)

the administrator guidance.

542

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

contains all necessary informal explanatory text.

543

If the entire functional specification is informal, this work unit is not applicable

and is therefore considered to be satisfied.

544

Supporting narrative descriptions are necessary for those portions of the functional

specification that are difficult to understand only from the semiformal or formal

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

ADV_FSP.1.2C

internally consistent.

545

The evaluator validates the functional specification by ensuring that the

descriptions of the interfaces making up the TSFI are consistent with the

descriptions of the functions of the TSF

546

For guidance on consistency analysis see Annex B.3.

ADV_FSP.1.3C

Page 86 of 373

CEM-99/045

August 1999

Version 1.0

TOE

(a)

(b)

(c)

Figure 5.1 TSF Interfaces

548

It should be noted that all security functions reflected in the functional

requirements of CC Part 2 (or in extended components thereof) will have some

sort of externally-visible manifestation. While not all of these are necessarily

interfaces from which the security function can be tested, they are all externally-

visible to some extent and must therefore be included in the functional

specification.

549

For guidance on determining the TOE boundary see Annex B.6.

describes all of the external TOE security function interfaces.

550

For a TOE that has no threat of malicious users (i.e. FPT_PHP, FPT_RVM, and

FPT_SEP are rightfully excluded from its ST), the only interfaces that are

August 1999

CEM-99/045

Page 87 of 373

Version 1.0

described in the functional specification (and expanded upon in the other TSF

representation descriptions) are those to and from the TSF. The absence of

FPT_PHP, FPT_RVM, and FPT_SEP presumes there is no concern for any sort of

bypassing of the security features; therefore, there is no concern with any possible

impact that other interfaces might have on the TSF.

551

On the other hand, if the TOE has a threat of malicious users or bypass (i.e.

FPT_PHP, FPT_RVM, and FPT_SEP are included in its ST), all external

interfaces are described in the functional specification, but only to the extent that

the effect of each is made clear: interfaces to the security functions (i.e. interfaces

b and c in Figure 5.1) are completely described, while other interfaces are

described only to the extent that it is clear that the TSF is inaccessible through the

interface (i.e. that the interface is of type a, rather than b in Figure 5.1). The

inclusion of FPT_PHP, FPT_RVM, and FPT_SEP implies a concern that all

interfaces might have some effect upon the TSF. Because each external interface is

a potential TSF interface, the functional specification must contain a description of

each interface in sufficient detail so that an evaluator can determine whether the

interface is security relevant.

552

Some architectures lend themselves to readily provide this interface description in

sufficient detail for groups of external interfaces. For example, a kernel

architecture is such that all calls to the operating system are handled by kernel

Page 88 of 373

CEM-99/045

August 1999

Version 1.0

etc.), the functional specification should explain that a file is either opened

upon request, or else that an error code is returned. (While the functional

specification may enumerate all these different reasons for errors, it need

not provide such detail.) The description of the semantics should include

how the security requirements apply to the interface (e.g. whether the use of

the interface is an auditable event and, if so, the information that can be

recorded).

c)

All interfaces are described for all possible modes of operation. If the TSF

provides the notion of privilege, the description of the interface should

explain how the interface behaves in the presence or absence of privilege.

d)

The information contained in the descriptions of the security relevant

parameters and syntax of the interface should be consistent across all

documentation.

554

Verification of the above is done by reviewing the functional specification and the

TOE summary specification of the ST, as well as the user and administrator

guidance provided by the developer. For example, if the TOE were an operating

system and its underlying hardware, the evaluator would look for discussions of

user-accessible programs, descriptions of protocols used to direct the activities of

programs, descriptions of user-accessible databases used to direct the activities of

programs, and for user interfaces (e.g. commands, application program interfaces)

as applicable to the TOE under evaluation; the evaluator would also ensure that the

processor instruction set is described.

555

This review might be iterative, such that the evaluator would not discover the

functional specification to be incomplete until the design, source code, or other

evidence is examined and found to contain parameters or error messages that have

been omitted from the functional specification.

is fully represented.

556

In order to assess the completeness of the TSF representation, the evaluator

consults the TOE summary specification of the ST, the user guidance, and the

August 1999

CEM-99/045

Page 89 of 373

Version 1.0

559

For each interface in the functional specification that operates on a controlled

resource, the evaluator determines whether it returns an error code that indicates a

possible failure due to enforcement of one of the security requirements; if no error

Page 90 of 373

CEM-99/045

August 1999

Version 1.0