it security evaluation methods lecture notes (7/7)

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

마스터제목스타일편집


CC Part 3 : SARs



3

Security assurance components, as defined in this CC Part 3, are the basis for the security assurance requirements expressed in a PP or a ST. These requirements establish a standard way of expressing the assurance requirements for TOEs.

This CC Part 3 catalogues the set of assurance components, families and classes. This CC Part 3 also defines evaluation criteria for ( ) and ( ) and presents ( ) that define the predefined CC scale for rating assurance for TOEs, which is called the EALs.

What is the CC Part III?



4

Organisation of CC Part 3

The paradigm used in the SARs of CC Part 3 Assurance classes, families, components, EALs

along with their relationships The detailed definitions of the EALs The detailed definitions of the CC Part 3

assurance classes A summary of the dependencies between the

assurance components A cross reference between PPs and the families

and components of the APE class / EALs and the assurance components / the CAPs and the assurance components.

What is the CC Part III?



5

Why Do We Care About Assurance?



6

Greater Evaluation Effort (Scope, Depth, Rigor)

Greater Assurance!

Evaluation Assurance Scale



7

SAR Structure

SAR hierarchy

공통평

CC assurance requirements

Assurance

보증 컴포넌트

Class introduction

Class name

Family name

Objectives

Component levelling (컴포넌트 계층관계)

Application notes

Component identification

Objectives

Application notes

Dependencies (종속관계)

Assurance

Assurance

Assurance



8

Assurance Class Structure

Class name Each assurance class is assigned a unique name. The name indicates the topics covered by the

assurance class.

Class introduction Each assurance class has an introductory section

that describes the composition of the class and contains supportive text covering the intent of the class.

Assurance families Each assurance class contains at least one

assurance family.

SAR Structure



9

SAR Structure

ADV (개발)

ADV_ARC 보안 구조

ADV_FSP 기능명세

ADV_IMP 구현의 표현

1

1 2 3 4 5 6

1 2

ADV_INT TSF 내부 1 2 3

ADV_SPM 보안정책모델 1

ADV_TDS TOE 설계 1 2 3 4 5 6



10

Assurance Family Structure

Family name Every assurance family is assigned a unique

name.

The name provides descriptive information about the topics covered by the assurance family.

Each assurance family is placed within the assurance class that contains other families with the same intent.

Objectives The objectives section of the assurance family

presents the intent of the assurance family.

SAR Structure



11

Assurance Family Structure

Component levelling Each assurance family contains one or more

assurance components.

This section of the assurance family describes the components available and explains the distinctions between them.

Assurance families containing more than one component are levelled and rationale is provided as to how the components are levelled.

This rationale is in terms of scope, depth, and/or rigour.

Application notes The application notes contains additional information

for the assurance family.

SAR Structure



12

Assurance Component Structure

Component identification The component identification section provides

descriptive information necessary to identify, categorise, register, and reference a component.

Every assurance component is assigned a unique name.

The name provides descriptive information about the topics covered by the assurance component.

Objectives The objectives section contains specific objectives for

the particular assurance component.

Application notes The application notes contains additional information

for the assurance component.

SAR Structure



13

Assurance Component Structure

Dependencies

Dependencies among assurance components arise when a component is ( ), and relies upon the presence of ( ).

Each assurance component provides a complete list of dependencies to other assurance components.

The components depended upon may have dependencies on other components.

In specific situations the indicated dependencies might not be applicable.

The PP/ST author, by ( ) for why a given dependency is not applicable, may elect not to satisfy that dependency.

SAR Structure



14

SAR Structure

보증 컴포넌트

컴포넌트 식별

응용 시 주의사항

기능 패밀리기능 패밀리보증 엘리먼트

목적

종속관계



15

Assurance Elements Structure

A set of assurance elements is provided for each assurance component.

An assurance element is a security requirement which, if further divided, would not yield a meaningful evaluation result.

Each assurance element is identified as one of the following three sets :

Developer action elements

Content and presentation of evidence elements

SAR Structure



16

Assurance Elements Structure

Evaluator action elements :

The activities that shall be performed by the evaluator. This set of actions explicitly includes confirmation that the requirements prescribed in the content and presentation of evidence elements have been met.

It also includes explicit actions and analysis that shall be performed in addition to that already performed by the developer.

The evaluator actions define the evaluator's responsibilities in the two aspects of evaluation.

First, ( ) of the PP/ST, in accordance with the classes APE and ASE

Second, ( ) of the TOE's conformance with its SFRs and SARs

SAR Structure



17

Summary The Evaluation Assurance Levels (EALs)

provide an increasing scale that balances the level of assurance obtained with the ( ) of acquiring that degree of assurance.

TOE's assurance Levels in CC. ( ) hierarchically ordered evaluation

assurance levels are defined.

Each EAL represents ( ) assurance than all lower EALs.

EAL



18

EAL

EAL1 : Functionally tested

EAL2 : Structurally tested

EAL3 : Methodically tested and checked

EAL4 : Methodically designed, tested, and reviewed

EAL5 : Semiformally designed and tested

EAL6 : Semiformally verified design and tested

EAL7 : Formally verified design and tested

EAL



19

The Composed Assurance Packages (CAPs) are to be applied to composed TOEs.

CAP - Introduction -



20

Composed TOE

Composed TOEs are comprised of components that have been (are going through) component TOE evaluation.

The individual components will have been certified to an EAL or another assurance package specified in the ST.

A basic level of assurance in a composed TOE will be gained through application of EAL1, which can be achieved with information about the components that is generally available in the public domain.

EAL1 can be applied to both component and composed TOEs.

CAPs provide an alternative approach to obtaining higher levels of assurance for a composed TOE than application of the ( ).




21

Necessity of Composed TOE Evaluation




22

CAP-A – Structurally composed

Objectives

CAP-A is applicable when a composed TOE is integrated and confidence in the correct security operation of the resulting composite is required.

