보호프로파일(PP, Protection Profile)은 ISO/IEC 15408(CC, Common Criteria) 평가에서 IT제품에 대한 특정 소비자의 보안요구사항을 담은 문서로서, 최근 들어 많은 국가기관 및 기업에 의해 개발되고 있다. 이러한 보호프로파일은 IT시스템 및 제품을 도입하는 과정에서 보안성 평가에 대한 기준이 되므로 정보보호의 중요성이 강조되는 시점에서 그 중요성이 날로 증대되고 있다. 하지만 구체적인 보호프로파일 개발 방법이나 보안환경 분석 및 보안요구사항 도출 방법에 대해서는 상세한 방법론이 존재하지 않아, 보호프로파일을 쉽게 개발하기는 어려운 실정이다. 이에 본 논문에서는 국외 보호프로파일 개발 방법론 및 사례를 분석하고, 보호프로파일의 보안환경 분석 및 보안요구사항 도출 방법론을 제안한다.
보호프로파일(PP, Protection Profile)은 ISO/IEC 15408(CC, Common Criteria) 평가에서 IT제품에 대한 특정 소비자의 보안요구사항을 담은 문서로서, 최근 들어 많은 국가기관 및 기업에 의해 개발되고 있다. 이러한 보호프로파일은 IT시스템 및 제품을 도입하는 과정에서 보안성 평가에 대한 기준이 되므로 정보보호의 중요성이 강조되는 시점에서 그 중요성이 날로 증대되고 있다. 하지만 구체적인 보호프로파일 개발 방법이나 보안환경 분석 및 보안요구사항 도출 방법에 대해서는 상세한 방법론이 존재하지 않아, 보호프로파일을 쉽게 개발하기는 어려운 실정이다. 이에 본 논문에서는 국외 보호프로파일 개발 방법론 및 사례를 분석하고, 보호프로파일의 보안환경 분석 및 보안요구사항 도출 방법론을 제안한다.
As a formal document that expresses a set of security requirements for IT products that meets specific consumer needs in the ISO/IEC 15408(CC, Common Criteria) evaluation, protection profiles are developing by many national agencies and companies recently. Since a protection profile is a criteria fo...
As a formal document that expresses a set of security requirements for IT products that meets specific consumer needs in the ISO/IEC 15408(CC, Common Criteria) evaluation, protection profiles are developing by many national agencies and companies recently. Since a protection profile is a criteria for security evaluation when the IT systems and products are introduced, the importance of the protection profile is increasing. However, developing protection profiles are still difficult due to lack of detailed methodology and guidance to analyze security environments or to derive security requirements. In this paper, we analyze foreign instances of developing protection profiles and propose a methodology for deriving security requirements through analyzing the TOE security environment.
As a formal document that expresses a set of security requirements for IT products that meets specific consumer needs in the ISO/IEC 15408(CC, Common Criteria) evaluation, protection profiles are developing by many national agencies and companies recently. Since a protection profile is a criteria for security evaluation when the IT systems and products are introduced, the importance of the protection profile is increasing. However, developing protection profiles are still difficult due to lack of detailed methodology and guidance to analyze security environments or to derive security requirements. In this paper, we analyze foreign instances of developing protection profiles and propose a methodology for deriving security requirements through analyzing the TOE security environment.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
본 논문에서는 PP 개발을 위한 보안요구사항 도출방법론을 제안하였다. 제안하는 방법론은 환경을 3가지 등급으로 나누고 각 환경에 대한 위험분석을 통하여 PP 작성 시 환경 에 포함되어야 하는 위협을 도출하는 방식이다.
다음은 환경별로 고려해야하는 위협 패키지를 도출하기 위한 절차를 보여준다. 본 논문에서는 위협 패키기 도출에 대한 이해를 돕기 위해 각 단계의 표에 예시를 명기하였다.
활용할 수 있는지를 기술하였다. 본 단계에서는 이렇게 도출된 보안환경을 보안목적 및 보안 기능요구사항과 대응시키기 위한 이론적 근거를 마련하기 위해, 보안 기능요구사항의 도출을 패키지화한다. 이를 위해 일본의 PP 작성 가이드를 참고하여 자산-위협-보안목적을 대응하는 〔표 6〕을 작성하고, 미국의 NIST SP 800- 53 을 참고하여 통제번호-통제이름-통제기준선을 대응하는 〔표 기을 작성해야 한다.
하지만 CC에서는 TOE 보안환경 분석 및 보안요구사항 도출에 대한 구체적인 방법을 서술하고 있지 않아, PP를 개발하는데 있어 많은 어려움이 따르고 있다. 이에 본 논문에서는 IT 시스템 및 제품 개발자 , 그리고 구매자가 PP 작성 시 고려해야 할 위험평가 방법과 위험분석을 적용한 PP 개발 사례를 분석하여, 환경 분석으로부터 보안요구사항 도출을 위한 프레임워크 및 개발 방법론을 제시하고자 한다. 본 논문의 2장에서는 PP 개발상의 문제점을 기술하고.
이전 단계까지는 보안요구사항을 도출하기 위해 가장 중요한 보안환경에서의 위협도출 및 위험분석을 어떻게 활용할 수 있는지를 기술하였다. 본 단계에서는 이렇게 도출된 보안환경을 보안목적 및 보안 기능요구사항과 대응시키기 위한 이론적 근거를 마련하기 위해, 보안 기능요구사항의 도출을 패키지화한다.
제안 방법
따라서 본 논문에서는 운영환경을 높음, 중간, 낮음으로 설정하고, 〔그림 1〕과 같은 절차에 따라서 운영환경에 따른 보안요구사항 도출 방법을 제안한다.
높아야 한다. 따라서 위험수준에 따른 보증패키지는 미국의 IATF 문서 ⑹를 참조하여 국내실정에 맞게 수정하였다. (〔표 8〕참조)
제안하는 방법론은 환경을 3가지 등급으로 나누고 각 환경에 대한 위험분석을 통하여 PP 작성 시 환경 에 포함되어야 하는 위협을 도출하는 방식이다. 또한 일본 및 미국에서 PP 개발을 위해 사용하는 문서를 참조하여 보안환경에 따른 보안목적 및 보안 기능요구사항을 패키지화하였다. 마지막으로 환경에 따른 보증 패키지를 제안함으로써 국내에서의 PP 개발을 위한 가이드라인을 제시하였다.
또한 일본 및 미국에서 PP 개발을 위해 사용하는 문서를 참조하여 보안환경에 따른 보안목적 및 보안 기능요구사항을 패키지화하였다. 마지막으로 환경에 따른 보증 패키지를 제안함으로써 국내에서의 PP 개발을 위한 가이드라인을 제시하였다. 제 안하는 방식을 PP 개발에 활용하면, 국내 실정 에 적합한 보호프로파일 보안 요구사항을 보다 효율적으로 작성할 수 있을 것이다.
위협 심각성 평가 종류는 “Threat Modeling”에서 사용한 DREAD 분류법을 일부 수정하였으며, 다음과 같이 위협에 대한 심각성 평가를 한다(〔표 4〕참조). 특정위협의 상대적인 심각성은 위협 결과 종류에 상관없이 특정 위협이 심각성 평가에서 받은 점수를 합산한 다음 평균을 구하여 결정한다.
제안하였다. 제안하는 방법론은 환경을 3가지 등급으로 나누고 각 환경에 대한 위험분석을 통하여 PP 작성 시 환경 에 포함되어야 하는 위협을 도출하는 방식이다. 또한 일본 및 미국에서 PP 개발을 위해 사용하는 문서를 참조하여 보안환경에 따른 보안목적 및 보안 기능요구사항을 패키지화하였다.
이론/모형
PP의 보안환경 도출에서 가장 중요한 요소인 위협을 도출하기 위해, 다양한 위협분류 방법 중 Swiderski와 Snyder가 "Threat Modeling"에서 제안한 STRIDE 분류 스킴에 기반하는데, 이 스킴에서는 위협을 신분위장, 데이터변조, 부인, 정보 유출, 서비스 거부, 권한 상승으로 분류하고 있다⑷. 다음은 환경별로 고려해야하는 위협 패키지를 도출하기 위한 절차를 보여준다.
성능/효과
SSE-CMM은 5개의 개발과정을 포함하며, 이러한 개발과정에는 11개의 보안 공학적 프로세스 영역이 존재한다. 5개의 개발과정은 PP 작성 프로세스(보안환경, 보안목적, 보안기능요구사항, 보증요구사항, 이론적 근거)와 매핑되어 PP 작성을 용이하게 하고 있다.
첫째, PKB에는 기존 PP의 환경 부분을 모두 포함하지 못하고 있다. 둘째, PKB내의 정의된 정책, 위협 및 가정을 선택하기 위해서는 TOE 및 관련된 사람의 추가적인 정보를 입수해야 한다. 셋째, PP 작성 시 TOE가 보호해야 할 자산을 파악하는 일은 매우 중요하나 TOE의 자산에 대한 평가 방법 및 분류체계에 대한 지침이 없다.
첫째, 보안환경 정의는 위협 분석을 통해 작성 가능하다. 둘째, 보안목적과 보안요구사항 및 대응을 분류 및 규정해 둠으로써, 보안목적 및 보안요구사항의 대응을 쉽게 하는 동시에 누락이 없도록 작성할 수 있다.
둘째, PKB내의 정의된 정책, 위협 및 가정을 선택하기 위해서는 TOE 및 관련된 사람의 추가적인 정보를 입수해야 한다. 셋째, PP 작성 시 TOE가 보호해야 할 자산을 파악하는 일은 매우 중요하나 TOE의 자산에 대한 평가 방법 및 분류체계에 대한 지침이 없다.
하지만 CC Toolbox와 PKB만으로는 제대로 된 PP를 만들 수 없는데, 그 이유는 다음과 같다. 첫째, PKB에는 기존 PP의 환경 부분을 모두 포함하지 못하고 있다. 둘째, PKB내의 정의된 정책, 위협 및 가정을 선택하기 위해서는 TOE 및 관련된 사람의 추가적인 정보를 입수해야 한다.
따라서 일본의 pp 작성 가이드는 다음과 같은 장점을 갖는다. 첫째, 보안환경 정의는 위협 분석을 통해 작성 가능하다. 둘째, 보안목적과 보안요구사항 및 대응을 분류 및 규정해 둠으로써, 보안목적 및 보안요구사항의 대응을 쉽게 하는 동시에 누락이 없도록 작성할 수 있다.
후속연구
마지막으로 환경에 따른 보증 패키지를 제안함으로써 국내에서의 PP 개발을 위한 가이드라인을 제시하였다. 제 안하는 방식을 PP 개발에 활용하면, 국내 실정 에 적합한 보호프로파일 보안 요구사항을 보다 효율적으로 작성할 수 있을 것이다.
참고문헌 (6)
CC: ISO/IEC 15408 Information technology-Security technology-Evaluation criteria for IT security V2.3, August 2005
Debra S. Herrmann, Using the Common Criteria for IT Security Evaluation, Auerbach Publications, 2003
'Consistency Instruction Manual For Development of US Government Protection Profiles For Use in Medium. Robustness Environments,' Release 3.0, National Security Agency, February 2005
Frank Swiderski, Window Snyder, Threat Modeling, Microsoft Press, 2004
Ron Ross, Stu Katzke, Arnold Johnson, Marianne Swanson, Gary Stoneburner, George Rogers, 'Recommended Security Controls for Federal Information Systems, NIST Special Publication 800-53,' National Institute of Standards and Technology, 2006
'Information Assurance Technical Framework Documents,' Release 3.1, National Security Agency, September 2002
※ AI-Helper는 부적절한 답변을 할 수 있습니다.