IT Security Evaluation Methods Lecture Notes (4/7)

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

마스터 제목 스타일 편집


Introduction to CC





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

“A few lines of code can wreak more havoc than a bomb.”

- Tom Ridge -

(Former) Secretary of the U.S. Department of Homeland Security



7

Early 1980s : Government, military drove early evaluation processes.

Their desire to use commercial products led to businesses developing methodologies for evaluating security, trustworthiness of systems.

Methodologies provide combination of

( ) requirements

( ) requirements

Levels of trust

Brief History



8

Brief History

1985 : DOD 5200.28STD (Orange Book, or TCSEC): standard reference for computer security for DoD

Developed by National Computer Security Center, US Dept. of Defense.

Specifies evaluation classes (C1, C2, B1, B2, B3, A1).

Specifies ( ) and ( )requirements for each class.

Heavily influenced by ( ) and ( ) concept.

Emphasizes confidentiality



9

Brief History

Mid 80s - Mid 90s :

The Red Book (Trusted Network Interpretation (TNI) of the Orange Book)

Series that expanded on Orange Book in specific areas was called “Rainbow Series”.

FIPS-140 for commercial/civilian government cryptographic modules (DES, AES)

Canada, UK, European Community develop standards similar to and beyond the Orange Book.

Mid 90s onward : Common Criteria



10

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네덜란드



11

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



12

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?



13

International agreement between CC certificate producing and/or consuming nations to recognize CC evaluations for ( ).

Eliminates ( ) of IT products and PPs.

This saves vendors and users time and resources.

CAP( ) and CCP ( )

CAP : Certificate Authorizing Participants Unanimity of the whole CCRA members

CCP : Certificate Consuming Participants

What is the CCRA?



14

Limited to the first four security levels of the CC : ( ).

What is the CCRA?



15

The 17 CAP (Certificate Authorizing Participants) Countries :

Australia, Canada, France, Germany, India, Italy, Japan, Malaysia, Netherlands, New Zealand, Norway, Republic of Korea, Spain, Sweden, Turkey, UK, US

The 9 CCP(Certificate Consuming Participants) Countries :

Austria, Czech, Denmark, Finland, Greece, Hungary, Israel, Pakistan, Singapore

What is the CCRA?



16

CC Certificate



17

CCEVS



18

CCEVS - USA -

NSA

NIST

NIAPCCEVS 인증기관

NVLAP

평가기관요구사항

CCTL(ISO 17025)

인정

기술사항협의

평가신청인

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

인증보고서인증제품목록

국제공통평가기준인증서

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

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

평가결과

기술감독



19

CCEVS - Korea -

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

인정기관(기술표준원)

평가기관(KISA, KTL, KOSYAS)

인정

평가신청인

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

평가결과

평가업무관리감독

인증서발급

평가자문

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

( ISO 17025 적합여부심사 )



20

CC Process - Korea -



21




22




23

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



24

CC DocumentsSecurity Require-ments

Functional Descrip-

tion

High-Level Design

Source Code/

H/W plan

Implementation



25

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



26

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



27

Process & Documents – CC vs. CMVP

Vendor(or Sponsor)

Designs andProduces

H/W, S/W, F/W

• Define Boundary

• Define Approved Modeof Operation

• Security Policy

CST Lab

Tests forConformance

Derived Test Requirements (= CEM@CC)

• Algorithm Testing• Documentation Review• Source Code Review• Operational andPhysical Testing

CMVPNIST and CSEC

Validates

• Review Test Results• Ongoing NVLAP

Assessment• Issue Certificates• NIST Cost Recovery

Fee

User

Specifies andPurchases

• Security and Assurance

Applications or products with embedded modules

※ CST Lab : Cryptographic and Security Testing Lab accredited by NVLAP(National Voluntary LaboratoryAccreditation Program)



28

Country CST Lab

USA

•ÆGISOLVE, INC. (USA - CA)• Aspect Labs, a division of BKP Security, Inc. (USA - CA)• atsec Information Security Corporation (USA - TX)• CEAL: a CygnaCom Solutions Laboratory (USA - VA)• COACT Inc. CAFE Laboratory (USA - MD)• Computer Sciences Corporation (USA - MD)• ICSA Labs, An Independent Division of Verizon Business (USA - PA)• InfoGard Laboratories, Inc. (USA - CA)• SAIC Accredited Testing & Evaluation (AT&E) Labs (USA - MD)• SAIC Accredited Testing & Evaluation (AT&E) Labs (USA - VA)•Underwriters Laboratories, Inc. (USA - IL)

Canada•DOMUS IT Security Laboratory (Canada)• EWA - Canada IT Security Evaluation & Test Facility (Canada)