CAP-A is applicable in those circumstances where developers or users require a low to moderate level of independently assured security ( ) ready availability of the complete development record.

CAP - Details -



23

CAP-B – Methodically composed

Objectives

CAP-B permits a conscientious developer to gain maximum assurance from understanding, ( ), the affects of interactions between component TOEs integrated in the composed TOE.

CAP-B is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the composed TOE and its development without substantial re-engineering.

CAP - Details -



24

CAP-C – Methodically composed, tested and reviewed

Objectives

CAP-C permits a developer to gain maximum assurance from positive analysis of the interactions between the ( ) of the composed TOE.

CAP-C is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity composed TOEs and are prepared to incur additional security-specific engineering costs.

CAP - Details -



25

Security Assurance Classes

SAR

Short Name Long Name Purpose

APEProtection profile

evaluationdemonstrate that the PP is complete, consistent, and technically sound

ASE Security Target evaluationdemonstrate that the ST is complete, consistent, technically sound, and suitable for use as the basis for a TOE evaluation

ADV Developmentensure that the development process is methodical by requiring various levels of specification and design and evaluating the consistency between them

AGD Guidance documentsensure that all relevant aspects of the secure operation and use of the TOE are documented in user and administrator guidance

ALC Lifecycle supportensure that methodical processes are followed during the operations and maintenance phase so that security integrity is not disrupted

ATE Testsensure adequate test coverage, test depth, and functional and independent testing

AVA Vulnerability assessmentanalyze 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

ACO Compositionensure that a composed TOE will operate securely when relying upon security functionality provided by previously evaluated software, firmware or hardware components.



26

보증요구사항의 구성

SAR

구분 클래스명 설명

APE 보호프로파일 평가위협을 정의하고 이러한 위협에 대응하는 보안대책을 설정하여이들이 위협을 충분하게 대응함을 입증. CC의 SFR을 이용하여 표준화된 언어로 보안대책을 표현.

ASE 보안목표명세서 평가보안목표명세서가 타당하고 내부적으로 일관성이 있으며, 하나이상의 다른 보호프로파일이나 패키지에 근거하고 있고 그것을정확하게 실체화 했음을 입증

ADV 개발TOE 요약명세 단계부터 실제 구현 단계까지 단계적으로 세분화하여 개발 프로세스가 조직적임을 보장

AGD 설명서안전한 운영과 TOE 사용에 관련된 모든 측면이 사용자 문서와 관리자 문서로 문서화되어 있음을 보장

ALC 생명주기지원 TOE 구현 및 유지보수 동안에 적용된 보안절차의 적절성 결정

ATE 시험TSF가 기능명세, TOE 설계, 구현표현에 서술된 대로 동작함을보증함

AVA 취약성 평가TOE의 개발이나 운영 중에 악용 가능한 취약성이 발생할 가능성확인

ACO 합성합성 TOE가 기존에 평가된 S/W, 펌웨어, 하드웨어 컴포넌트에 의해 제공되는 보안기능성에 의존하는 경우 안전하게 동작한다는신뢰 제공을 위한 보안요구사항 명세



27

PP Evaluation Class (APE)

SAR

Family Name Component(s)

APE_INT PP introduction APE_INT.1 PP introduction

APE_CCL Conformance claims APE_CCL.1 Conformance claims

APE_SPDSecurity problem

definitionAPE_SPD.1 Security problem definition

APE_OBJ Security objectivesAPE_OBJ.1 Security objectives for the operational environmentAPE_OBJ.2 Security objectives

APE_ECDExtended components

definitionAPE_ECD.1 Extended components definition

APE_REQ Security requirementsAPE_REQ.1 Stated security requirementsAPE_REQ.2 Derived security requirements



28

PP평가 클래스 (APE)

SAR

패밀리명 설명 컴포넌트

APE_INT 보호프로파일 소개 APE_INT.1 보호프로파일 소개

APE_CCL 준수 선언 APE_CCL.1 준수 선언

APE_SPDTOE 및 TOE 운영환경에서 다루

어야 하는 보안문제를 정의APE_SPD.1 보안문제정의

APE_OBJ 보안목적APE_OBJ.1 운영환경에 대한 보안목적APE_OBJ.2 보안목적

APE_ECD 확장 컴포넌트 정의 APE_ECD.1 확장 컴포넌트 정의

APE_REQ 보안요구사항APE_REQ.1 명시된 보안요구사항APE_REQ.2 도출된 보안요구사항



29

ST Evaluation Class (ASE)

SAR


ASE_INT ST introduction ASE_INT.1 ST introduction

ASE_CCLConformance

claimsASE_CCL.1 Conformance claims

ASE_SPDSecurity problem

definitionASE_SPD.1 Security problem definition

ASE_OBJ Security objectivesASE_OBJ.1 Security objectives for the operational environmentASE_OBJ.2 Security objectives

ASE_ECDExtended

components definition

ASE_ECD.1 Extended components definition

ASE_REQSecurity

requirementsASE_REQ.1 Stated security requirementsASE_REQ.2 Derived security requirements

ASE_TSSTOE summary specification

ASE_TSS.1 TOE summary specificationASE_TSS.2 TOE summary specification with architectural design summary



30

ST평가 클래스 (ASE)

SAR


ASE_INT 보안목표명세서 소개 ASE_INT.1 보안목표명세서 소개

ASE_CCL 준수 선언 ASE_CCL.1 준수 선언

ASE_SPD 보안문제정의 ASE_SPD.1 보안문제정의

ASE_OBJ 보안목적ASE_OBJ.1 운영환경에 대한 보안목적ASE_OBJ.2 보안목적

ASE_ECD 확장 컴포넌트 정의 ASE_ECD.1 확장 컴포넌트 정의

ASE_REQ 보안요구사항ASE_REQ.1 명시된 보안요구사항ASE_REQ.2 도출된 보안요구사항

