Common Criteria : Introduction

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

마스터 제목 스타일 편집


Common Criteria :Introduction





3

List of Terms

Term Meaning

CC Common Criteria (Official ISO name is Evaluation Criteria for Information Technology Security)

Class Grouping of families that share a common focus

Component Smallest selectable set of elements

Evaluation Assurance Level (EAL)

A package consisting of assurance components that represents a point on CC predefined assurance scale

Family A grouping of components that share security objective but may differ in emphasis



4

List of Terms

Term Meaning

Organizational Security Policy

One or more security rules, procedures, practices or guidelines imposed by organization upon its operations

Package A reusable set of either functional or assurance components, combined together to satisfy set of security policies

Protection Profile (PP)

An implementation independent set of security requirements

Security Target (ST)

A set of security requirements and specification to be used as a basis for evaluation of identified TOE

Semi-Formal Expressed in a restricted syntax language with defined semantics



5

List of Terms

Term Meaning

Target Of Evaluation (TOE)

An IT product or system and its associated administrator and user guidance documentation, that is the subject of evaluation

TOE Resource Anything consumable or usable in TOE

TOE Security Function (TSF)

A set consisting of all hardware, software and firmware of the TOE that must be relied upon for the correct enforcement of TSP

TOE Security Policy (TSP)

A set of rules that regulate how assets are managed, protected and distributed within a TOE

Trusted Channel

A means by which a use and a TSF can communicate with necessary confidence to support TSP



6

Evolution of Security Standards

Green Books

1989

IT-Security

Criteria

1989

Blue-White-Red

Book

1989

Orange Book

(TCSEC) 1985미 국

영 국

독 일

프랑스

Canadian Criteria

(CTCPEC) 1993

U.S. Federal Criteria

Draft 1993

캐나다

European

ITSEC (1991)

※ 1999년 : ISO/IEC 15408 국제 표준으로 제정

v1.0 1996v2.0 1998v2.1 1999v2.2 2004v2.3 2005v3.1 R1 2006.9v3.1 R2 2007.9

Netherlands

Criteria

1989네덜란드



7

CC Developers

Communications Security Establishment (CSE)

National Institute of Standards & Technology (NIST)

National Security Agency (NSA)

Central Service for Info. Systems Security (SCSSI)Service Central de la Securite des Systems d’ Information

German Information Security Agency (GISA, BSI)

National Communications Security Agency (NL-NCSA)

Communications-Electronics Security Group (CESG)

Canada

USA

France

Germany

UK

NorthAmerica

EuropeNetherlands



8

An international standard (ISO/IEC15408) for computer security evaluation

Does not provide ( ) list of security features.

Describes a ( ) in which...

Computer system purchasers and users can specify their security requirements.

Vendors can make claims about the security attributes of their products.

Testing laboratories can evaluate products to determine if they actually meet the claims.

What is the CC?



9

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?



10

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?



11

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?



12

What is the CC?



13

Out of Scope :

What is the CC?



14

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?



15

CC Certificate



16

CCEVS



17

CCEVS - USA -

NSA

NIST

NIAPCCEVS 인증기관

NVLAP

평가기관요구사항

CCTL(ISO 17025)

인정

기술사항협의

평가신청인

승인받은평가기관목록승인받은평가방법목록

인증보고서인증제품목록

국제공통평가기준인증서

평가신청제품및보호프로파일

사용자 정부기관 공공기관 외국정부 보안사회

평가결과

기술감독



18

CCEVS - Korea -

국가정보원 인증기관(IT 보안인증사무국)

인정기관(기술표준원)

평가기관(KISA, KTL, KOSYAS)

인정

평가신청인

사용자 정부기관 공공기관 외국정부 보안사회

평가결과

평가업무관리감독

인증서발급

평가자문

평가신청제품및보호프로파일

( ISO 17025 적합여부심사 )



19

CC Process - Korea -



20




21




22

You should prove that

IT product has been developed by using the S/W development models defined in SE, and

IT product is secure against known vulnerabilities.

CC Documents



23

