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

1756

While some specific details of the actual test results may be different from those

expected (e.g. time and date fields in an audit record) the overall result should be

identical. Any differences should be justified.

1758

Information that would typically be found in the ETR section regarding evaluator

penetration testing efforts is:

a)

TOE test configurations. The particular configurations of the TOE that were

penetration tested;

b)

security functions penetration tested. A brief listing of the security functions

that were the focus of the penetration testing;

c)

verdict for the sub-activity. The overall judgement on the results of

penetration testing.

1759

This list is by no means exhaustive and is only intended to provide some context as

to the type of information that should be present in the ETR concerning the

penetration testing the evaluator performed during the evaluation.

August 1999

CEM-99/045

Page 341 of 373

Version 1.0

Page 342 of 373

CEM-99/045

August 1999

Version 1.0

1761

This annex presents abbreviations, acronyms and vocabulary used by the CEM and

does not include those already presented in the CC. This annex also presents the

references used in the CEM.

A.1

Abbreviations and acronyms

1762

CEM

Common Methodology for Information Technology Security Evaluation

1763

ETR

Evaluation Technical Report

1764

OR

Observation Report

A.2

Vocabulary

1765

Terms which are presented in bold-faced type are themselves defined in this

section.

1766

Check:

to generate a verdict by a simple comparison. Evaluator expertise is not

required. The statement that uses this verb describes what is mapped.

1767

Evaluation Deliverable:

any resource required from the sponsor or developer by the evaluator or

overseer to perform one or more evaluation or evaluation oversight

activities.

1768

Evaluation Evidence:

a tangible evaluation deliverable.

1769

Evaluation Technical Report:

a report that documents the overall verdict and its justification, produced

by the evaluator and submitted to an overseer.

August 1999

CEM-99/045

Page 343 of 373

Version 1.0

1770

Examine:

to generate a verdict by analysis using evaluator expertise. The statement

that uses this verb identifies what is analysed and the properties for which it

is analysed.

1771

Interpretation:

a clarification or amplification of a CC, CEM or scheme requirement.

1772

Methodology:

the system of principles, procedures and processes applied to IT security

evaluations.

1773

Observation Report:

a report written by the evaluator requesting a clarification or identifying a

problem during the evaluation.

1774

Overall Verdict:

a pass or fail statement issued by an evaluator with respect to the result of

an evaluation.

1775

Oversight Verdict:

a statement issued by an overseer confirming or rejecting an overall verdict

based on the results of evaluation oversight activities.

1776

Record:

to retain a written description of procedures, events, observations, insights

and results in sufficient detail to enable the work performed during the

evaluation to be reconstructed at a later time.

1777

Report:

to include evaluation results and supporting material in the Evaluation

Technical Report or an Observation Report.

1778

Scheme:

set of rules, established by an evaluation authority, defining the evaluation

environment, including criteria and methodology required to conduct IT

security evaluations.

Page 344 of 373

CEM-99/045

August 1999

Version 1.0

1779

Tracing:

a simple directional relation between two sets of entities, which shows

which entities in the first set correspond to which entities in the second.

1780

Verdict:

a pass, fail or inconclusive statement issued by an evaluator with respect to

a CC evaluator action element, assurance component, or class. Also see

overall verdict.

A.3

References

CC

Common Criteria for Information Technology Security Evaluation, Version 2.1,

August 1999.

COD

Concise Oxford Dictionary, Oxford University Press, Ninth edition, 1995.

IEEE

IEEE Standard Glossary of Software Engineering Terminology, ANSI/IEEE STD

729-1983

August 1999

CEM-99/045

Page 345 of 373

Version 1.0

B.1

Objectives

1781

The objective of this chapter is to cover general guidance used to provide technical

evidence of evaluation results. The use of such general guidance helps in achieving

objectivity, repeatability and reproducibility of the work performed by the

evaluator.

B.2

Sampling

1782

This section provides general guidance on sampling. Specific and detailed

information is given in those work units under the specific evaluator action

elements where sampling has to be performed.

1783

Sampling is a defined procedure of an evaluator whereby some subset of a

required set of evaluation evidence is examined and assumed to be representative

for the entire set. It allows the evaluator to gain enough confidence in the

correctness of particular evaluation evidence without analysing the whole

evidence. The reason for sampling is to conserve resources while maintaining an

adequate level of assurance. Sampling of the evidence can provide two possible

outcomes:

a)

The subset reveals no errors, allowing the evaluator to have some

confidence that the entire set is correct.

b)

The subset reveals errors and therefore the validity of the entire set is called

into question. Even the resolution of all errors that were found may be

insufficient to provide the evaluator the necessary confidence and as a

result the evaluator may have to increase the size of the subset, or stop

using sampling for this particular evidence.

1784

Sampling is a technique which can be used to reach a reliable conclusion if a set of

evidence is relatively homogeneous in nature, e.g. if the evidence has been

produced during a well defined process.

1785

The CC identifies the following evaluator action elements where sampling is

explicitly acceptable:

a)

ADV_RCR.3.2E: “The evaluator shall determine the accuracy of the

proofs of correspondence by selectively verifying the formal analysis.”

b)

ATE_IND.*.2E: “The evaluator shall test a subset of the TSF as

appropriate to confirm that the TOE operates as specified”.

August 1999

CEM-99/045

Page 346 of 373

Version 1.0

c)