Germany • TÜV Informationstechnik GmbH (Germany)

Japan• ECSEC Laboratory Inc. (Japan)• Information Technology Security Center (Japan)

Spain • Epoche & Espri (Spain)

Taiwan • TTC IT Security Evaluation Laboratory (Taiwan, R.O.C.)

※ http://csrc.nist.gov/groups/STM/testing_labs/index.html




29


제출물 세부항목

기본 및 상세설계

암호모듈 명세, 암호모듈 포트와 인터페이스, 역할, 서비스 및 인증, 유한상

태 모델, 물리적 보안, 운영환경, 암호키 관리, 전자기 간섭/전자기 적합성

(EMI/EMC), 자가 시험, 설계 보증, 기타 공격의 완화

형상관리암호모듈을 구성하는 모든 구성요소, 암호모듈 버전 부여방법, 암호모듈 형

상변경 통제 방법

제품 사용 설명

암호모듈 설치 절차 및 보안관리 방법, 암호모듈 운용 방법, 암호모듈의 보안

기능, 경고 등 사용방법, 안전한 시동, 백업, 유지보수 및 운용에 대한 절차,

하드웨어 보안모듈의 경우 자체진단 및 진단결과에 대한 설명과 예시

시험 절차 및 결과서 시험 계획(시험환경 및 구성, 시험 항목), 시험절차, 시험 결과

취약성 분석 및 대응 방법 기술문서 암호모듈에 대하여 명백히 알려진 취약성에 대한 분석과 대응 방법 기술

평가대상 제품 제품 및 원시프로그램 또는 하드웨어 설계서



30

Common Criteria

Part 1 : General Information.

Part 2 : Catalogue of FunctionalRequirements. What are the Security Functions?

Part 3 : Catalogue of AssuranceRequirements. How deeply and rigorous are Security Functions

evaluated(designed & implemented)?

CC Structure



31

CC Structure

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



32

Part 1 : Defines general concepts and principles of IT security evaluation and presents a general model of evaluation. Part 1 also defines PP and ST.

Part 2 : Establishes a set of security functional components as a standard way of expressing the security requirements for IT products and systems.

Part 3 : Produces a catalog of establishes set of assurance components that can be used as a standard way of expressing the assurance requirements for IT products and systems. Part 3 also presents the 7 EALs, which are predefined packages of assurance components that make up the CC scale for rating confidence in the security of IT products and systems.

CC Structure



33

Common Criteria Evaluation Methodology(CEM)

Evaluation methodology to which the criteria is applied.

Primarily for evaluators reviewing vendor assurance measures and for validators confirming evaluator activities/ findings.

( )

A report submitted to the Certification Board summarizing the results of the evaluation and forming the basis of the certification.

Because the ETR contains sensitive information, it is not a public document but its distribution is subject to the rules of the national scheme.

CC Structure



34

( )

Each country has a Scheme.

CC Structure



35

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



36

CC Evaluation Process

RFP

Proposal

Product (+ 관련 문서)

제안서 심사

검 수



37

CC Evaluation Process

기능 요구사항

보안 문제

보안목적

기능명세

설계 설명

구현 표현

구현

TOE 요약명세

정책 모델

A B

A B

A가 B에 대응 (요구사항에 따라)

A가 B로 상세화

ASE_TSS

ADV_SPM

APE/ASE_OBJ

APE/ASE_REQ

ADV_FSP

ADV_TDS

ADV_IMP

ALC_CMC.5 ATE_AVA

모든 설계 분해 단계에서수행된 상호 보완적인 분석

구현 시 수행된 기능 시험및 침투 시험

보안문제, 보안기능요구사항(SFR)과

보안목적 간 일치성에 대한요구사항을 정의

TOE 요약명세에 대한 요구사항을정의

시험클래스와 취약성 평가 클래스에서시험된 TSF가 개발 클래스의 분해 단계에서

모두 서술된 사항임을 검증

선택된 SFR을 정형화하여모델링하고, 기능명세와 정형화된모델간의 일치성 제공에 대한

요구사항 정의

기능명세, 설계, 구현에 해당하는 각표현을 기능요구사항에 정의



38

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↑



39

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



40

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!




41


+

보안감사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)



42




43

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



44

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는다음의 [할당 : 표준목록]에부합하는명세된 암호키생성알고리즘 [할당 : 암호키생성알고리즘]과명세된암호길이 [할당 : 암호키길이]에따라암호키를생성해야한다.



45

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



46

SARs



47

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



48

EAL (1~7) rank is a scale of increasing assurance gained that ( ) at increasing levels of attack potential (expertise, resources, motivation)

i.e., This rank indicates how rigorous the verification process was, ( ) the TOE’s actual security.

