Common Criteria for Information Technology Security Evaluation ....pdf

Common Criteria

for Information Technology

Security Evaluation

Part 1: Introduction and general model

Foreword

This version of the Common Criteria for Information Technology Security Evaluation (CC v2.3) contains all final interpretations, editorial changes, and agreed new material since the publication of CC v2.1, in alignment with International Standard ISO/IEC 15408:2005.

CC version 2.3 consists of the following parts:

?Part 1: Introduction and general model

?Part 2: Security functional requirements

?Part 3: Security assurance requirements

Legal Notice:

The governmental organisations listed below contributed to the development of this version of the Common Criteria for Information Technology Security Evaluation. As the joint holders of the copyright in the Common Criteria for Information Technology Security Evaluation, version 2.3 Parts 1 through 3 (called “CC 2.3”), they hereby grant non-exclusive license to ISO/IEC to use CC 2.3 in the continued development/maintenance of the ISO/IEC 15408 international standard. However, these governmental organisations retain the right to use, copy, distribute, translate or modify CC 2.3 as they see fit.

Australia/New Zealand: The Defence Signals Directorate and the

Government Communications Security Bureau respectively; Canada: Communications Security Establishment;

France: Direction Centrale de la Sécurité des Systèmes d'Information; Germany: Bundesamt für Sicherheit in der Informationstechnik; Japan: Information Technology Promotion Agency

Communications Security Agency;

National

Netherlands: Netherlands

Spain: Ministerio de Administraciones Públicas and

Centro Criptológico Nacional;

United Kingdom: Communications-Electronics Security Group;

United States: The National Security Agency and the

National Institute of Standards and Technology.

Page 2 of 61 Version 2.3 August 2005

Table of contents

Table of Contents

1INTRODUCTION (7)

2SCOPE (8)

3TERMS AND DEFINITIONS (10)

4SYMBOLS AND ABBREVIATED TERMS (15)

5OVERVIEW (16)

5.1Introduction (16)

5.1.1Target audience of the CC (16)

5.2Evaluation context (18)

5.3Organisation of the Common Criteria (19)

6GENERAL MODEL (21)

6.1Security context (21)

6.1.1General security context (21)

6.1.2Information technology security context (23)

6.2Common Criteria approach (23)

6.2.1Development (23)

6.2.2TOE evaluation (25)

6.2.3Operation (26)

6.3Security concepts (26)

6.3.1Security environment (28)

6.3.2Security objectives (29)

6.3.3IT security requirements (30)

6.3.4TOE summary specification (31)

6.3.5TOE implementation (31)

6.4CC descriptive material (31)

6.4.1Expression of security requirements (31)

6.4.2Types of evaluation (38)

7COMMON CRITERIA REQUIREMENTS AND EVALUATION RESULTS (39)

7.1Introduction (39)

7.2Requirements in PPs and STs (40)

7.2.1PP evaluation results (40)

7.3Requirements in TOE (40)

7.3.1TOE evaluation results (41)

7.4Conformance results (41)

August 2005 Version 2.3 Page 3 of 61

Table of contents

7.5Use of TOE evaluation results (42)

A SPECIFICATION OF PROTECTION PROFILES (44)

A.1Overview (44)

A.2Content of Protection Profile (44)

A.2.1Content and presentation (44)

A.2.2PP introduction (45)

A.2.3TOE description (45)

A.2.4TOE security environment (46)

A.2.5Security objectives (47)

A.2.6IT security requirements (47)

A.2.7Application notes (49)

A.2.8Rationale (49)

B SPECIFICATION OF SECURITY TARGETS (51)

B.1Overview (51)

B.2Content of Security Target (51)

B.2.1Content and presentation (51)

B.2.2ST introduction (52)

B.2.3TOE description (53)

B.2.4TOE security environment (53)

B.2.5Security objectives (54)

B.2.6IT security requirements (54)

B.2.7TOE summary specification (56)

B.2.8PP claims (57)

B.2.9Application Notes (58)

B.2.10Rationale (59)

C BIBLIOGRAPHY (61)

Page 4 of 61 Version 2.3 August 2005

List of figures

List of figures

Figure 1 - Evaluation Context (19)

Figure 2 - Security concepts and relationships (21)

Figure 3 - Evaluation concepts and relationships (22)

Figure 4 - TOE development model (24)

Figure 5 - TOE evaluation process (25)

Figure 6 - Derivation of requirements and specifications (28)

