IT Security Evaluation Methods Lecture Notes (5/7)

고려대학교정보보호대학원

마스터 제목 스타일 편집


CC Part 1 :General Model





3

Goal

Develop a standardized methodology for specifying, designing, and evaluating IT products that perform security functions which would be widely recognized and yield consistent, repeatable results.

What is the CC?



4

ISO/IEC 15408

Part 1 : Provides a brief history of the CC, basic concepts and terminology.

Part 2 : Catalog of standardized security functional requirements.

Part 3 : Catalog of standardized security assurance requirements.

What is the CC?



5

CC Security Requirements

TOE Security ( ) Requirements

Requirements implementing the security objectives stated in PP.

TOE Security ( ) Requirements

The level of trust that TOE really provides the required security functions.

Security Requirements for ( )

Requirements derived from the operational environment in which the customer intends to deploy the TOE.

What is the CC?



6

What is the CC?



7

Out of Scope :

What is the CC?



8

CC will provide benefits to :

Consumers :

A wider choice of evaluated products

Developers :

Greater understanding of consumer requirements

Greater access to markets

What is the CC?



9

Terminology (Textbook p.255)

What is the CC?

CC 공통평가기준 (Common Criteria)

EAL 평가보증등급 (Evaluation Assurance Level)

IT 정보기술 (Information Technology)

PP 보호프로파일 (Protection Profile)

SAR 보증요구사항 (Security Assurance Requirement )

SFP 보안기능정책 (Security Function Policy)

SFR 보안기능요구사항 (Security Functional Requirement)

ST 보안목표명세서 (Security Target)

TOE 평가대상 (Target of Evaluation)

TSF TOE 보안기능성 (TOE Security Functionality)

TSFI TOE 보안기능 인터페이스 (TOE Security Function Interface)



10

TOE (Target of Evaluation)

TOE : IT product or system and its associated ( ) that is the subject of an evaluation.

Product :

System :



11

PP (Protection Profile)

List of consumer’s security requirements, described in a very specific way defined by the CC

Implementation-independent PP represents ( )

ST (Security Target)

Document that identifies what a product actually does

Specific to an implementation ST represents ( )

PP & ST



12

CC Part 3

* Assurance Classes

* Assurance Components

CC Part 2Security Functional Requirements

* Functional Classes

* Functional Families

* Functional Components

* Detailed Req.

* Functional Packages

CC Part 1Introduction and General Model

* Assurance Families

* Detailed Req.

* Eval. Assur. Levels

Security Assurance Requirements

CC Part 3

* General Concepts

* Evaluation Model

CC Structure



13

Part 1 : Introduction and general model

Defines the general concepts and principles of IT security evaluation.

Presents a general model of evaluation.

CC Structure



14

Part 2 : Security functional components

Establishes a set of functional components that serve as standard templates upon which to base functional requirements for TOEs.

CC Part 2 catalogues the set of functional components and organizes them in familiesand classes.

CC Structure



15

Part 3 : Security assurance components

Establishes a set of assurance components that serve as standard templates upon which to base assurance requirements for TOEs.

Defines evaluation criteria for PPs and STs and presents seven pre-defined assurance packages which are called the Evaluation Assurance Levels (EALs).

CC Structure



16

CC Evaluation & Validation Procedure

PP ST

TOE evaluation

Validation/ Certification

TOE & CC evidence

CC

CEM

Evaluation Scheme

evaluation results

TOE development



17

Assets & Countermeasures

Security

Protection of assets

Assets

Entities that someone places value upon

Contents of a file or a server; The authenticity of votes cast in an election; Access to a classified facility..

Environment(s)

The environment(s) in which these assets are located

The computer room of a bank; Connected to the Internet; a LAN; A general office environment..



18

Assets & Countermeasures–Security Concepts and Relationships –

Owners

Countermeasures

Threats

Risk

Assets

Threat agents

impose

wish to minimizevalue

to reduce

to

give rise to

to

wish to abuse and/or may damage

that increase



19

Assets & Countermeasures– Evaluation Concepts and Relationships –

confidence

sufficient

correct

owners

evaluation

countermeasures

risk

assets

provides

require

that

and therefore minimize

to

andthereforeminimize

are



20

Sufficiency of the Countermeasures

Analysed through ( )

ST divides countermeasures in 2 groups The security objectives for the TOE

The security objectives for the Operational Environment

Correctness of the Countermeasures

Correctness of the TOE

Correctness of the Operational Environment

Assets & Countermeasures– Sufficiency & Correctness of Countermeasures –



21

Correctness of the TOE

Analysed through various activities such as :

Testing the TOE Examining various design representations of the

TOE Examining the physical security of the development

