선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- CC V3.0 개정은 평가대상(TOE, Target of Evaluation)의 보안요구사항을 표현하는 보안기능/ 보증컴포넌트를 구성하는 클래스와 패밀리간의 중복성 제거 및 재구성을 통해 평가활동의 중복을 줄임으로써 효율적인 평가를 지원하는데 그 목적이 있다. 부가적으로 CC에 반영되지 않은 총 126 개의 해석 요구사항(RI : Request for Interpretation)을 평가자 활동의 작업단위 (Work Units) 에반영하여 CC V* 2.
제안 방법
- 의 ADV_HLD(기본설계)와 ADV(LLD)는 ADV_TDS에 통합되었다. EAL5 이상의 고등급평가/개발방법론을 구체적으로 제시하기 위해 ADV INTCTOE 내부)을 확장시켰다. 특히, AD-V_INT의.
- 0에서는 구조적 설겨〕, 응집도, 결합도의 다양한 소프트웨어 공학 기법을 도입하였다. 구조적 설계는 초기화(initialization), 자체보호(self-protection) 및 비우회성 (non-bypassability)을 분석하여 보안 기능이 안전하게 구현되었는지를 분석한다. 응집도 및 결합도는 모듈 설계 (modular design) 의 모듈분해(module decomposition) 과정에서 소프트웨어 또는 모듈간의 연결 및 의존도를 판단하는데 사용되며, TOE 보안기능의 복잡도를 줄이는데 도움을 제공한다.
- 첫째, CC에서 사용되는 개념과 용어, 내용을 구체화하고 명확하게 표현하였다. 둘째, 보안목적 수립 시 개발자 보안환경을 추가시켜, 이를 통해 보안 보증요구사항을 도출하도록 하였다. 셋째, CC V* 2.
- 의 보안 기능 컴포넌트에서 사용된 복수개의 모델을 '주체-연산-객체'의 보안행위 모델을 통합시켜 보안 기능 컴포넌트를 단순화하였다. 마지막으로, 다양한 소프트웨어 공학기법 적용을 통해 EAL5 이상의 고등급 평가/개발방법론 구현을 구체화시켰다.
- 첫째, 서로 다른 주체, 객체에 대한 구분 없이 TOE 전체에 대한 전역 속성을 설명하는 TSP(TOE 보안정책) 속성에 대한 모델로서 정보 흐름, 프라이버시 등을 다룬다, 둘째, 서로 다른 주체, 객체간의 책임을 구분하는 TOE 자체의 보호를 위한 모델로서 접근통제, 보안관리 등을 다룬다. 마지막으로, 특정 구현을 설명하는 TSP 구현에 대한 모델로서 암호, 메커니즘, 알고리즘 등을 다룬다. 이와 같이, CC V* 2.
- 특히, AD-V_INT의. 모듈설계에서는 높은 평가보증등급을 충족시키기 위해 TOE 기능의 복잡도를 줄이는 방안으로 소프트웨어 공학기법인 응집도, 결합도 개념을 도입하였다. ATE(시험)도 ADV가 내용이 변경됨에 따라 약간 변경되었다.
- 모호한 개념 및 용어를 명확하게 다시 정의하고, CC에서 추상적으로 표현된 내용들을 보다 구체적이고 현실적으로 기술하여 CC의 전반적인 내용에 대한 이해도를 높인다.
- 본 논문에서는 CC V3.0의 개정내용을 상세하게 분석하였다. 분석내용을 요약하면 다음과 같다.
- 0 개정은 평가대상(TOE, Target of Evaluation)의 보안요구사항을 표현하는 보안기능/ 보증컴포넌트를 구성하는 클래스와 패밀리간의 중복성 제거 및 재구성을 통해 평가활동의 중복을 줄임으로써 효율적인 평가를 지원하는데 그 목적이 있다. 부가적으로 CC에 반영되지 않은 총 126 개의 해석 요구사항(RI : Request for Interpretation)을 평가자 활동의 작업단위 (Work Units) 에반영하여 CC V* 2. 자체의 문제점을 보완하였다.
- 실세계와 부적합한 '폭포수 모델(Waterfall model)' 대신, 구조적 설계(architectural design), 응집도(cohesion), 결합도(coupling) 등의 다양한 소프트웨어 공학기법을 적용하여 TOE를 안전하게 구현하고, TOE 보안기능의 복잡도를 줄이는 등 EAL5이상의 고등급 평가/개발방법론을 구현하기 위한 구체적인 방법을 제시한다.
- 본 논문에서는 CC V* 2. 에서 V3.0으로 변경됨에 따라 CC V3.0의 변경사항에 대한 이해를 높이고 국가적인 차원에서 이에 적절히 대응하는데 도움을 제공하기 위해 CC V3.0의 개정내용을 상세하게 분석한다.
- CC V* 2. 의 ADV에서 적용하는 폭포수 모델은 실세 겨에 적합하지 않아 CC V3.0에서 ATV_ARC (보안 아키텍처), ADV_TDS(TOE 설계), 등의 새로운 구조(architectural structure)를 채택하였다. CC V* 2.
- 셋째, CC V* 2. 의 보안 기능 컴포넌트에서 사용된 복수개의 모델을 '주체-연산-객체'의 보안행위 모델을 통합시켜 보안 기능 컴포넌트를 단순화하였다. 마지막으로, 다양한 소프트웨어 공학기법 적용을 통해 EAL5 이상의 고등급 평가/개발방법론 구현을 구체화시켰다.
- 부가적으로 CC에 반영되지 않은 총 126 개의 해석 요구사항(RI : Request for Interpretation)을 평가자 활동의 작업단위 (Work Units) 에반영하여 CC V* 2. 자체의 문제점을 보완하였다. CC V3.
- 에서는 세 개의 추상화된 모델을 사용한다. 첫째, 서로 다른 주체, 객체에 대한 구분 없이 TOE 전체에 대한 전역 속성을 설명하는 TSP(TOE 보안정책) 속성에 대한 모델로서 정보 흐름, 프라이버시 등을 다룬다, 둘째, 서로 다른 주체, 객체간의 책임을 구분하는 TOE 자체의 보호를 위한 모델로서 접근통제, 보안관리 등을 다룬다. 마지막으로, 특정 구현을 설명하는 TSP 구현에 대한 모델로서 암호, 메커니즘, 알고리즘 등을 다룬다.
성능/효과
- 첫째, TOE 설명로 통합되었다. 둘째, 이론적 근거 (Rational)가 보안목적 (Security objectives)과 보안요구사항(Security requiremene으로 통합되었다. 셋째, 적합성 수용 (Conformance claims)이 추가되었다.
- 넷째, 보안목적 (Security objectives)0!] 개발환경에 대한 보안목적 (Security objectives for the development environmer此)이 추가되었다. 마지막으로, TOE 보안환경 (TOE Security environment)이 보안문제 정의 (Security problem definition)로 명칭이 변경되었다.
- 보안목적 수립시 TOE 개발환경의 반영 및 중복되거나 유사한 보안기능 및 보안보증 클래스/패밀리의 통합으로 인해 FDP(데이터 보호 및 프라이버시), FIA(식별, 인증 및 연결), FCO(통신), FAU(보안 감사), FPT(TSF 보호) 등 보안기능컴포넌트와 APE/ASE(PP 평가/ST 평가), ADV(개발), ATE (시험), ALC(생명주기 지원), AGD(설명서), AVA (취약성 평가) 등 보안보증컴포넌트가 많이 변경되었다. CC V3.
- 보안목적을 수립시, TOE 개발환경을 추가적으로 고려함으로써 개발환경으로부터 발생 가능한 위협을 사전에 분석하여 개발자 측면에서 TOE 구현의 정확성 (Correctness) 을 높이고, TOE 자체의 취약성을 줄인다.
- 분석내용을 요약하면 다음과 같다. 첫째, CC에서 사용되는 개념과 용어, 내용을 구체화하고 명확하게 표현하였다. 둘째, 보안목적 수립 시 개발자 보안환경을 추가시켜, 이를 통해 보안 보증요구사항을 도출하도록 하였다.
- 변경사항은 다음과 같다. 첫째, TOE 설명로 통합되었다. 둘째, 이론적 근거 (Rational)가 보안목적 (Security objectives)과 보안요구사항(Security requiremene으로 통합되었다.
- 0에서는 CC V* 2에서 사용되는 세 개의 모델을 두 번째 모델('주체-연산-객처)' 모델)로 통합하여 재구성하였다. 통합 및 재구성의 결과로써 보안 기능 컴포넌트의 클래스 및 패밀리 수가 각각 6 개, 45개로 대폭 축소되었다.
후속연구
- 향후, CC V3.0은 1999년 8월에 개정된 CC 2.1 이후로 가장 많은 내용이 변경될 전망이다. 2005년 4월 공개된 CC V3.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.