ASE_TSS TOE 요약명세ASE_TSS.1 TOE 요약명세ASE_TSS.2 구조적 설계 정보가 제공되는 TOE 요약명세



31

기능 요구사항

보안 문제

보안목적

기능명세

설계 설명

구현 표현

구현

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을 정형화하여모델링하고, 이 정형화된 모델과기능명세간의 일치성 제공에 대한

요구사항 정의

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

SAR –개발 클래스 (ADV) Overview



32

Development Class (ADV)

SAR


ADV_ARC Security Architecture ADV_ARC.1 Security architecture description

ADV_FSP Functional specification

ADV_FSP.1 Basic functional specificationADV_FSP.2 Security-enforcing functional specificationADV_FSP.3 Functional specification with complete summaryADV_FSP.4 Complete functional specificationADV_FSP.5 Complete semi-formal functional specification

with additional error informationADV_FSP.6 Complete semi-formal functional specification

with additional formal specification

ADV_IMPImplementation representation

ADV_IMP.1 Implementation representation of the TSFADV_IMP.2 Complete mapping of the implementation

representation of the TSF

ADV_INT TSF internalsADV_INT.1 Well-structured subset of TSF internalsADV_INT.2 Well-structured internalsADV_INT.3 Minimally complex internals



33

개발 클래스 (ADV)

SAR


ADV_ARC 보안 구조 ADV_ARC.1 보안 구조 설명

ADV_FSP 기능명세

ADV_FSP.1 기본적인 기능명세ADV_FSP.2 보안-수행 기능명세ADV_FSP.3 완전한 요약정보가 제공되는 기능명세ADV_FSP.4 완전한 기능명세ADV_FSP.5 추가적인 오류 정보를 제공하는 준정형화된

완전한 기능명세ADV_FSP.6 추가적인 정형명세를 제공하는 준정형화된

완전한 기능명세

ADV_IMP 구현의 표현ADV_IMP.1 TSF에 대한 구현의 표현ADV_IMP.2 TSF의 구현

ADV_INT TSF 내부ADV_INT.1 잘 구조화된 TSF 내부의 일부ADV_INT.2 잘 구조화된 TSF 내부ADV_INT.3 최소화된 복잡도를 갖는 TSF 내부



34

Development Class (ADV)

SAR


ADV_SPMSecurity policy

modelingADV_SPM.1 Formal TOE security policy model

ADV_TDS TOE design

ADV_TDS.1 Basic designADV_TDS.2 Architectural designADV_TDS.3 Basic modular designADV_TDS.4 Semiformal modular designADV_TDS.5 Complete semiformal modular designADV_TDS.6 Complete semiformal modular design

with formal high-level design presentation



35

개발 클래스 (ADV)

SAR


ADV_SPM 보안정책모델 ADV_SPM.1 정형화된 TOE 보안정책모델

ADV_TDS TOE 설계

ADV_TDS.1 기본적인 설계ADV_TDS.2 구조적인 설계ADV_TDS.3 기본적인 모듈화 설계ADV_TDS.4 준정형화된 모듈화 설계ADV_TDS.5 완전한 준정형화된 모듈화 설계ADV_TDS.6 정형화된 상위수준 설계 표현이 제공되는

완전한 준정형화된 모듈화 설계



36

GuidanceDocumentsClass(AGD)

SAR


AGD_OPEOperational user

guidanceAGD_OPE.1 Operational user guidance

AGD_PREPreparative procedures

AGD_PRE.1 Preparative procedures



37

설명서 클래스 (AGD)

SAR


AGD_OPE 사용자 운영 설명서 AGD_OPE.1 사용자 운영 설명서

AGD_PRE 준비 절차 AGD_PRE.1 준비 절차



38

Life-Cycle Support Class (ALC)

SAR


ALC_CMC CM capabilities

ALC_CMC.1 Labelling of the TOEALC_CMC.2 Use of a CM systemALC_CMC.3 Authorisation controlsALC_CMC.4 Production support, acceptance procedures and automationALC_CMC.5 Advanced support

ALC_CMS CM scope

ALC_CMS.1 TOE CM coverageALC_CMS.2 Parts of the TOE CM coverageALC_CMS.3 Implementation representation CM coverageALC_CMS.4 Problem tracking CM coverageALC_CMS.5 Development tools CM coverage

ALC_DEL Delivery ALC_DEL.1 Delivery procedures

ALC_DVSDevelopment

securityALC_DVS.1 Identification of security measuresALC_DVS.2 Sufficiency of security measures



39

생명주기지원 클래스 (ALC)

SAR


ALC_CMC 형상관리 능력

ALC_CMC.1 TOE 레이블링ALC_CMC.2 형상관리 시스템의 사용ALC_CMC.3 인가통제ALC_CMC.4 생산지원, 수용절차 및 자동화ALC_CMC.5 고급지원

ALC_CMS 형상관리 범위

ALC_CMS.1 TOE 형상관리 범위ALC_CMS.2 TOE 부분에 대한 형상관리 범위ALC_CMS.3 구현 표현 형상관리 범위ALC_CMS.4 문제추적 형상관리 범위ALC_CMS.5 개발도구 형상관리 범위

ALC_DEL 배포 ALC_DEL.1 배포 절차

ALC_DVS 개발 보안ALC_DVS.1 보안대책의 식별ALC_DVS.2 보안대책의 충분함



40

Life-Cycle Support Class (ALC)

SAR


ALC_FLR Flaw remediationALC_FLR.1 Basic flaw remediationALC_FLR.2 Flaw reporting proceduresALC_FLR.3 Systematic flaw remediation

ALC_LCD Life-cycle definitionALC_LCD.1 Developer defined life-cycle modelALC_LCD.2 Measurable life-cycle model

ALC_TAT Tools and techniquesALC_TAT.1 Well-defined development toolsALC_TAT.2 Compliance with implementation standardsALC_TAT.3 Compliance with implementation standards - all parts