Figure 7 - Organisation and construction of requirements (32)

Figure 8 - Use of security requirements (36)

Figure 9 - Evaluation results (39)

Figure 10 - Use of TOE evaluation results (43)

Figure 11 - Protection Profile content (45)

Figure 12 - Security Target content (52)

August 2005 Version 2.3 Page 5 of 61

List of tables

List of tables

Table 1 - Roadmap to the Common Criteria (20)

Page 6 of 61 Version 2.3 August 2005

Introduction

1 Introduction

1The CC will permit comparability between the results of independent security evaluations. It does so by providing a common set of requirements

for the security functions of IT products and systems and for assurance

measures applied to them during a security evaluation. The evaluation

process establishes a level of confidence that the security functions of such

products and systems and the assurance measures applied to them meet these

requirements. The evaluation results may help consumers to determine

whether the IT product or system is secure enough for their intended

application and whether the security risks implicit in its use are tolerable.

2The CC is useful as a guide for the development of products or systems with IT security functions and for the procurement of commercial products and

systems with such functions. During evaluation, such an IT product or

system is known as a Target of Evaluation (TOE). Such TOEs include, for

example, operating systems, computer networks, distributed systems, and

applications.

3The CC addresses protection of information from unauthorised disclosure, modification, or loss of use. The categories of protection relating to these

three types of failure of security are commonly called confidentiality,

integrity, and availability, respectively. The CC may also be applicable to

aspects of IT security outside of these three. The CC concentrates on threats

to that information arising from human activities, whether malicious or

otherwise, but may be applicable to some non-human threats as well. In

addition, the CC may be applied in other areas of IT, but makes no claim of

competence outside the strict domain of IT security.

4The CC is applicable to IT security measures implemented in hardware, firmware or software. Where particular aspects of evaluation are intended

only to apply to certain methods of implementation, this will be indicated

within the relevant criteria statements.

August 2005 Version 2.3 Page 7 of 61

Scope 2 Scope

5This multipart standard, the Common Criteria (CC), is meant to be used as the basis for evaluation of security properties of IT products and systems. By

establishing such a common criteria base, the results of an IT security

evaluation will be meaningful to a wider audience.

6Certain topics, because they involve specialized techniques or because they are somewhat peripheral to IT security, are considered to be outside the

scope of the CC. Some of these are identified below:

a)The CC does not contain security evaluation criteria pertaining to

administrative security measures not related directly to the IT security

measures. However, it is recognised that a significant part of the

security of a TOE can often be achieved through administrative

measures such as organisational, personnel, physical, and procedural

controls. Administrative security measures in the operating

environment of the TOE are treated as secure usage assumptions

where these have an impact on the ability of the IT security measures

to counter the identified threats.

b)The evaluation of technical physical aspects of IT security such as

electromagnetic emanation control is not specifically covered,

although many of the concepts addressed will be applicable to that

area. In particular, the CC addresses some aspects of physical

protection of the TOE.

c)The CC addresses neither the evaluation methodology nor the

administrative and legal framework under which the criteria may be

applied by evaluation authorities. However, it is expected that the CC

will be used for evaluation purposes in the context of such a

framework and such a methodology.

d)The procedures for use of evaluation results in product or system

accreditation are outside the scope of the CC. Product or system

accreditation is the administrative process whereby authority is

granted for the operation of an IT product or system in its full

operational environment. Evaluation focuses on the IT security parts

of the product or system and those parts of the operational

environment that may directly affect the secure use of IT elements.

The results of the evaluation process are consequently a valuable

input to the accreditation process. However, as other techniques are

more appropriate for the assessments of non-IT related product or

system security properties and their relationship to the IT security

parts, accreditors should make separate provision for those aspects.

e)The subject of criteria for the assessment of the inherent qualities of

cryptographic algorithms is not covered in the CC. Should

independent assessment of mathematical properties of cryptography Page 8 of 61 Version 2.3 August 2005

Scope

embedded in a TOE be required, the evaluation scheme under which

the CC is applied must make provision for such assessments. August 2005 Version 2.3 Page 9 of 61

Terms and definitions

3 Terms and definitions

7

For the purposes of this document, the following terms and definitions apply. 8 This chapter 3 contains only those terms which are used in a specialised way