What is the EAL?



49

Level EAL1 The lowest level which should be considered for

purposes of Evaluation. Not Really Used in Practice.

Level EAL2 Best that can be achieved without imposing some

additional tasks on a developer. Good starting point for vendors with little documentation and no well-defined security engineering practices.

제품을 구성하는 ( )에 대한분석과 시험.

Level EAL3 Allows a conscientious developer to benefit from

positive security engineering design without alteration of existing reasonably sound development practices.

보안기능을 구성하는 ( )분석과 시험.

What is the EAL?



50

Level EAL4 The best that can be achieved without significant

alteration of current good development practices. 서브시스템을 구성하는 ( )분석과 시험.

Level EAL5 The best achievable via preplanned, good quality,

careful security-aware development without unduly expensive practices.

Level EAL6 A "high tech" level for (mainly military) use in

environments with significant threats and moderately valued assets.

What is the EAL?



51

Level EAL7 The greatest amount of evaluation assurance

attainable whilst remaining in the real world for real products. EAL7 is at the limits of the current technology.

EAL5~7 : 문서에 대한 요구수준은 EAL4와 유사하나 ( ).

What is the EAL?



52

What is the EAL?



53

EAL Example

평가등급에 따른 보증 컴포넌트EAL3

형상관리(ACM)

배포 및 운영(ADO)

개발(ADV)

설명서(AGD)

생명주기 지원

(ALC)

시험(ATE)

취약성 평가

(AVA)

ACM_AUTACM_CAPACM_SCPADO_DELADO_IGSADV_FSPADV_HLDADV_IMPADV_INTADV_LLDADV_RCRADV_SPMAGD_ADMAGD_USRALC_DVSALC_FLRALC_LCDALC_TATATE_COVATE_DPTATE_FUNATE_INDAVA_CCAAVA_MSUAVA_SOFAVA_VLA

1

11

1

11

1

2

1111

1

11

1

12

11

3

2

1

11

11

111

14221221

11111

112112

21

1432133

1123111

2222121213

253213432223112

2332222314

253314533233112

33332323142

2

2

1

1

2

1111

보증 클래스 보증 패밀리EAL1 EAL2 EAL4 EAL5 EAL6 EAL7

EAL3+

서술적인상세설계 준정형화된상세설계



54

EAL –CC vs. ITSEC vs. TCSEC



55

EAL –CC vs. CMVP NSTISSP #11 Guidance IA & IA-Enabled Products

NSA Involvement inProduct Evaluation

NSA Evaluated Product List

NIAP - CertifiedCCTL Evaluations

FIPS evaluatedunder CMVP

(FIPS 140-1 or 140-2)

Validated Product Listhttp://csrc.nist.gov/cryptval

Type 1 Cryptofor Classified

Le

ve

l 1

Le

ve

l 2

Le

ve

l 3

Le

ve

l 4

EAL

Basicrobustnessproducts

Mediumrobustnessproducts

Highrobustnessproducts

4

7

6

5

3

2

1

0

4+

CMVP Labs• Atlan• Cygnacom (CEAL)• CoACT• EWA• Domus• InfoGard

NIAP Labs• Booz Allen

Hamilton• Cable & Wireless• CoACT• Criterian

Levels OfRobustness

Crypto Modules and Algorithms

• CSC• Cygnacom• InfoGard• SAIC

IT Products and PP



56

Time and Expense



57

For each, in the operational environment, exploitable vulnerability the required attack potential is calculated according to the following factors :

Elapsed Time (0-19 points),

Specialist Expertise (0-8 points),

Knowledge of the TOE (0-11 points),

Window of opportunity (0-10 points) (e.g., number of samples needed, etc),

IT hardware/software or other equipment (0-9 points)

Attack Potential (according to CEM)



58

Final Assessment

TOE is resistant to

“basic” attack potential if all attacks require at least 10 points,

...

“high” attack potential if all attacks require at least 25 points.

Attack Potential (according to CEM)



59

Would CVSS be better for CC?

( )

But. .. we should note the common problem of many unknown deployment environments and configurations and the emphasis on the whole vector not just a single score.

Scoring tips are provided as a support for consistency, but less detail and examples than CC.

Attack Potential vs. CVSS



60

Common Criteria Portal



61

Common Criteria Portal



62

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

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

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

Evaluator License – Korea –



63

선임평가자 :

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

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

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

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




64


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



65

Any Others?



66

The CC is not alone.

Many evaluation programs exist (30+).

Let’s take a look at them…. briefly!

Security Assurance Landscape



67



68



69

Gain assurance from knowledge of ( ).

ISO 9000

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

Certifying Process



70

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

CMM



71

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



72

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




Introduction to CC