41

생명주기지원 클래스 (ALC)

SAR


ALC_FLR 결함 교정ALC_FLR.1 기본적인 결함교정ALC_FLR.2 결함교정 절차ALC_FLR.3 체계적인 결함교정

ALC_LCD 생명주기 정의ALC_LCD.1 개발자가 정의한 생명주기 모델ALC_LCD.2 측정가능한 생명주기 모델

ALC_TAT 도구와 기법ALC_TAT.1 잘 정의된 개발 도구ALC_TAT.2 적용된 구현표준ALC_TAT.3 모든 부분에서 적용된 구현표준



42

Tests Class (ATE)

SAR


ATE_COV CoverageATE_COV.1 Evidence of coverageATE_COV.2 Analysis of coverageATE_COV.3 Rigorous analysis of coverage

ATE_DPT Depth

ATE_DPT.1 Testing : basic designATE_DPT.2 Testing : security enforcing modulesATE_DPT.3 Testing : modular designATE_DPT.4 Testing : implementation representation

ATE_FUN Functional testsATE_FUN.1 Functional testingATE_FUN.2 Ordered functional testing

ATE_IND Independent testingATE_IND.1 Independent testing - conformanceATE_IND.2 Independent testing - sampleATE_IND.3 Independent testing - complete



43

시험 클래스 (ATE)

SAR


ATE_COV 시험범위ATE_COV.1 시험범위의 증거ATE_COV.2 시험범위의 분석ATE_COV.3 시험범위의 엄밀한 분석

ATE_DPT 상세수준

ATE_DPT.1 기본설계 시험ATE_DPT.2 보안-수행 모듈 시험ATE_DPT.3 모듈화 설계 시험ATE_DPT.4 구현 표현 시험

ATE_FUN 기능 시험ATE_FUN.1 기능 시험ATE_FUN.2 순서화된 기능 시험

ATE_IND 독립적인 시험ATE_IND.1 독립적인 시험 : 기능 확인ATE_IND.2 독립적인 시험 : 표본 확인ATE_IND.3 독립적인 시험 : 전체 시험



44

Vulnerability Assessment Class (AVA)

SAR


AVA_VAN Vulnerability analysis

AVA_VAN.1 Vulnerability surveyAVA_VAN.2 Vulnerability analysisAVA_VAN.3 Focused vulnerability analysisAVA_VAN.4 Methodical vulnerability analysisAVA_VAN.5 Advanced methodical vulnerability analysis



45

취약성평가 클래스 (AVA)

SAR


AVA_VAN 취약성 분석

AVA_VAN.1 취약성 조사AVA_VAN.2 취약성 분석AVA_VAN.3 강화된 취약성 분석AVA_VAN.4 체계적인 취약성 분석AVA_VAN.5 고도의 체계적인 취약성 분석



46

Composition Class (ACO)

SAR


ACO_COR Composition rationale ACO_COR.1 Composition rationale

ACO_DEV Development evidenceACO_DEV.1 Functional DescriptionACO_DEV.2 Basic evidence of designACO_DEV.3 Detailed evidence of design

ACO_RELReliance of dependent

componentACO_REL.1 Basic reliance informationACO_REL.2 Reliance information

ACO_CTT Composed TOE testingACO_CTT.1 Interface testingACO_CTT.2 Rigorous interface testing

ACO_VULComposition

vulnerability analysis

ACO_VUL.1 Composition vulnerability reviewACO_VUL.2 Composition vulnerability analysisACO_VUL.3 Enhanced-Basic Composition vulnerability analysis



47

합성 클래스 (ACO)

SAR


ACO_COR합성에 대한이론적 근거

ACO_COR.1 합성에 대한 이론적 근거

ACO_DEV 개발 증거ACO_DEV.1 기능 설명ACO_DEV.2 기본적인 설계 증거ACO_DEV.3 세부적인 설계 증거

ACO_REL종속 컴포넌트의

의존성ACO_REL.1 기본적인 의존 정보ACO_REL.2 의존 정보

ACO_CTT 합성 TOE 시험ACO_CTT.1 인터페이스 시험ACO_CTT.2 엄밀한 인터페이스 시험

ACO_VUL 합성 취약성 분석ACO_VUL.1 합성 취약성 검토ACO_VUL.2 합성 취약성 분석ACO_VUL.3 강화된-기본 합성 취약성 분석



48

SAR

TSF-a

TSF-b

비-TSF-a

비-TSF-b

TSFI-b

AA B

B

E E

E

1 2 3 4

CC

D

D



49

Evaluation Assurance Level



50

EALs

Evaluation Assurance Level

Provide an increasing scale that balances the level of assurance obtained with the ( ) of acquiring that degree of assurance.

The CC approach identifies the separate concepts of assurance in a TOE at the end of the evaluation, and of maintenance of that assurance during the operational use of the TOE.

It is important to note that not all families and components from CC Part 3 are included in the EALs.



51

EALs



52

EALs Level EAL1

The lowest level which should be considered for purposes of Evaluation.

Level EAL2 ( ), But best

that can be achieved without imposing some additional tasks on a developer.

Level EAL3 Allows a conscientious developer to benefit from

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



53

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.

EALs



54

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.

EALs



55

EAL1

보증 클래스 보증 컴포넌트

개발 ADV_FSP.1 기본적인 기능명세

설명서AGD_OPE.1 사용자 운영 설명서

AGD_PRE.1 준비 절차

생명주기지원ALC_CMC.1 TOE 레이블링

ALC_CMS.1 TOE 형상관리 범위

보안목표명세서 평가

ASE_CCL.1 준수 선언

ASE_ECD.1 확장 컴포넌트 정의

ASE_INT.1 보안목표명세서 소개

ASE_OBJ.1 운영환경에 대한 보안목적

ASE_REQ.1 명시된 보안요구사항