throughout the CC. The majority of terms in the CC are used either according to their accepted dictionary definitions or according to commonly accepted definitions that may be found in ISO security glossaries or other well-known collections of security terms. Some combinations of common terms used in the CC, while not meriting inclusion in this chapter 3, are explained for clarity in the context where they are used. Explanations of the use of terms and concepts used in a specialised way in CC Part 2 and CC Part 3 can be found in their respective “paradigm” sections.

9 assets ? information or resources to be protected by the countermeasures of a TOE.

10 assignment ? the specification of an identified parameter in a component. 11 assurance ? grounds for confidence that an entity meets its security objectives.

12 attack potential ? the perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker's expertise, resources and motivation.

13 augmentation ? the addition of one or more assurance component(s) from CC Part 3 to an EAL or assurance package.

14 authentication data ? information used to verify the claimed identity of a user.

15 authorised user ? a user who may, in accordance with the TSP, perform an operation.

16 class ? a grouping of families that share a common focus.

17 component ? the smallest selectable set of elements that may be included in a PP, an ST, or a package.

18 connectivity ? the property of the TOE which allows interaction with IT entities external to the TOE. This includes exchange of data by wire or by wireless means, over any distance in any environment or configuration.

19 dependency ? a relationship between requirements such that the requirement that is depended upon must normally be satisfied for the other requirements to be able to meet their objectives.

20

element ? an indivisible security requirement. Page 10 of 61 Version 2.3 August 2005

Terms and definitions

21evaluation ? assessment of a PP, an ST or a TOE, against defined criteria. 22evaluation assurance level (EAL) ? a package consisting of assurance components from CC Part 3 that represents a point on the CC predefined

assurance scale.

23evaluation authority ? a body that implements the CC for a specific community by means of an evaluation scheme and thereby sets the standards

and monitors the quality of evaluations conducted by bodies within that

community.

24evaluation scheme ? the administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific

community.

25extension ? the addition to an ST or PP of functional requirements not contained in CC Part 2 and/or assurance requirements not contained in CC

Part 3.

26external IT entity ? any IT product or system, untrusted or trusted, outside of the TOE that interacts with the TOE.

27family ? a grouping of components that share security objectives but may differ in emphasis or rigour.

28formal ? expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts.

29guidance documentation ? guidance documentation describes the delivery, installation, configuration, operation, management and use of the TOE as

these activities apply to the users, administrators, and integrators of the TOE.

The requirements on the scope and contents of guidance documents are

defined in a PP or ST.

30human user ? any person who interacts with the TOE.

31identity ? a representation (e.g. a string) uniquely identifying an authorised user, which can either be the full or abbreviated name of that user or a

pseudonym.

32informal ? expressed in natural language.

33internal communication channel ? a communication channel between separated parts of TOE.

34internal TOE transfer ? communicating data between separated parts of the TOE.

35inter-TSF transfers ? communicating data between the TOE and the security functions of other trusted IT products.

August 2005 Version 2.3 Page 11 of 61

Terms and definitions 36iteration ? the use of a component more than once with varying operations. 37object ? an entity within the TSC that contains or receives information and upon which subjects perform operations.

38organisational security policies ? One or more security rules, procedures, practices, or guidelines imposed by an organisation upon its operations.

39package ? a reusable set of either functional or assurance components (e.g.

an EAL), combined together to satisfy a set of identified security objectives.

40product ? a package of IT software, firmware and/or hardware, providing functionality designed for use or incorporation within a multiplicity of

systems.

41protection profile (PP) ? an implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs.

42reference monitor ? the concept of an abstract machine that enforces TOE access control policies.

43reference validation mechanism ? an implementation of the reference monitor concept that possesses the following properties: it is tamperproof,

always invoked, and simple enough to be subjected to thorough analysis and

testing.

44refinement ? the addition of details to a component.

45role ? a predefined set of rules establishing the allowed interactions between a user and the TOE.

46secret ? information that must be known only to authorised users and/or the TSF in order to enforce a specific SFP.

47security attribute ? characteristics of subjects, users, objects, information, and/or resources that are used for the enforcement of the TSP.

48security function (SF) ? a part or parts of the TOE that have to be relied upon for enforcing a closely related subset of the rules from the TSP.

49security function policy (SFP) ? the security policy enforced by an SF.

50security objective ? a statement of intent to counter identified threats and/or satisfy identified organisation security policies and assumptions.

51security target (ST) ? a set of security requirements and specifications to be used as the basis for evaluation of an identified TOE.

52selection ? the specification of one or more items from a list in a component.