CC DocumentsSecurity Require-ments

Functional Descrip-

tion

High-Level Design

Source Code/

H/W plan

Implementation



24

CC Documents

EAL5

EAL4

EAL3

EAL2

EAL1

EAL6

EAL7

Functionally Tested

Structurally Tested

Methodically Tested and Checked

Methodically Designed,Tested and Reviewed

Semi-formally Designed and Tested

Semi-formally Verified designand Tested

Formally Verified Design and Tested

EAL



25

Q) Level of Detail?

A) Should meet ( )

Security functions are ( ) from the definition in the Security Target done to the source code in the following steps :

Security function definition (Security Target)

Functional specification

High-level design

Low-level design

Implementation (source code)

CC Documents



26

Target Of Evaluation (TOE)

The TOE is the ( ) and its associated ( )that is the subject of an evaluation

Protection Profile (PP : 보호프로파일)

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

Implementation-independent PP represents ( )

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

Document that identifies what a product actually does Specific to an implementation ST represents ( )

TOE, PP and ST



27

CC Evaluation Process

RFP

Proposal

Product (+ 관련 문서)

제안서 심사

검 수



28

[Note] 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..



29

[Note] 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



30

[Note] Assets & Countermeasures– Evaluation Concepts and Relationships –

confidence

sufficient

correct

owners

evaluation

countermeasures

risk

assets

provides

require

that

and therefore minimize

to

andthereforeminimize

are



31

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

[Note] Assets & Countermeasures– Sufficiency & Correctness of Countermeasures –



32

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




33

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.




34

CC Evaluation Process –Comparisons

Foreign Domestic

Asset & Threat Assessment

Selection of Security Product

- Sufficiency

- Correctness

- Efficiency

Operation of Security Product

CC : Crypto Algorithm (X), Physical Security (X), PCI/DSS : Used in Payments IndustryKISMS : ISO/IEC 27001 + Security↑



35

SFRs are stated for an Evaluator to identify ( ) in the TOE.

SARs are provided for an Evaluator to gain a level of confidence that the SFR is accurately enforced on the TOE and confidence that the ( ).

i.e., SAR is the ( ) that it really does.

Building Blocks: SFR, SAR



36

Aspects of Assurance

Are the Security Functions correctly implemented?

Are they sufficient to counter the threats?

Are they free from flaws and vulnerabilities?

Are they free from critical side effects?

Note : Assurance also means that we can have confidence in the whole product development chain, as well as ( ), ( ) and ( ) of the product!




37


+

보안감사Security

AuditCommunication

CryptographicSupport

User DataProtection

Identification & Authentication

Security Management

PrivacyProtectionof the TSF

ResourceUtilization

TOE Access

Trusted Path/Channel

PP Evaluation ST Evaluation

ConfigurationManagement

Delivery and Operation

DevelopmentGuidance

Documents

Life CycleSupport

Test

VulnerabilityAnalysis

Maintenanceof assurance

SFR (11) SAR (10)



38

SFRs구분 클래스명 설명

FAU Security Audit (보안감사)monitor, capture, store, analyze, and report information related to security events

FCO Communication (통신)assure the identity of originators and recipients of transmitted information; nonrepudiation

FCS Cryptographic Support (암호지원)manage and control operational use of cryptographic keys

FDP User Data Protection (사용자 데이터 보호)protect (1) user data, and the associated security attributes, within a TOE and (2) data that is imported, exported, and stored

FIA Identification and Authentication (식별 및 인증)ensure unambiguous identification of authorized users and the correct association of security attributes with users and subjects

FMT Security Management (보안관리)manage security attributes, TSF data, and functions and define security roles

FPR Privacy (프라이버시)protect users against discovery and misuse of their identity

FPT Protection of the TSF (TOE 보안기능의 보호)maintain the integrity of the TSF management functions and data

FRU Resource Utilization (자원활용)ensure availability of system resources through fault tolerance and the allocation of services by priority

FTA TOE Access (TOE 접근) control user session establishment

FTP Trusted Path/Channel (안전한 경로/채널)provide a trusted communication path between users and the TSF and between the TSF and other trusted IT products