ASE_TSS.1 TOE 요약명세

시험 ATE_IND.1 독립적인 시험 : 기능확인

취약성 평가 AVA_VAN.1 취약성 조사



56

EAL1

Objectives

EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious.

It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information.



57

EAL1

Assurance Components

EAL1 provides a basic level of assurance by a limited ST and an analysis of the SFRs in that ST using a functional and interface specification and guidance documentation, to understand the security behaviour.

The analysis is supported by a search for potential vulnerabilities in the public domain and independent testing (functional and penetration) of the TSF.

EAL1 also provides assurance through unique identification of the TOE and of the relevant evaluation documents.

This EAL provides a meaningful increase in assurance over unevaluated IT.



58

EAL2보증 클래스 보증 컴포넌트

개발

ADV_ARC.1 보안 구조 설명

ADV_FSP.2 보안-수행 기능명세

ADV_TDS.1 기본적인 설계



생명주기지원

ALC_CMC.2 형상관리 시스템의 사용

ALC_CMS.2 TOE 부분에 대한 형상관리 범위

ALC_DEL.1 배포 절차

보안목표명세서 평가




ASE_OBJ.2 보안목적

ASE_REQ.2 도출된 보안요구사항

ASE_SPD.1 보안문제정의


시험

ATE_COV.1 시험범위의 증거

ATE_FUN.1 기능 시험

ATE_IND.2 독립적인 시험 : 표본 시험

취약성 평가 AVA_VAN.2 취약성 분석



59

EAL2

Objectives

EAL2 requires ( )in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practise.

As such it should not require a substantially increased investment of cost or time.

EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record.

Such a situation may arise when securing ( ), or where access to the developer may be limited.



60

EAL2


EAL2 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and interface specification, guidance documentation and a basic description of the architecture of the TOE, to understand the security behaviour.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, selective independent confirmation of the developer test results, and a vulnerability analysis (based upon the functional specification, TOE design, security architecture description and guidance evidence provided) demonstrating resistance to penetration attackers with a basic attack potential.



61

EAL2

EAL2 also provides assurance through use of a configuration management system and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a vulnerability analysis (in addition to the search of the public domain), and independent testing based upon more detailed TOE specifications.



62


개발


ADV_FSP.3 완전한 요약정보가 제공되는 기능명세

ADV_TDS.2 구조적인 설계



생명주기지원

ALC_CMC.3 인가 통제

ALC_CMS.3 구현 표현 형상관리범위


ALC_DVS.1 보안대책의 식별

ALC_LCD.1 개발자가 정의한 생명주기 모델

보안목표명세서평가









시험

ATE_COV.2 시험범위의 분석

ATE_DPT.1 기본설계 시험



취약성 평가 AVA_VAN.2 취약성 분석



63

EAL3

Objectives

EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage ( ) substantial alteration of existing sound development practises.

EAL3 is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re-engineering.



64

EAL3


EAL3 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and interface specification, guidance documentation, and an architectural description of the design of the TOE, to understand the security behaviour.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification and TOE design, selective independent confirmation of the developer test results, and a vulnerability analysis (based upon the functional specification, TOE design, security architecture description and guidance evidence provided) demonstrating resistance to penetration attackers with a basic attack potential.



65

EAL3

EAL3 also provides assurance through the use of development environment controls, TOE configuration management, and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL2 by requiring more complete testing coverage of the security functionality and mechanisms and/or procedures that provide some confidence that the TOE will not be tampered with during development.



66


개발


ADV_FSP.4 완전한 기능명세

ADV_IMP.1 TSF에 대한 구현의 표현

ADV_TDS.3 기본적인 모듈화 설계



생명주기지원

ALC_CMC.4 생산지원, 수용절차 및 자동화

ALC_CMS.4 문제추적 형상관리 범위



ALC_LCD.1 개발자가 정의한 생명주기 모델

ALC_TAT.1 잘 정의된 개발 도구










시험


ATE_DPT.2 보안-수행 모듈 시험



취약성 평가 AVA_VAN.3 강화된 취약성 분석



67

EAL4

Objectives EAL4 permits a developer to gain maximum

assurance from positive security engineering based on ( ) commercial development practises which, though rigorous, do not require substantial specialist knowledge, skills, and other resources.

EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line.

EAL4 is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security-specific engineering costs.



68

EAL4


EAL4 provides assurance by a ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, a description of the basic modular design of the TOE, and a subset of the implementation, to understand the security behaviour.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification and TOE design, selective independent confirmation of the developer test results, and a vulnerability analysis (based upon the functional specification, TOE design, implementation representation, security architecture description and guidance evidence provided) demonstrating resistance to penetration attackers with an Enhanced-Basic attack potential.



69

EAL4

EAL4 also provides assurance through the use of development environment controls and additional TOE configuration management including automation, and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL3 by requiring more design description, the implementation representation for the entire TSF, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.



70

EAL5


개발


ADV_FSP.5 추가적인 오류 정보를 제공하는준정형화된 완전한 기능명세

ADV_IMP.1 TSF에 대한 구현의 표현

ADV_INT.2 잘 구조화된 TSF 내부

ADV_TDS.4 준정형화된 모듈화 설계

설명서

AGD_OPE.1 사용자 운영 설명서


생명주기지원

ALC_CMC.4 생산지원, 수용절차 및 자동화

ALC_CMS.5 개발도구 형상관리 범위



ALC_LCD.1 개발자가 정의한 생명 주기 모델

ALC_TAT.2 적용된 구현표준










시험


ATE_DPT.3 모듈화 설계 시험



취약성 평가 AVA_VAN.4 체계적인 취약성 분석



71

EAL5

Objectives EAL5 permits a developer to gain maximum assurance

from security engineering based upon ( ) commercial development practises supported by moderate application of specialist security engineering techniques.

Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialised techniques, will not be large.

EAL5 is therefore applicable in those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques.