environment of the TOE

Determine correctness in the form of Security Assurance Requirements :

If the SARs are met, there exists assurance in the correctness of the TOE and the TOE is therefore less likely to contain vulnerabilities that can be exploited by attackers.

SAR : Structured description to determine the correctness of the TOE




22

Correctness of the Operational Environment

In the CC, ( ) assurance is obtained regarding the correctness of the operational environment. Or, in other words, the operational environment is ( ) evaluated.

As far as the evaluation is concerned, the operational environment is ( ) to be a 100% correct instantiation of the security objectives for the operational environment.




23

Evaluation

2 Types of Evaluation

ST/TOE evaluation

PP evaluation

Note) In many places, the CC uses the term evaluation (without qualifiers) to refer to an ST/TOE evaluation.



24

Evaluation

ST/TOE evaluation

ST evaluation

The ( ) of the TOE and the operational environment are determined

TOE evaluation

The ( ) of the TOE is determined. As said earlier, the TOE evaluation ( ) assess correctness of the operational environment.

The principal inputs to a TOE evaluation are : the evaluation evidence, which includes the TOE and ST, but will usually also include input from the development environment, such as design documents or developer test results.



25

PP and Package

To allow consumer groups and communities of interest to express their security needs, and to facilitate writing STs, the CC provides two special constructs :

Packages

Protection Profiles (PPs)



26

PP and Package

Package : Set of security requirements

A ( ), containing only SFRs, or

an ( ), containing only SARs

(e.g.) Evaluation Assurance Levels (EALs) in CC Part 3

( ) containing both SFRs and SARs are NOT allowed.

A package can be defined by any party and is intended to be re-usable. Packages can be used in the construction of

larger packages, PPs and STs.



27

PP and Package

PP : Whereas an ST always describes a specific TOE (e.g. the MinuteGap v18.5 Firewall), a PP is intended to describe a TOE type (e.g. firewalls).

The same PP may therefore be used as a template for many different STs to be used in different evaluations.

A PP describes the general requirements for a TOE type, and is therefore typically written by :

A user community seeking to come to a consensus on the requirements for a given TOE type;

A developer of a TOE, or a group of developers of similar TOEs wishing to establish a minimum baseline for that type of TOE;

A government or large corporation specifying its requirements as part of its acquisition process.



28

PP and Package

PPs can be evaluated (by the APE in CC Part 3) in order to demonstrate that :

The PP is complete, consistent, and technically sound and

The PP is suitable for use as a template on which to build another PP or an ST.

Basing a PP/ST on an evaluated PP has two advantages :

There is much less risk that there are errors, ambiguities or gaps in the PP.

Evaluation of the new PP/ST may often re-use evaluation results of the evaluated PP, resulting in less effort for evaluating the new PP/ST.



29

PP and Package

Using PPs and Packages

If an ST claims to be conformant to one or more packages and/or Protection Profiles, the evaluation of that ST will (among other properties of that ST) demonstrate that the ST actually conforms to these packages and/or PPs that they claim conformance to. This allows the following process :

1. (PP evaluation) An organisation seeking to acquire a particular type of IT security product develops their security needs into a PP, then has this PP evaluated and publishes it;

2. (ST evaluation) A developer takes this PP, writes an ST that claims conformance to the PP and has this ST evaluated;

3. (TOE evaluation) The developer then builds a TOE (or uses an existing one) and has this TOE evaluated against the ST.



30

PP and Package

Using Multiple PPs

The CC also allows PPs to conform to other PPs, allowing chains of PPs to be constructed, each based on the previous one(s).

Examples of Multiple PPs

One could take a PP for an Integrated Circuit and a PP for a Smart Card OS, and use these to construct a Smart Card PP (IC and OS) that claims conformance to the other two.

One could then write a PP on Smart Cards for Public Transport based on the Smart Card PP and a PP on Applet Loading.

Finally, a developer could then construct an ST based on this Smart Cards for Public Transport PP.



31

Evaluation Results (Textbook p.54 Exhibit 34)

Evaluate PP

Evaluate ST

PP EvaluationResults

Evaluated PP PP Registry

ST EvaluationResults

Evaluated ST

TOE EvaluationResults

Evaluated TOE

EPL (EvaluatedProducts

Lists)

Evaluate TOE



32

SAR/SFR Structure

Class

Family 1

Component 1

Element 1트 1

Component 2 Component 3

Element 2 Element 3∙∙∙

∙∙∙

Family 2

(예) ADV : 개발클래스

(예) ADV_HLD : 기본설계

(예) ADV_HLD.1 : 서술적인기본설계

(예) ADV_HLD.1.X.D : 개발자요구사항ADV_HLD.1.X.C : 증거요구사항ADV_HLD.1.X.E : 평가자요구사항