Page 12 of 61 Version 2.3 August 2005

Terms and definitions

53semiformal ? expressed in a restricted syntax language with defined semantics.

54strength of function (SOF) ? a qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected

security behaviour by directly attacking its underlying security mechanisms.

55SOF-basic ? a level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE

security by attackers possessing a low attack potential.

56SOF-medium ? a level of the TOE strength of function where analysis shows that the function provides adequate protection against straightforward

or intentional breach of TOE security by attackers possessing a moderate

attack potential.

57SOF-high ? a level of the TOE strength of function where analysis shows that the function provides adequate protection against deliberately planned or

organised breach of TOE security by attackers possessing a high attack

potential.

58subject ? an entity within the TSC that causes operations to be performed.

59system ? a specific IT installation, with a particular purpose and operational environment.

60target of evaluation (TOE) ? an IT product or system and its associated guidance documentation that is the subject of an evaluation.

61TOE resource ? anything useable or consumable in the TOE.

62TOE security functions (TSF) ? a set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct

enforcement of the TSP.

63TOE security functions interface (TSFI) ? a set of interfaces, whether interactive (man-machine interface) or programmatic (application

programming interface), through which TOE resources are accessed,

mediated by the TSF, or information is obtained from the TSF.

64TOE security policy (TSP) ? a set of rules that regulate how assets are managed, protected and distributed within a TOE.

65TOE security policy mode ? a structured representation of the security policy to be enforced by the TOE.

66transfers outside TSF control ? communicating data to entities not under control of the TSF.

67trusted channel ? A means by which a TSF and a remote trusted IT product can communicate with necessary confidence to support the TSP.

August 2005 Version 2.3 Page 13 of 61

Terms and definitions

68trusted path ? a means by which a user and a TSF can communicate with necessary confidence to support the TSP.

69TSF data ? data created by and for the TOE, that might affect the operation of the TOE.

70TSF scope of control (TSC) ? the set of interactions that can occur with or within a TOE and are subject to the rules of the TSP.

71user ? any entity (human user or external IT entity) outside the TOE that interacts with the TOE.

72user data ? data created by and for the user, that does not affect the operation of the TSF.

73normative ? normative text is that which “describes the scope of the document, and which set out provisions.” (ISO/IEC Directives, Part 2)

Within normative text, the verbs “shall”, “should”, “may”, and “can” have

the ISO standard meanings described in this chapter and the verb “must” is

not used. Unless explicitly labeled “informative”, all CC text is normative.

Any text related to meeting requirements is considered normative.

74informative ? informative text is that which “provides additional information intended to assist the understanding or use of the

document.”(ISO/IEC Directives, Part 2). Informative text is not related to

meeting requirements.

75shall ? within normative text, “shall” indicates “requirements strictly to be followed in order to conform to the document and from which no deviation is

permitted.” (ISO/IEC Directives, Part 2)

76should ? within normative text, should indicates “that among several possibilities one is recommended as particularly suitable, without mentioning

or excluding others, or that a certain course of action is preferred but not

necessarily required.”(ISO/IEC Directives, Part 2) The CC interprets 'not

necessarily required' to mean that the choice of another possibility requires a

justification of why the preferred option was not chosen.

77may ? within normative text, may indicates “a course of action permissible within the limits of the document”(ISO/IEC Directives, Part 2)

78can ? within normative text, can indicates “statements of possibility and capability, whether material, physical or causal”(ISO/IEC Directives, Part 2)

Page 14 of 61 Version 2.3 August 2005

Symbols and abbreviated terms

4 Symbols and abbreviated terms

79The following abbreviations are common to more than one part of the CC: CC Common Criteria

EAL Evaluation Assurance Level

IT Information Technology

PP Protection Profile

SF Security Function

SFP Security Function Policy

SOF Strength of Function

ST Security Target

TOE Target of Evaluation

TSC TSF Scope of Control

TSF TOE Security Functions

TSFI TSF Interface

TSP TOE Security Policy

August 2005 Version 2.3 Page 15 of 61

Overview 5 Overview

80This chapter introduces the main concepts of the CC. It identifies the target audience, evaluation context, and the approach taken to present the material.

5.1 Introduction

81Information held by IT products or systems is a critical resource that enables organisations to succeed in their mission. Additionally, individuals have a

reasonable expectation that their personal information contained in IT

products or systems remain private, be available to them as needed, and not

be subject to unauthorised modification. IT products or systems should