72

EAL5


EAL5 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, a description of the design of the TOE, and the implementation, to understand the security behaviour. A modular TSF design is also required.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design, selective independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential.



73

EAL5

EAL5 also provides assurance through the use of a development environment controls, and comprehensive TOE configuration management including automation, and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL4 by requiring semiformal design descriptions, a more structured ( ) architecture, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.



74

EAL6


개발


ADV_FSP.5 추가적인 오류 정보를 제공하는준정형화된 완전한 기능명세

ADV_IMP.2 TSF에 대한 구현

ADV_INT.3 최소화된 복잡도를 갖는 TSF 내부

ADV_SPM.1 정형화된 TOE 보안정책모델

ADV_TDS.5 완전한 준정형화된 모듈화 설계



생명주기지원

ALC_CMC.5 고급 지원



ALC_DVS.2 보안대책의 충분함

ALC_LCD.1 개발자가 정의한 생명 주기 모델

ALC_TAT.3 모든 부분에서 적용된 구현표준










시험

ATE_COV.3 시험범위의 엄밀한 분석

ATE_DPT.3 모듈화 설계 시험

ATE_FUN.2 순서화된 기능 시험


취약성 평가 AVA_VAN.5 고도의 체계적인 취약성 분석



75

EAL6

Objectives

EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting ( ) value assets against ( ) risks.

EAL6 is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs.



76

EAL6


EAL6 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, the design of the TOE, and the implementation to understand the security behaviour. Assurance is additionally gained through a formal model of select TOE security policies and a semiformal presentation of the functional specification and TOE design. A modular layered and simple TSF design is also required.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design, selective independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential.



77

EAL6

EAL6 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL5 by requiring more comprehensive analysis, a structured representation of the implementation, more architectural structure (e.g. layering), more comprehensive independent vulnerability analysis, and improved configuration management and development environment controls.



78


개발


ADV_FSP.6 추가적인 정형명세를 제공하는준정형화된 완전한 기능명세

ADV_IMP.2 TSF에 대한 구현

ADV_INT.3 최소화된 복잡도를 갖는 TSF 내부

ADV_SPM.1 정형화된 TOE 보안정책모델

ADV_TDS.6 정형화된 상위수준 설계 표현이제공되는 완전한 준정형화된 모듈화 설계



생명주기지원

ALC_CMC.5 고급 지원



ALC_DVS.2 보안대책의 충분함

ALC_LCD.2 측정가능한 생명 주기 모델

ALC_TAT.3 모든 부분에서 적용된 구현표준










시험

ATE_COV.3 시험범위의 엄밀한 분석

ATE_DPT.4 구현 표현 시험

ATE_FUN.2 순서화된 기능 시험

ATE_IND.3 독립적인 시험 : 전체 시험

취약성 평가 AVA_VAN.5 고도의 체계적인 취약성 분석



79

EAL7

Objectives

EAL7 is applicable to the development of security TOEs for application in ( ) risk situations and/or where the high value of the assets justifies the higher costs.

Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.



80

EAL7 Assurance Components

EAL7 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, the design of the TOE, and a structured presentation of the implementation to understand the security behaviour. Assurance is additionally gained through a formal model of select TOE security policies and a semiformal presentation of the functional specification and TOE design. A modular, layered and simple TSF design is also required.

The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design and implementation representation, complete independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential.



81

EAL7

EAL7 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures.

This EAL represents a meaningful increase in assurance from EAL6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing.



평가등급에 따른 보증 컴포넌트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

82

EALn+ EAL3+



83

Evaluation Task Order during an EAL3



84

PP & ST



85

PP & ST

Protection Profile & Security Target

Protection Profile (PP) Security Target (ST)

ProtectionProfile(PP)

SFR&

SAR

SecurityTarget(ST)



86

What is the PP?

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

Implementation-( )

A PP is typically used as :

part of a requirement specification for a specific consumer or group of consumers, who will only consider buying a specific type of IT if it meets the PP;

part of a regulation from a specific regulatory entity, who will only allow a specific type of IT to be used if it meets the PP;

a baseline defined by a group of IT developers, who then agree that all IT that they produce of this type will meet this baseline.



87

PP Contents

87

PP

PP introduction

Conformance claims

Security problem definition

Extended componentsdefinition

PP reference

TOE overview

Security objectives

Security requirements

CC conformance claim

PP claim, Package claim

Conformance rationale

Threats

Organisational security policies

Assumptions

Security objectives for the TOE

Security objectives for the operational environment

Security objectives rationale

Extended components definition

Security functional requirements

Security assurance requirements

Security requirements rationale

Conformance statement



88

PP Contents

88

보호프로파일

보호프로파일소개

준수선언

보안문제정의

확장컴포넌트정의

보호프로파일참조

TOE 개요

보안목적

보안요구사항

공통평가기준준수선언

보호프로파일, 패키지준수선언

준수선언의이론적근거

위협

조직의보안정책

가정사항

TOE에대한보안목적

운영환경에대한보안목적

보안목적의이론적근거


보안기능요구사항

보증요구사항

보안요구사항의이론적근거

보호프로파일준수방법



89

PP Contents

CCv2.3에서 v3.1로의 변경

v3.1


준수선언

보안문제정의


• 보호프로파일참조• TOE 개요

보안목적

보안요구사항

• 공통평가기준준수선언• 보호프로파일, 패키지준수선언• 준수선언의이론적근거• 보호프로파일준수방법

• 위협• 조직의보안정책• 가정사항

• TOE에대한보안목적• 운영환경에대한보안목적• 보안목적의이론적근거

• 확장컴포넌트정의

• 보안기능요구사항• 보증요구사항• 보안요구사항의이론적근거

v2.3


TOE 설명

TOE 보안환경

• 보호프로파일식별• 보호프로파일개요

보안목적

IT 보안요구사항