33

Class

The most general grouping of security components All the members of a class share a common general

focus(목적)

Family

A grouping of components that share a more specific focus But may differ in emphasis or rigour

Component

The ( ) unit in the CC The set of components within a family may be ordered to

represent increasing strength or capability

Element

The ( ) expression of a security need ( ).

SAR/SFR Structure



34

SAR/SFR Structure

형상관리(ACM)

배포 및 운영(ADO)

개발(ADV)

설명서(AGD)

생명주기 지원

(ALC)

시험(ATE)

취약성 평가

(AVA)

형상관리자동화(ACM_AUT)

형상관리능력(ACM_CAP)

형상관리범위(ACM_SCP)

배포(ADO_DEL)

설치, 생성, 시동(ADO_IGS)

기능명세(ADV_FSP)

상위수준설계(ADV_HLD)

구현표현(ADV_IMP)

TSF 내부(ADV_INT)

하위수준설계(ADV_LLD)

표현의일치성(ADV_RCR)

보안정책모델(ADV_SPM)

관리자설명서(AGD_ADM)

사용자설명서(AGD_USR)

개발보안(ALC_DVS)

결함교정(ALC_FLR)

생명주기정의(ALC_LCD)

도구와기법(ALC_TAT)

범위(ATE_COV)

깊이(ATE_DPT)

기능시험(ATE_FUN)

독립시험(ATE_IND)

비밀채널분석(AVA_CCA)

오용(AVA_MSU)

보안기능강도(AVA_SOF)

취약성분석(AVA_VLA)

보증 클래스 보증 패밀리

1 2 3 4 5

서술적인 기본설계

보안기능과 비 보안기능을 분리

준정형화된 기본설계

준정형화된 설계 및 시헙(TSF 메커니즘)

정형화된 기본설계

개발자 요구사항ADV_HLD.2.1D 개발자는 TSF 기본설계 제공

ADV_HLD.2

증거 요구사항(제출물 요구사항)ADV_HLD.2.1C 비정형화 서술ADV_HLD.2.2C 내부적으로 일관성ADV_HLD.2.3C TSF의 구조를 서브시스템으로 서술ADV_HLD.2.4C 서브시스템 보안 기능성 서술ADV_HLD.2.5C 하부구조(하드웨어, 펌웨어 등] 식별ADV_HLD.2.6C TSF 서브시스템의 모든 인터페이스 식별ADV_HLD.2.7C TSF 서브시스템의 외부 인터페이스 식별ADV_HLD.2.8C 인터페이스 목적, 예외사항, 오류 등ADV_HLD.2.9C TSP 수행 서브시스템과 기타 서브시스텝 구분

평가자 요구사항ADV_HLD.2.1E 제동된 정보가 증가요구사항 만족하는지 확인ADV_HLD.2.1E 기본설계가 TOE 보안기능요구사항 정확히 기술



35

CC functional and assurance components may be used exactly as defined in the CC, or they may be tailored through the use of permitted operations.

Iteration Allows a component to be used more than once with

varying operations

Assignment Allows the specification of parameters

Selection Allows the specification of one or more items from a list

Refinement Allows the addition of details

SFR/SAR Operations



36

The Iteration Operation

The PP/ST author performs an iteration operation by including multiplerequirements based on the samecomponent.

(e.g.) FCS_COP.1에 정교화 오퍼레이션을반복하여 적용

FCS_COP.1(1) 암호 연산 컴포넌트에 PKI 알고리즘의 구현을 요구하는 내용 서술

FCS_COP.1(2) 암호 연산 컴포넌트에 DES 알고리즘의 구현을 요구하는 내용 서술

SFR/SAR Operations



37

The Assignment Operation

An assignment operation occurs where a given component contains an element with a parameter that may be set by the PP/ST author.

Whenever an element in a PP contains an assignment, a PP author shall do one of four things :

SFR/SAR Operations

FIA_AFL.1.2 “실패한 인증 시도가 정의된 횟수에 도달하거나 초과하면, TSF는 [할당: 대응행동 목록]을 수행해야 한다.”

[원 문]



38

Leave the assignment uncompleted : (e.g.) FIA_AFL.1.2 “실패한 인증 시도가 정의된 횟수에도달하거나 초과하면, TSF는 [할당: 대응행동 목록]을수행해야 한다.”

Complete the assignment : (e.g.) FIA_AFL.1.2 “실패한 인증 시도가 정의된 횟수에도달하거나 초과하면, TSF는 그 외부 실체가 향후 어떤주체에라도 연결되는 것을 방지해야 한다”