39

SFR Example

FCS 암호지원

FCS_CKM 암호 키관리

FCS_COP 암호 연산

FCS_CKM.1 암호키 생성

FCS_CKM.2 암호키 분배

FCS_CKM.3 암호키 접근

FCS_CKM.4 암호키 파기

FCS_COP.1 암호연산

FCS_CKM.1.1 TSF는다음의 [할당 : 표준목록]에부합하는명세된 암호키생성알고리즘 [할당 : 암호키생성알고리즘]과명세된암호길이 [할당 : 암호키길이]에따라암호키를생성해야한다.



40

SARs

구분 클래스명 설명

ACM Configuration Management (형상관리)control the process by which a TOE and its related documentation is developed, refined, and modified

ADO Delivery and Operation (배포 및 운영)ensure correct delivery, installation, generation, and initialization of the TOE

ADV Development (개발)ensure that the development process is methodical by requiring various levels of specification and design and evaluating the consistency between them

AGD Guidance Documents (설명서)ensure that all relevant aspects of the secure operation and use of the TOE are documented in user and administrator guidance

ALC Life Cycle Support (생명주기 지원)

ensure that methodical processes are followed during the operations and maintenance phase so that security integrity

is not disrupted

ATE Test (시험)ensure adequate test coverage, test depth, and functional and independent testing

AVA Vulnerability Analysis (취약성 평가)analyze the existence of latent vulnerabilities, such as exploitable covert channels; the misuse or incorrect configuration of the TOE; the ability to defeat, bypass, or compromise security credentials

APE PP Evaluation (보호프로파일 평가)demonstrate that the PP is complete, consistent, and technically sound

ASE ST Evaluation (보안목표명세서 평가)demonstrate that the ST is complete, consistent, technically sound, and suitable for use as the basis for a TOE evaluation



41

SARs

형상관리(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 보안기능요구사항 정확히 기술



42

선임평가자 : EAL4 이하의 등급에 대해평가수행이 가능한 자

주임평가자 : EAL3 이하의 등급에 대해평가수행이 가능한 자

수습평가자 : 상위 평가자의 평가업무를보조하는 자

Evaluator License – Korea –



43

선임평가자 :

주임평가자 자격 취득 후 평가업무에 2년 이상종사한 자로서 EAL4 이상 등급의 평가에 2회 이상참여한자 또는

정보통신분야 공인시험기관이나 정보보호업체에서평가 유관업무에 3년 이상 종사한 자 중 인증기관이요구하는 자격요건을 충족한자

주임평가자 : 수습평가자가 EAL3 이상의 등급평가수행에 1회 이상 참여한 자

수습평가자 : 인증기관 주관으로 실시하는평가인증관련 전문 교육과정을 이수하고 시험에서60점 이상을 득점한 자




44


정보보호제품 평가인증 교육 수료증 정보보호제품 평가자 자격증



45



46

Gain assurance from knowledge of ( ).

ISO 9000

SEI(Software Engineering Institute)'s Capability Maturity Model(CMM)

Certifying Process



47

와츠 험프리 (Watts S. Humphrey, 1928~) : CMM(Capability Maturity Model for SW) 제국의 황제. 소프트웨어및 시스템을 개발하는 회사의 품질 관리기준과 개선 시스템을 '프로세스'의관점에서 확립.

CMM



48

SSE-CMM = ( )

Does not specify a specific design process.

Aims to improve the design process used by an organization. (Process Improvement)

Aims to assess and organization’s capability in using security engineering processes.

The scope encompasses system engineering activities including design.

Is applicable to organizations of all sizes.

SSE-CMM - ISO/IEC 21827:2007



49

Objective measure of the maturity of security engineering

Capability Level 1 - Performed Informally

Capability Level 2 - Planned and Tracked

Capability Level 3 - Well Defined

Capability Level 4 - Quantitatively Controlled

Capability Level 5 - Continuously Improvin

SSE-CMM - ISO/IEC 21827:2007




Common Criteria :Introduction