perform their functions while exercising proper control of the information to

ensure it is protected against hazards such as unwanted or unwarranted

dissemination, alteration, or loss. The term IT security is used to cover

prevention and mitigation of these and similar hazards.

82Many consumers of IT lack the knowledge, expertise or resources necessary to judge whether their confidence in the security of their IT products or

systems is appropriate, and they may not wish to rely solely on the assertions

of the developers. Consumers may therefore choose to increase their

confidence in the security measures of an IT product or system by ordering

an analysis of its security (i.e. a security evaluation).

83The CC can be used to select the appropriate IT security measures and it contains criteria for evaluation of security requirements.

5.1.1 Target audience of the CC

84There are three groups with a general interest in evaluation of the security properties of IT products and systems: TOE consumers, TOE developers,

and TOE evaluators. The criteria presented in this document have been

structured to support the needs of all three groups. They are all considered to

be the principal users of this CC. The three groups can benefit from the

criteria as explained in the following paragraphs.

5.1.1.1 Consumers

85The CC plays an important role in supporting techniques for consumer selection of IT security requirements to express their organisational needs.

The CC is written to ensure that evaluation fulfils the needs of the consumers

as this is the fundamental purpose and justification for the evaluation

process.

86Consumers can use the results of evaluations to help decide whether an evaluated product or system fulfils their security needs. These security needs

are typically identified as a result of both risk analysis and policy direction.

Consumers can also use the evaluation results to compare different products

or systems. Presentation of the assurance requirements within a hierarchy

supports this need.

Page 16 of 61 Version 2.3 August 2005

Overview

87The CC gives consumers -- especially in consumer groups and communities of interest -- an implementation-independent structure termed the Protection

Profile (PP) in which to express their special requirements for IT security

measures in a TOE.

5.1.1.2 Developers

88The CC is intended to support developers in preparing for and assisting in the evaluation of their products or systems and in identifying security

requirements to be satisfied by each of their products or systems. It is also

quite possible that an associated evaluation methodology, potentially

accompanied by a mutual recognition agreement for evaluation results,

would further permit the CC to support someone, other than the TOE

developer, in preparing for and assisting in the evaluation of a developer s

TOE.

89The CC constructs can then be used to make claims that the TOE conforms to its identified requirements by means of specified security functions and

assurances to be evaluated. Each TOE s requirements are contained in an

implementation-dependent construct termed the Security Target (ST). One or

more PPs may provide the requirements of a broad consumer base.

90The CC describes security functions that a developer could include in the TOE. The CC can be used to determine the responsibilities and actions to

support evidence that is necessary to support the evaluation of the TOE. It

also defines the content and presentation of that evidence.

5.1.1.3 Evaluators

91The CC contains criteria to be used by evaluators when forming judgements about the conformance of TOEs to their security requirements. The CC

describes the set of general actions the evaluator is to carry out and the

security functions on which to perform these actions. Note that the CC does

not specify procedures to be followed in carrying out those actions.

5.1.1.4 Others

92While the CC is oriented towards specification and evaluation of the IT security properties of TOEs, it may also be useful as reference material to all

parties with an interest in or responsibility for IT security. Some of the

additional interest groups that can benefit from information contained in the

CC are:

a)system custodians and system security officers responsible for

determining and meeting organisational IT security policies and

requirements;

b)auditors, both internal and external, responsible for assessing the

adequacy of the security of a system;

August 2005 Version 2.3 Page 17 of 61

Overview

c)security architects and designers responsible for the specification of

the security content of IT systems and products;

d)accreditors responsible for accepting an IT system for use within a

particular environment;

e)sponsors of evaluation responsible for requesting and supporting an

evaluation; and

f)evaluation authorities responsible for the management and oversight

of IT security evaluation programmes.

5.2 Evaluation

context

93In order to achieve greater comparability between evaluation results, evaluations should be performed within the framework of an authoritative

evaluation scheme that sets the standards, monitors the quality of the

evaluations and administers the regulations to which the evaluation facilities

and evaluators must conform.

94The CC does not state requirements for the regulatory framework. However, consistency between the regulatory frameworks of different evaluation

authorities will be necessary to achieve the goal of mutual recognition of the

results of such evaluations. Figure 1 depicts the major elements that form the

context for evaluations.

95Use of a common evaluation methodology contributes to the repeatability and objectivity of the results but is not by itself sufficient. Many of the

evaluation criteria require the application of expert judgement and