Narrow the assignment, to further limit the range of values that is allowed (범위 한정) :

(e.g.) FIA_AFL.1.1 “TSF는 [할당: 인증 사건의 목록]에 관련된[할당: 4~9사이의 양수] 번의 실패한 인증시도가 발생한경우 이를 탐지해야 한다”

Transform the assignment to a selection, thereby narrowing the assignment :

(e.g.) FIA_AFL.1.2 “실패한 인증 시도가 정의된 횟수에도달하거나 초과하면, TSF는 [선택: 그 사용자가 향후 어떤주체에라도 연결되는 것을 방지, 관리자에게 통보]해야 한다.”

SFR/SAR Operations



39

Whenever an element in an ST contains an assignment, an ST author shall complete that assignment, as indicated in b) above. Options a), c) and d) are not allowed for STs.

SFR/SAR Operations



40

The Selection Operation

The selection operation occurs where a given component contains an element where a choice from several items has to be made by the PP/ST author.

Whenever an element in a PP contains a selection, the PP author may do one of three things :

SFR/SAR Operations

FCO_NRO.1.1 “TSF는 [선택: 발신자, 수신자, [할당 : 제3자 목록]]의 요청시 전송된 [할당 : 정보 유형 목록]의 발신 증거를 생성할 수 있어야 한다”

[원 문]



41

Leave the selection uncompleted :

FCO_NRO.1.1 “TSF는 [선택: 발신자, 수신자, [할당 : 제3자 목록]]의 요청 시 전송된 [할당 : 정보 유형 목록]의발신 증거를 생성할 수 있어야 한다”

Complete the selection by choosing one or more items :

FCO_NRO.1.1 “TSF는 수신자의 요청 시 전송된 [할당 : 정보 유형 목록]의 발신 증거를 생성할 수 있어야 한다”

Restrict the selection by removing some of the choices, but leaving two or more :

FCO_NRO.1.1 “TSF는 [선택: 수신자, [할당 : 제3자목록]]의 요청 시 전송된 [할당 : 정보 유형 목록]의 발신증거를 생성할 수 있어야 한다”

SFR/SAR Operations



42

Whenever an element in an ST contains a selection, an ST author shall complete that selection, as indicated in b) above. Options a) and c) are not allowed for STs.

SFR/SAR Operations



43

The Refinement Operation

The PP/ST author performs a refinement by altering that requirement.

The first rule for a refinement is that a TOE meeting the refined requirement also meets the unrefined requirement in the context of the PP/ST (i.e. a refined requirement must be “stricter” than the original requirement). If a refinement does not meet this rule, the resulting refined requirement is considered to be an extended requirement and shall be treated as such.

(e.g.) FIA_UAU.2.1 “TSF는 사용자를 대신하여 TSF가 중재하는모든 행동을 허용하기 전에 사용자를 성공적으로 인증해야 한다”

FIA_UAU.2.1 “TSF는 사용자를 대신하여 TSF가 중재하는 모든행동을 허용하기 전에 사용자/패스워드를 사용하여 사용자를성공적으로 인증해야 한다”

SFR/SAR Operations



44

The only exception to this rule is that a PP/ST author is allowed to refine a SFR to apply to some but not all subjects, objects, operations, security attributes and/or external entities. (However, this exception does NOT apply to refining SFRs that are taken from PPs that compliance is being claimed to.)

(e.g.) FIA_UAU.2.1 “TSF는 사용자를 대신하여 TSF가중재하는 모든 행동을 허용하기 전에 사용자를성공적으로 인증해야 한다”

FIA_UAU.2.1 “TSF는 사용자를 대신하여 TSF가 중재하는모든 행동을 허용하기 전에 인터넷으로 접속하는사용자를 성공적으로 인증해야 한다”

SFR/SAR Operations



45

The second rule for a refinement is that the refinement shall be related to the original component.

For example, refining an audit component with an extra element on prevention of electromagnetic radiation is not allowed.

A special case of refinement is an editorial refinement, where a small change is made in a requirement, i.e. rephrasing a sentence due to adherence to proper English grammar, or to make it more understandable to the reader.

(original) FPT_FLS.1.1 “TSF는 다음과 같은 유형의 장애들이발생한 경우 안전한 상태를 유지해야 한다: CPU의 고장”

(refinement ver.1) FPT_FLS.1.1 “TSF는 다음과 같은 장애가발생한 경우 안전한 상태를 유지해야 한다: CPU의 고장”

(refinement ver.2) FPT_FLS.1.1 “TSF는 CPU의 고장시안전한 상태를 유지해야 한다”

SFR/SAR Operations




CC Part 1 :General Model

Engineering

IT Security Evaluation Methods Lecture Notes (5/7)