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

approach has been taken, such that delivery does not present an obvious weak

point in an otherwise secure development process.

668

The delivery procedures describe proper procedures to determine the identification

of the TOE and to maintain integrity during transfer of the TOE or its component

parts. The procedures describe which parts of the TOE need to be covered by these

procedures. It should contain procedures for physical or electronic (e.g. for

downloading off the Internet) distribution where applicable. The delivery

procedures refer to the entire TOE, including applicable software, hardware,

firmware and documentation.

669

The emphasis on integrity is not surprising, since integrity will always be of

concern for TOE delivery. Where confidentiality and availability are of concern,

they also should be considered under this work unit.

670

The delivery procedures should be applicable across all phases of delivery from

the production environment to the installation environment (e.g. packaging,

storage and distribution).

objectives.

671

The suitability of the choice of the delivery procedures is influenced by the

specific TOE (e.g. whether it is software or hardware) and by the security

objectives.

672

Standard commercial practice for packaging and delivery may be acceptable. This

includes shrink wrapped packaging, a security tape or a sealed envelope. For the

distribution the public mail or a private distribution service may be acceptable.

August 1999

CEM-99/045

Page 111 of 373

Version 1.0

c)

observing that the process is applied in practice when the evaluator obtains

the TOE through regular channels;

d)

questioning end users as to how the TOE was delivered.

674

For guidance on site visits see Annex B.5.

675

It may be the case of a newly developed TOE that the delivery procedures have yet

to be exercised. In these cases, the evaluator has to be satisfied that appropriate

procedures and facilities are in place for future deliveries and that all personnel

involved are aware of their responsibilities. The evaluator may request a “dry run”

of a

delivery if this is practical. If the developer has produced other similar

Page 112 of 373

CEM-99/045

August 1999

Version 1.0

676

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.

677

The evaluation evidence for this sub-activity is:

678

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

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

679

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

August 1999

CEM-99/045

Page 113 of 373

Version 1.0

681

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.

682

The

installation, generation, and start-up procedures may provide detailed

information about the following:

a)

changing the installation specific security characteristics of entities under

the control of the TSF;

b)

handling exceptions and problems;

c)

minimum system requirements for secure installation if applicable.

683

In order to confirm that the installation, generation, and start-up procedures result

in a secure configuration, the evaluator may follow the developer’s procedures and

may

perform the activities that customers are usually expected to perform to

Page 114 of 373

CEM-99/045

August 1999

Version 1.0

684

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 increasingly

refined descriptions of the TSF design documentation. Design documentation

consists of a functional specification (which describes the external interfaces of the

TOE) and a high-level design (which describes the architecture of the TOE in

terms of internal subsystems). There is also a representation correspondence

(which maps representations of the TOE to one another in order to ensure

consistency).

685

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

components:

686

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.

687

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.

688

An informal high-level design is expressed in terms of sequences of actions that

occur in each subsystem in response to stimulus at its interface. For example, a

firewall might be composed of subsystems that deal with packet filtering, with

remote administration, with auditing, and with connection-level filtering. The

high-level design description of the firewall would describe the actions that are

taken, in terms of what actions each subsystem takes when an incoming packet

arrives at the firewall.

August 1999

CEM-99/045

Page 115 of 373

Version 1.0

689

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.

690

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

the security functions provided by the TOE are sufficient to satisfy the security

functional requirements of the ST.

691

The evaluation evidence for this sub-activity is:

692

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

contains all necessary informal explanatory text.

693

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

and is therefore considered to be satisfied.

694

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).

Page 116 of 373

CEM-99/045

August 1999

Version 1.0

TOE

(a)

(b)

(c)

701

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 6.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 6.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.

702

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 118 of 373

CEM-99/045

August 1999

Version 1.0

August 1999

CEM-99/045

Page 119 of 373

Version 1.0

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.

705

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.

ADV_FSP.1.4C

is fully represented.

706

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

709

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

Page 120 of 373

CEM-99/045

August 1999

Version 1.0