• 가정사항• 위협• 조직의보안정책

• TOE 보안목적• 환경에대한보안목적

보호프로파일응용시주의사항

• TOE 보안기능요구사항• TOE 보증요구사항• IT 환경에대한보안요구사항

이론적근거• 보안목적의이론적근거• 보안요구사항의이론적근거



90

TOE Overview Example

∗ The TOE overview is aimed at potential consumers of a TOE to find

TOEs that may meet their security needs, and are supported by

their hardware, software and firmware.

∗ The TOE overview briefly describes the usage of the TOE and

its major security features, identifies the TOE type and

identifies any major non-TOE hardware/software/firmware

available to the TOE.

Objectives



91


∗ TOE가 보안과 관련하여 어떤 기능을 하는지, 어떻게 사용될 수있는지에 대한 전반적인 지식 제공

∗ 실무 운영 측면에서 TOE 용도 및 주요 보안 특성을 소비자가이해할 수 있는 언어로 서술해야 함

예)

TOE의 용도 및 주요 보안 특성



92


∗ 침입차단시스템, 가상사설망-침입차단시스템, 스마트카드, 인트라넷, 웹 서버, 데이터베이스 등 일반적인 유형 식별

TOE 유형

∗ TOE가 의존하는 부가적인 하드웨어, 소프트웨어 및 펌웨어

∗ 일반적인 개념만 제공되는 경우가 많음

∗ 이미 알려진 요구사항 명세에서는 특정 소비자를 위한 특정 정보를더 많이 제공할 수 있음

예)

사용 가능한 비-TOE 하드웨어/소프트웨어/펌웨어 식별



93

Conformance Claims

∗ Describe CC version used

CC Conformance Claim

∗ Describe PP and Package used

PP Claim, Package Claim

∗ The conformance statement in the PP states how STs and/or other PPs must conform to that PP.

Conformance Statement



94


∗ The conformance statement in the PP states how STs and/or other PPs must conform to that PP.

Strict vs. Demonstrable

Cannot specify additional assumptions

Can specify additionalassumptions

Cannot specify additional security objectives for the operational environment

Can specify additionalsecurity objectives for the operational environment



95


∗ If an ST claims conformance to multiple PPs, it shall conform to

each PP in the manner ordained by that PP. This may mean that

the ST conforms strictly to some PPs and demonstrably to

other PPs.

∗ The CC does not recognise “partial" conformance.

예)

Notes



96

Security Problem Definition

○ Vulnerability Database

Threats



97


∗ Security rules, procedures, or guidelines imposed (or presumed to be imposed) now and/or in the future by an actual or hypothetical organisation in the operational environment.

∗ OSPs may be laid down by an organisation controlling the operational environment of the TOE, or they may be laid down by legislative or regulatory bodies.

예)

OSP



98


∗ Shows the assumptions that are made on the operational environment in order to be able to provide security functionality.

∗ Assumptions can be on physical, personnel and connectivity of the operational environment.

∗ Note that during the evaluation these assumptions are considered to be ( ): they are ( ) tested in any way.

예)

Assumptions



99

Security Objectives

∗ A concise and abstract statement of the intended solution to the problem defined by the security problem definition.

○

○

○

Security Objectives



100

Security Objectives

∗ A set of objectives that the TOE should achieve in order to solve its part of the problem

예)



101

Security Objectives

∗ Technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE).

예)



102

Security Objectives

∗ A tracing that shows which security objectives address which threats, OSPs and assumptions;

∗ A set of justifications that shows that all threats, OSPs, and assumptions are effectively addressed by the security objectives.

Threats OSP Assumptions

Security Objectivesfor the TOE

Security Objectivesfor the OE



103

Extended Components Definition

∗ In some cases, there may be requirements in an ST that are not based on components in CC Part 2 or CC Part 3, new components (extended components) must be defined.

○ Note that this section is intended to contain only the extended

components and not the extended requirements (requirements

based on extended components).

○ The extended requirements should be included in the security

requirements (see the next Section).

Extended Components Definition



104

Security Requirements

∗ The SFRs are a translation of the ( ) for the TOE in the CC language.

○ This language is defined as a set of components defined in CC

Part 2.

○ The CC has four operations : assignment, selection, iteration,

and refinement.

○ An SFR can have a dependency on other SFRs. This signifies

that if an ST uses that SFR, it generally needs to use those

other SFRs as well. This improves the completeness of STs.

∗ SARs are the ( ) that it really does.

SFR & SAR



105

Security Requirements

∗ A tracing that shows which SFRs address which security objectives for the TOE;

∗ A set of justifications that shows that all security objectives for the TOE are effectively addressed by the SFRs.

Security Requirements Rationale

Threats OSP Assumptions

Security Objectivesfor the TOE

Security Objectivesfor the OE

SFRs SARs



106

PP for Low AssurancePP

(for low assurance)

PP introduction

Conformance claims



PP reference

TOE overview

Security objectives





Threats


Assumptions


Security objectives for the operational environment






Conformance statement



107

PP for Low Assurance보호프로파일

(낮은보증수준)


준수선언

보안문제정의


보호프로파일참조

TOE 개요

보안목적

보안요구사항




위협


가정사항

TOE에대한보안목적





보증요구사항


보호프로파일준수방법



108

PP for Low Assurance

∗ A low-assurance PP may only claim conformance to a low-assurance PP.

∗ A non-low assurance PP may claim conformance with a low assurance PP

∗ A low-assurance PP consists of

○ a PP introduction

○ a conformance claim

○ security objectives for the operational environment

○ the SFRs and the SARs (including the extended components definition) and the security requirements rationale (only if the dependencies are not satisfied).

PP for Low Assurance



109

What is the ST?

Document that identifies what a product actually does

Specific to an implementation

STs may be based on ( ), ( ) or ( ) - however this is not mandatory, as STs do not have to be based on ( ).

A ST is typically used as :