background knowledge for which consistency is more difficult to achieve. In

order to enhance the consistency of the evaluation findings, the final

evaluation results could be submitted to a certification process. The

certification process is the independent inspection of the results of the

evaluation leading to the production of the final certificate or approval. The

certificate is normally publicly available. It is noted that the certification

process is a means of gaining greater consistency in the application of IT

security criteria.

96The evaluation scheme, methodology, and certification processes are the responsibility of the evaluation authorities that run evaluation schemes and

are outside the scope of the CC.

Page 18 of 61 Version 2.3 August 2005

Overview

Figure 1 - Evaluation Context

5.3 Organisation of the Common Criteria

97The CC is presented as a set of distinct but related parts as identified below.

Terms used in the description of the parts are explained in chapter 6.

a)Part 1, Introduction and general model, is the introduction to the

CC. It defines general concepts and principles of IT security

evaluation and presents a general model of evaluation. Part 1 also

presents constructs for expressing IT security objectives, for selecting

and defining IT security requirements, and for writing high-level

specifications for products and systems. In addition, the usefulness of

each part of the CC is described in terms of each of the target

audiences.

b)Part 2, Security functional requirements, establishes a set of

functional components as a standard way of expressing the functional

requirements for TOEs. Part 2 catalogues the set of functional

components, families, and classes.

c)Part 3, Security assurance requirements, establishes a set of

assurance components as a standard way of expressing the assurance

requirements for TOEs. Part 3 catalogues the set of assurance

components, families and classes. Part 3 also defines evaluation

criteria for PPs and STs and presents evaluation assurance levels that

define the predefined CC scale for rating assurance for TOEs, which

is called the Evaluation Assurance Levels (EALs).

August 2005 Version 2.3 Page 19 of 61

Overview

98In support of the three parts of the CC listed above, it is anticipated that other types of documents will be published, including technical rationale material

and guidance documents.

99The following table presents, for the three key target audience groupings, how the parts of the CC will be of interest.

Consumers Developers Evaluators

Part 1 Use for

background

information and

reference

purposes.

Guidance

structure for PPs.

Use for background

information and

reference for the

development of

requirements and

formulating security

specifications for

TOEs.

Use for

background

information and

reference purposes.

Guidance structure

for PPs and STs.

Part 2 Use for guidance

and reference

when formulating

statements of

requirements for

security functions.

Use for reference

when interpreting

statements of

functional

requirements and

formulating

functional

specifications for

TOEs.

Use as mandatory

statement of

evaluation criteria

when determining

whether a TOE

effectively meets

claimed security

functions.

Part 3 Use for guidance

when determining

required levels of

assurance.

Use for reference

when interpreting

statements of

assurance

requirements and

determining

assurance approaches

of TOEs.

Use as mandatory

statement of

evaluation criteria

when determining

the assurance of

TOEs and when

evaluating PPs and

STs.

Table 1 - Roadmap to the Common Criteria

Page 20 of 61 Version 2.3 August 2005

General model

model

6 General

100This chapter presents the general concepts used throughout the CC, including the context in which the concepts are to be used and the CC approach for

applying the concepts. CC Part 2 and CC Part 3 expand on the use of these

concepts and assume that the approach described is used. This chapter

assumes some knowledge of IT security and does not propose to act as a

tutorial in this area.

101The CC discusses security using a set of security concepts and terminology.

An understanding of these concepts and the terminology is a prerequisite to

the effective use of the CC. However, the concepts themselves are quite

general and are not intended to restrict the class of IT security problems to

which the CC is applicable.

context

6.1 Security

6.1.1 General security context

102Security is concerned with the protection of assets from threats, where threats are categorised as the potential for abuse of protected assets. All

categories of threats should be considered; but in the domain of security

greater attention is given to those threats that are related to malicious or other

human activities. Figure 2 illustrates high level concepts and relationships.

Figure 2 - Security concepts and relationships

103Safeguarding assets of interest is the responsibility of owners who place value on those assets. Actual or presumed threat agents may also place value

on the assets and seek to abuse assets in a manner contrary to the interests of

the owner. Owners will perceive such threats as potential for impairment of

the assets such that the value of the assets to the owners would be reduced.

Security specific impairment commonly includes, but is not limited to,

damaging disclosure of the asset to unauthorised recipients (loss of August 2005 Version 2.3 Page 21 of 61

本文来源：https://www.bwwdw.com/article/k26q.html