ATE_IND.2.3E: “The evaluator shall execute a sample of tests in the test

documentation to verify the developer test results.”

d)

AVA_CCA.*.3E: “The evaluator shall selectively validate the covert

channel analysis through testing.”

e)

AVA_MSU.2.2E and AVA_MSU.3.2E: “The evaluator shall repeat all

configuration and installation procedures, and other procedures selectively,

to confirm that the TOE can be configured and used securely using only the

supplied guidance documentation.”

f)

AMA_SIA.1.2E: “The evaluator shall check, by sampling, that the security

impact analysis documents changes to an appropriate level of detail,

together with appropriate justifications that assurance has been maintained

in the current version of the TOE.”

1786

In addition ADV_IMP.1.1D requires that the developer provide the

implementation representation for a subset of the TSF only. The sample of the

subset should be selected in agreement with the evaluator. Provision of a sample of

the implementation representation allows the evaluator to assess the presentation

of the implementation representation itself and to sample the traceability evidence

to gain assurance in the correspondence between the low-level design and the

implementation representation.

1787

In addition to the sampling that the CC accepts, the CEM identifies the following

actions where sampling is acceptable:

a)

Action ACM_CAP.*.1E: “The evaluator shall confirm that the information

provided meets all requirements for content and presentation of evidence.”

Here sampling is accepted for the content and presentation of evidence

elements ACM_CAP.*.8C and ACM_CAP.*.9C for EAL3 and EAL4.

b)

Action ATE_FUN.1.1E: “The evaluator shall confirm that the information

provided meets all requirements for content and presentation of evidence.”

Here sampling is accepted for the content and presentation of evidence

element ATE_FUN.1.3C, ATE_FUN.1.4C, and ATE_FUN.1.5C for EAL2,

EAL3, and EAL4.

c)

Action ALC_DVS.1.1E: “The evaluator shall confirm that the information

provided meets all requirements for content and presentation of evidence.”

Here sampling is accepted for the content and presentation of evidence

element ALC_DVS.1.2C for EAL3 and EAL4.

1788

Sampling in the cases identified in the CC, and in cases specifically covered in

CEM work items, is recognised as a cost-effective approach to performing

evaluator actions. Sampling in other areas is permitted only in exceptional cases,

where

performance of a particular activity in its entirety would require effort

August 1999

CEM-99/045

Page 347 of 373

Version 1.0

disproportionate to the other evaluation activities, and where this would not add

correspondingly to assurance. In such cases a rationale for the use of sampling in

that area will need to be made. Neither the fact that the TOE is large and complex,

nor that it has many security functional requirements, is sufficient justification,

since evaluations of large, complex TOEs can be expected to require more effort.

Rather it is intended that this exception be limited to cases such as that where the

TOE development approach yields large quantities of material for a particular CC

requirement that would normally all need to be checked or examined, and where

such an action would not be expected to raise assurance correspondingly.

1789

Sampling needs to be justified taking into account the possible impact on the

security objectives and threats of the TOE. The impact depends on what might be

missed as a result of sampling. Consideration also needs to be given to the nature

of the evidence to be sampled, and the requirement not to diminish or ignore any

security functions.

1790

It should be recognised that sampling of evidence directly related to the

implementation of the TOE (e.g. developer test results) requires a different

approach to sampling related to the determination of whether a process is being

followed. In many cases the evaluator is required to determine that a process is

being followed, and a sampling strategy is recommended. The approach here will

differ from that taken when sampling a developer’s test results. This is because the

former case is concerned with ensuring that a process is in place, and the latter

deals with determining correct implementation of the TOE. Typically, larger

sample sizes should be analysed in cases related to the correct implementation of

the TOE than would be necessary to ensure that a process is in place.

1791

The following principles should be followed whenever sampling is performed:

a)

The sample size should be commensurate with the cost effectiveness of the

evaluation and will depend on a number of TOE dependent factors (e.g. the

size and complexity of the TOE, the amount of documentation), but a

minimum size of 20% should be adopted as a norm for sampling material

related to the TOE implementation. Where sampling relates to gaining

evidence that a process (e.g. visitor control or design review), a percentage

figure is not appropriate, and the evaluator should sample sufficient

information to gain reasonable confidence that the procedure is being

followed. The sample size has to be justified.

b)

The sample should be representative of all aspects relevant to the areas that

are sampled. In particular, a selection should cover a variety of

components, security functions, developer and operational sites (if more

than one is involved) and hardware platform types (if more than one is

involved).

c)

The sponsor and developer should not be informed in advance of the exact

composition of the sample, subject to ensuring timely delivery of the

sample and supporting deliverable, e.g. test harnesses and equipment to the

evaluator in accordance with the evaluation schedule.

Page 348 of 373

CEM-99/045

August 1999

Version 1.0

B.3

Consistency analysis

1793

This section provides general guidance on consistency analysis. Specific and

detailed information is given in those work units under the specific evaluator

action elements where a consistency analysis has to be performed.

1794

A consistency analysis is a defined procedure of an evaluator whereby a special

part of an evaluation deliverable is itself analysed (internally consistent) or is

compared with one or more other evaluation deliverables.

1795

The CC distinguishes between different kinds of consistency analysis:

a)

The evaluator has to analyse the internal consistency of an evaluation

August 1999

CEM-99/045

Page 349 of 373

Version 1.0

Page 350 of 373

CEM-99/045

August 1999

Version 1.0