Before and during the evaluation, the ST specifies “what is to be evaluated”.

After the evaluation, the ST specifies “what was evaluated”. Ease of use and understandability are major issues for this role.



110

ST Contents

ST

ST introduction

SP reference

Conformance claims



TOE reference

TOE overview

Security objectives


TOE summary specification

TOE description




Threats


Assumptions


Security objectives forthe operational environment









111

ST Contents

보안목표명세서

보안목표명세서소개

보안목표명세서참조

준수선언

보안문제정의


TOE 참조

TOE 개요

보안목적

보안요구사항

TOE 요약명세

TOE 설명




위협


가정사항

TOE 보안목적




TOE 요약명세


보증요구사항




112

ST Contents

CCv2.3에서 v3.1로의변경

v3.1

보안목표명세서 소개

준수 선언

보안문제정의

확장 컴포넌트 정의

• 보안목표명세서 참조• TOE 참조• TOE 개요• TOE 설명

보안목적

보안요구사항

• 공통평가기준 준수 선언• 보호프로파일, 패키지 준수 선언• 준수 선언의 이론적 근거

• 위협• 조직의 보안정책• 가정사항

• TOE 보안목적• 운영환경에 대한 보안목적• 보안목적의 이론적 근거

• 확장 컴포넌트 정의

• 보안기능요구사항• 보증요구사항• 보안요구사항의 이론적 근거

v2.3

보안목표명세서 소개

TOE 설명

TOE 보안환경

• 보안목표명세서 식별• 보안목표명세서 개요• 공통평가기준 적합성

보안목적

IT 보안요구사항

• 가정사항• 위협• 조직의 보안정책

• TOE 보안목적• 환경에 대한 보안목적

• TOE 보안기능요구사항• TOE 보증요구사항• IT 환경에 대한 보안요구사항

이론적 근거• 보안목적의 이론적 근거• 보안요구사항의 이론적 근거

보호프로파일 수용• 보호프로파일 참조• 보호프로파일 재정립• 보호프로파일 추가사항

TOE 요약명세• TOE 보안기능• 보증수단

TOE 요약명세 • TOE 요약명세



113

ST Reference Example

∗ 보안목표명세서를 식별하는 명확한 보안목표명세서 참조

○ 일반적으로 제목, 버전, 작성자, 발간일로 구성

예)

∗ 다른 보안목표명세서, 같은 보안목표명세서의 다른 버전과 구별할수 있도록 유일함

보안목표명세서 참조



114

TOE Reference Example

∗ 보안목표명세서를 준수하는 TOE 식별

○ 일반적으로 개발자명, TOE 이름, TOE 버전으로 구성

예)

○ 하나의 TOE가 다른 소비자들에 의해 여러 번 평가 받을 경우여러 개의 보안목표명세서를 가질 수 있음

○ TOE 참조는 반드시 유일해야 할 필요는 없음

∗ TOE가 하나 이상의 잘 알려진 제품들로 구성될 경우, 그 제품명을명시함으로써 TOE 참조에 반영할 수 있음

TOE 참조



115


∗ TOE가 보안과 관련하여 어떤 기능을 하는지, 어떻게 사용될 수있는지 전반적인 지식 제공

∗ 실무 운영 측면에서 TOE 용도 및 주요 보안 특성을 소비자가이해할 수 있는 언어로 서술해야 함

예)

TOE의 용도 및 주요 보안 특성



116


∗ 침입차단시스템, 가상사설망-침입차단시스템, 스마트카드, 인트라넷, 웹 서버, 데이터베이스 등 일반적인 유형 식별

TOE 유형

∗ TOE가 의존하는 부가적인 하드웨어, 소프트웨어 및 펌웨어

∗ 일반적인 개념만 제공되는 경우가 많음

∗ 특정 소비자를 위해 이미 알려진 요구사항 명세에서는 특정 정보를더 많이 제공 가능함

예)

사용 가능한 비-TOE 하드웨어/소프트웨어/펌웨어 식별



117

TOE Description

∗ A TOE description is a narrative description of the TOE, in more

detail than was provided in the TOE overview.

∗ The TOE description discusses the physical scope of the TOE: a

list of all hardware, firmware, software and guidance parts that

constitute the TOE.

∗ The TOE description should also discuss the logical scope of the

TOE: the logical security features offered by the TOE.

∗ An important property of the physical and logical scopes is that

they describe the TOE in such a way that there remains no doubt.

This is especially important when the TOE is intertwined with and

cannot be easily separated from non-TOE entities.

Objectives



118

ST for Low Assurance

ST(for low assurance)

ST introduction

SP reference

Conformance claims



TOE reference

TOE overview

Security objectives



TOE description




Threats


Assumptions


Security objectives forthe operational environment









119


보안목표명세서소개

보안목표명세서참조

준수선언

보안문제정의


TOE 참조

TOE 개요

보안목적

보안요구사항

TOE 요약명세

TOE 설명




위협

조직의 보안정책

가정사항

TOE 보안목적

운영환경에 대한 보안목적

보안목적의 이론적 근거


TOE 요약명세


보증요구사항


보안목표명세서(낮은보증수준)



120


∗ The CC allows the use of a low assurance ST for an ( )evaluation, but not for EAL 2 and up.

∗ A low-assurance ST may only claim conformance to a low-assurance PP. A non-low assurance ST may claim conformance with a low assurance PP.

∗ A low-assurance ST has a significantly reduced content compared to a non-low assurance ST :

○ there is no need to describe the security problem definition.

○ there is no need to describe the security objectives for the TOE. The security objectives for the operational environment shall still be described.

○ there is no need to describe the security objectives rationale as there is no security problem definition in the ST.

○ the security requirements rationale only needs to justify (any) dependencies not being satisfied as there are no security objectives for the TOE in the ST.





CC Part 3 : SARs

it security evaluation methods lecture notes (7/7)

Engineering