맨위로가기

공통평가기준

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

공통평가기준(CC)은 IT 제품 및 시스템의 보안성을 평가하기 위한 국제 표준이다. 1990년대 초 ITSEC, CTCPEC, TCSEC 등 기존의 여러 정보보안 평가 기준을 통합하여 개발되었으며, 캐나다, 프랑스, 독일, 네덜란드, 영국, 미국 정부가 공동으로 개발했다. CC는 제품의 보안 기능과 보증 수준을 평가하며, 보호 프로파일, 보안 목표, 평가 대상, 보안 기능 요구 사항, 보안 보증 요구 사항, 평가 보증 레벨 등의 주요 개념을 사용한다. CCRA(공통평가기준 상호인정협정)를 통해 회원국 간 평가 결과를 상호 인정하며, 2014년에는 협업 보호 프로파일(cPP) 및 EAL 1~2 평가만 인정하는 새로운 협정이 비준되었다. CC는 비용, 평가의 초점, FOSS 차별, 인증의 가치 등에 대한 비판과 논란이 있으며, FIPS-140, CESG 등의 대안이 존재한다.

더 읽어볼만한 페이지

  • 컴퓨터 보안 표준 - ISO/IEC 27002
    ISO/IEC 27002는 조직이 정보 보안을 효과적으로 관리하도록 지침을 제공하는 정보 보안 표준으로, 정보 보안 정책, 조직 구조, 물리적 보안 등 다양한 영역을 다룬다.
  • 컴퓨터 보안 표준 - 콘텐츠 보안 정책
    콘텐츠 보안 정책(CSP)은 웹 사이트의 XSS 공격과 데이터 주입 공격을 완화하기 위해 웹 서버 응답 헤더에 선언적 허용 목록 정책을 적용하여 인라인 JavaScript, CSS, 동적 코드 평가 등을 비활성화하는 웹 브라우저 보안 기능이다.
  • 평가 - 설명책임
    설명책임은 개인이나 조직이 자신의 행동과 결정에 대한 책임을 지고 그 결과를 설명해야 하는 의무를 뜻하며, 정치, 경제, 사회 전반에서 다양한 방식으로 나타나고, 선거 외에도 시민 사회 활동이나 여론 조사 등으로 추궁될 수 있으며, 조직 내부 윤리, 보안, 개인의 책임과 공공-민간 영역의 책임 공백 문제도 포함하여, 다양한 분야에서 확보 및 강화 노력이 이루어지고 있다.
  • 평가 - REACH
    REACH는 유럽 연합의 화학 물질 등록, 평가, 허가 및 제한에 관한 규정으로, 사람의 건강과 환경 보호, EU 화학 산업 경쟁력 강화, 그리고 고위험성 물질의 대체을 장려하는 것을 목표로 한다.
  • 컴퓨터 보안 - 얼굴 인식 시스템
    얼굴 인식 시스템은 디지털 이미지나 비디오에서 사람 얼굴을 감지하고 식별하는 기술로, 다양한 알고리즘 발전을 거쳐 보안, 신원 확인 등에 활용되지만, 편향성, 개인 정보 침해, 기술적 한계와 같은 윤리적 문제도 야기한다.
  • 컴퓨터 보안 - 워터마크
    워터마크는 종이 제조 시 두께 차이를 이용해 만들어지는 표식으로, 위조 방지를 위해 지폐나 여권 등에 사용되며 댄디 롤 등의 제작 기법을 통해 만들어지고 컴퓨터 프린터 인쇄 기술로도 활용된다.
공통평가기준
개요
이름공통 평가 기준
로마자 표기Gongtong Pyeongga Gijun
영어Common Criteria
일본어共通評価基準 (Kyōtsū Hyōka Kijun)
약칭CC
상세 정보
유형정보 기술 보안 평가 기준
제정 기관국제 표준화 기구 (ISO)
표준 번호ISO/IEC 15408
최초 발행1999년
최신 버전2022년 (ISO/IEC 15408:2022)
관련 표준ISO/IEC 27001
FIPS 140-2
평가 보증 등급 (EAL)
EAL1기능적으로 테스트됨 (Functionally Tested)
EAL2구조적으로 테스트됨 (Structurally Tested)
EAL3체계적으로 테스트되고 검증됨 (Methodically Tested and Checked)
EAL4체계적으로 설계, 테스트 및 검토됨 (Methodically Designed, Tested, and Reviewed)
EAL5준형식적으로 설계되고 테스트됨 (Semi-formally Designed and Tested)
EAL6준형식적으로 검증된 설계 및 테스트됨 (Semi-formally Verified Design and Tested)
EAL7형식적으로 검증된 설계 및 테스트됨 (Formally Verified Design and Tested)
특징
목표정보 기술 제품 및 시스템의 보안 기능을 평가하기 위한 국제 표준
내용보안 목표, 보안 요구 사항, 평가 보증 등급 등을 정의
활용정부, 기업 등에서 정보 보호 제품 도입 시 평가 기준으로 활용

2. 역사

공통평가기준(CC)은 다음 세 가지 표준에서 시작되었다.


  • ITSEC - 1990년대 초 프랑스, 독일, 네덜란드, 영국에서 개발된 유럽 표준이다. 이는 두 가지 영국식 접근 방식(방위/정보 시장을 목표로 하는 CESG 영국 평가 제도와 상업적 사용을 목표로 하는 DTI 그린 북)과 같은 이전 작업의 통합이었으며, 호주 등 다른 일부 국가에서도 채택되었다. 1991년 유럽 위원회에서 발행되었고, TCSEC의 개념을 기반으로 하면서, 보다 유연한 틀을 가지고, 민생품에서 정부 전용 제품까지 폭넓게 평가·인증이 이루어졌다. 국가 간의 상호 승인, 기능 주장과 보증 요건의 분리, 그리고 평가 기준 ITSEC에 더해 평가 방법 매뉴얼 ITSEM의 표준화 등, 몇 가지 점에서 CC의 틀의 기초가 되었다.
  • CTCPEC - 캐나다 표준은 미국 국방부 표준을 따랐지만 몇 가지 문제를 피했고, 미국과 캐나다의 평가자 모두가 공동으로 사용했다. 1993년에 공표되었으며, 오렌지 북과 ITSEC의 접근 방식을 조합하였다.
  • TCSEC - 미국 국방부 DoD 5200.28 Std, 오렌지 북 및 레인보우 시리즈의 일부이다. 1983년에 제정되었고, 1986년부터 NSA가 국방 관련 시스템을 중심으로 평가·인증을 실시하고 있다. 오렌지 북은 1970년대 후반과 1980년대 초 국가안보국과 국립 표준국(NBS는 결국 NIST가 됨)에서 수행한 앤더슨 보고서를 포함한 컴퓨터 보안 작업에서 시작되었다.


CC는 정부 시장(주로 국방 또는 정보 사용)을 위해 컴퓨터 제품을 판매하는 회사에서 하나의 표준 세트에 대해서만 평가를 받도록 하기 위해, 이러한 기존 표준을 통합하여 제작되었다. CC는 캐나다, 프랑스, 독일, 네덜란드, 영국 및 미국 정부에서 개발했다. 1993년에 미국에서 초안된 FC (Federal Criteria for Information Technology Security)도 CC 개발에 영향을 주었다. FC는 원래 군수용 TCSEC를, 민간용으로도 사용하기 쉽도록 ITSEC의 내용도 도입한 개정판으로 구상되었다.

1990년, ISO는 국제적으로 통용될 수 있는 보안 평가 기준 개발을 결정했다. 이 작업은 같은 해 ISO/IEC JTC 1/SC 27/WG 3에서 시작했지만, 작업량과 국제 간 조정의 어려움으로 지지부진했다.

1993년 6월, TCSEC, ITSEC, CTCPEC 및 FC 개발에 참여했던 6개국 7개 조직은 공통 평가 기준(CC)을 공동 개발하고 ISO 규격화하는 데 합의했다. 이들은 CC 프로젝트를 통해 각자의 평가 기준을 통일하고 그 성과를 ISO에 제공하는 것을 목표로 했다. CC 프로젝트는 각 조직의 대표자로 구성된 편집 위원회(CCEB)를 결성하여 ISO/IEC JTC 1/SC 27/WG 3에 규격안을 제안했다.

1996년 1월, CC 1.0 버전이 완성되었고, 4월에는 ISO 위원회 원안(CD)으로 채택되어 배포가 승인되었다. 이후 1998년에 CC 2.0 버전이 ISO 최종 초안(FCD)으로 승인되었고, 1999년에 CC 2.1 버전이 국제 표준(IS)으로 승인되어 ISO/IEC 15408:1999가 되었다. 이러한 통합 과정은 무려 9년이 소요되었다.

공통평가기준(CC)은 ITSEC, CTCPEC, 오렌지 북 등 기존의 여러 정보보안 평가 기준을 통합하여 만들어졌다. 이는 각기 다른 평가 기준으로 인해 발생하는 중복 평가 문제를 해결하고, 하나의 표준화된 평가 기준을 제공하기 위함이었다.

CC는 캐나다, 프랑스, 독일, 네덜란드, 영국, 미국 정부가 공동으로 개발하였으며, 여러 차례의 시행 평가와 공개 심사, 그리고 ISO의 피드백을 거쳐 개선되었다.

1998년에는 캐나다, 프랑스, 독일, 영국, 미국이 상호 인정 협정(MRA)을 체결하여 평가 인증 결과를 상호 승인하는 기반을 마련하였다. 1999년에는 CC 2.1 버전이 국제 표준(IS, ISO/IEC 15408:1999)으로 승인되었다.

이후 지속적인 개선 작업을 통해 2005년에는 CC 2.3 버전(ISO/IEC 15408:2005) 및 CEM 2.3 버전(ISO/IEC 18045:2005)이 발행되었고, 2006년에는 CC 3.1 버전이 발행되었다.

2. 1. 기원

공통평가기준(CC)은 다음 세 가지 표준에서 시작되었다.

  • ITSEC - 1990년대 초 프랑스, 독일, 네덜란드, 영국에서 개발된 유럽 표준이다. 이는 두 가지 영국식 접근 방식(방위/정보 시장을 목표로 하는 CESG 영국 평가 제도와 상업적 사용을 목표로 하는 DTI 그린 북)과 같은 이전 작업의 통합이었으며, 호주 등 다른 일부 국가에서도 채택되었다. 1991년 유럽 위원회에서 발행되었고, TCSEC의 개념을 기반으로 하면서, 보다 유연한 틀을 가지고, 민생품에서 정부 전용 제품까지 폭넓게 평가·인증이 이루어졌다. 국가 간의 상호 승인, 기능 주장과 보증 요건의 분리, 그리고 평가 기준 ITSEC에 더해 평가 방법 매뉴얼 ITSEM의 표준화 등, 몇 가지 점에서 CC의 틀의 기초가 되었다.
  • CTCPEC - 캐나다 표준은 미국 국방부 표준을 따랐지만 몇 가지 문제를 피했고, 미국과 캐나다의 평가자 모두가 공동으로 사용했다. 1993년에 공표되었으며, 오렌지 북과 ITSEC의 접근 방식을 조합하였다.
  • TCSEC - 미국 국방부 DoD 5200.28 Std, 오렌지 북 및 레인보우 시리즈의 일부이다. 1983년에 제정되었고, 1986년부터 NSA가 국방 관련 시스템을 중심으로 평가·인증을 실시하고 있다. 오렌지 북은 1970년대 후반과 1980년대 초 국가안보국과 국립 표준국(NBS는 결국 NIST가 됨)에서 수행한 앤더슨 보고서를 포함한 컴퓨터 보안 작업에서 시작되었다.


CC는 정부 시장(주로 국방 또는 정보 사용)을 위해 컴퓨터 제품을 판매하는 회사에서 하나의 표준 세트에 대해서만 평가를 받도록 하기 위해, 이러한 기존 표준을 통합하여 제작되었다. CC는 캐나다, 프랑스, 독일, 네덜란드, 영국 및 미국 정부에서 개발했다. 1993년에 미국에서 초안된 FC (Federal Criteria for Information Technology Security)도 CC 개발에 영향을 주었다. FC는 원래 군수용 TCSEC를, 민간용으로도 사용하기 쉽도록 ITSEC의 내용도 도입한 개정판으로 구상되었다.

2. 2. 통합 과정

1990년, ISO는 국제적으로 통용될 수 있는 보안 평가 기준 개발을 결정했다. 이 작업은 같은 해 ISO/IEC JTC 1/SC 27/WG 3에서 시작했지만, 작업량과 국제 간 조정의 어려움으로 지지부진했다.

1993년 6월, TCSEC, ITSEC, CTCPEC 및 FC 개발에 참여했던 6개국 7개 조직은 공통 평가 기준(CC)을 공동 개발하고 ISO 규격화하는 데 합의했다. 이들은 CC 프로젝트를 통해 각자의 평가 기준을 통일하고 그 성과를 ISO에 제공하는 것을 목표로 했다. CC 프로젝트는 각 조직의 대표자로 구성된 편집 위원회(CCEB)를 결성하여 ISO/IEC JTC 1/SC 27/WG 3에 규격안을 제안했다.

1996년 1월, CC 1.0 버전이 완성되었고, 4월에는 ISO 위원회 원안(CD)으로 채택되어 배포가 승인되었다. 이후 1998년에 CC 2.0 버전이 ISO 최종 초안(FCD)으로 승인되었고, 1999년에 CC 2.1 버전이 국제 표준(IS)으로 승인되어 ISO/IEC 15408:1999가 되었다. 이러한 통합 과정은 무려 9년이 소요되었다.

2. 3. 국제 표준화

공통평가기준(CC)은 ITSEC, CTCPEC, 오렌지 북 등 기존의 여러 정보보안 평가 기준을 통합하여 만들어졌다. 이는 각기 다른 평가 기준으로 인해 발생하는 중복 평가 문제를 해결하고, 하나의 표준화된 평가 기준을 제공하기 위함이었다.

CC는 캐나다, 프랑스, 독일, 네덜란드, 영국, 미국 정부가 공동으로 개발하였으며, 여러 차례의 시행 평가와 공개 심사, 그리고 ISO의 피드백을 거쳐 개선되었다.

1998년에는 캐나다, 프랑스, 독일, 영국, 미국이 상호 인정 협정(MRA)을 체결하여 평가 인증 결과를 상호 승인하는 기반을 마련하였다. 1999년에는 CC 2.1 버전이 국제 표준(IS, ISO/IEC 15408:1999)으로 승인되었다.

이후 지속적인 개선 작업을 통해 2005년에는 CC 2.3 버전(ISO/IEC 15408:2005) 및 CEM 2.3 버전(ISO/IEC 18045:2005)이 발행되었고, 2006년에는 CC 3.1 버전이 발행되었다.

3. 주요 개념

wikitext

공통평가기준(Common Criteria, CC)은 IT 제품 및 시스템의 보안성을 평가하기 위한 프레임워크를 제공한다.


  • '''보호 프로파일 (PP)''' – 일반적으로 사용자 또는 사용자 커뮤니티에서 생성하는 문서로, 디지털 서명을 제공하는 데 사용되는 스마트 카드 또는 네트워크 방화벽과 같이 특정 목적을 위해 해당 사용자와 관련된 보안 장치 클래스에 대한 보안 요구 사항을 식별한다. 제품 공급업체는 하나 이상의 PP를 준수하는 제품을 구현하고 해당 PP에 대해 제품을 평가받을 수 있다. 특정 유형의 제품을 찾는 고객은 요구 사항을 충족하는 PP에 대해 인증된 제품에 집중할 수 있다.
  • '''보안 목표 (ST)''' – 평가 대상의 보안 ''속성''을 식별하는 문서이다. ST는 하나 이상의 PP와의 준수를 주장할 수 있다. 평가 대상(TOE)는 ST에 설정된 보안 기능 요구 사항(SFR)에 따라 평가되며, 그 이상도 그 이하도 아니다. ST는 일반적으로 잠재 고객이 평가를 통해 인증된 특정 보안 기능을 결정할 수 있도록 게시된다.
  • '''평가 대상(TOE)''' – 평가의 대상이 되는 제품 또는 시스템이다. 평가는 대상에 대해 제기된 주장을 검증하는 역할을 한다.
  • '''보안 기능 요구 사항(SFR)''' – 제품에서 제공될 수 있는 개별 보안 '''기능'''을 지정한다. 공통평가기준은 이러한 기능에 대한 표준 카탈로그를 제시한다. 예를 들어, SFR은 특정 역할을 수행하는 사용자가 '''어떻게''' 인증될 수 있는지를 명시할 수 있다. 공통평가기준은 ST에 포함될 SFR을 규정하지 않지만, 하나의 기능의 올바른 작동이 다른 기능에 종속되는 종속성을 식별한다.
  • '''보안 보증 요구 사항(SAR)''' – 주장된 보안 기능과의 준수를 보장하기 위해 제품 개발 및 평가 중에 수행된 조치에 대한 설명이다. 예를 들어, 평가는 모든 소스 코드를 변경 관리 시스템에 보관하거나 전체 기능 테스트를 수행해야 할 수 있다. 공통평가기준은 이러한 요구 사항에 대한 카탈로그를 제공하며, 요구 사항은 평가에 따라 다를 수 있다.
  • '''평가 보증 레벨 (EAL)''' – 평가의 깊이와 엄격성을 설명하는 숫자 등급이다. 각 EAL은 주어진 엄격성 수준으로 제품의 전체 개발을 포괄하는 보안 보증 요구 사항(SAR) 패키지에 해당한다. 공통평가기준은 7단계로 나열하며, EAL1은 가장 기본적인 단계이고 EAL7은 가장 엄격한 단계이다. 더 높은 EAL이 ''반드시'' "더 나은 보안"을 의미하지는 않으며, TOE의 주장된 보안 보증이 더 광범위하게 검증되었음을 의미한다.


TOE 내의 암호화 구현 세부 사항은 CC의 범위를 벗어난다. 대신, FIPS 140-2와 같은 국가 표준은 암호화 모듈에 대한 사양을 제공하고, 다양한 표준은 사용 중인 암호화 알고리즘을 지정한다.

3. 1. 핵심 용어

공통평가기준(Common Criteria, CC) 평가는 컴퓨터 보안 제품 및 시스템에 대해 수행된다.

  • '''보호 프로파일 (PP)''' – 일반적으로 사용자 또는 사용자 커뮤니티에서 생성하는 문서로, 특정 목적을 위해 해당 사용자와 관련된 보안 장치 클래스(예: 디지털 서명을 제공하는 데 사용되는 스마트 카드 또는 네트워크 방화벽)에 대한 보안 요구 사항을 식별한다. 제품 공급업체는 하나 이상의 PP를 준수하는 제품을 구현하도록 선택하고 해당 PP에 대해 제품을 평가받을 수 있다. 특정 유형의 제품을 찾는 고객은 요구 사항을 충족하는 PP에 대해 인증된 제품에 집중할 수 있다.
  • '''보안 목표 (ST)''' – 평가 대상의 보안 ''속성''을 식별하는 문서이다. ST는 하나 이상의 PP와의 준수를 주장할 수 있다. TOE는 ST에 설정된 SFR(보안 기능 요구 사항, 아래 참조)에 따라 평가되며, 그 이상도 그 이하도 아니다. ST는 일반적으로 잠재 고객이 평가를 통해 인증된 특정 보안 기능을 결정할 수 있도록 게시된다.
  • '''평가 대상(TOE)''' – 평가의 대상이 되는 제품 또는 시스템이다. 평가는 대상에 대해 제기된 주장을 검증하는 역할을 한다.
  • '''보안 기능 요구 사항(SFR)''' – 제품에서 제공될 수 있는 개별 보안 '''기능'''을 지정한다. 공통평가기준은 이러한 기능에 대한 표준 카탈로그를 제시한다. 예를 들어, SFR은 특정 역할을 수행하는 사용자가 '''어떻게''' 인증될 수 있는지를 명시할 수 있다. 공통평가기준은 ST에 포함될 SFR을 규정하지 않지만, 하나의 기능의 올바른 작동이 다른 기능에 종속되는 종속성을 식별한다.
  • '''보안 보증 요구 사항(SAR)''' – 주장된 보안 기능과의 준수를 보장하기 위해 제품 개발 및 평가 중에 수행된 조치에 대한 설명이다. 예를 들어, 평가는 모든 소스 코드를 변경 관리 시스템에 보관하거나 전체 기능 테스트를 수행해야 할 수 있다. 공통평가기준은 이러한 요구 사항에 대한 카탈로그를 제공하며, 요구 사항은 평가에 따라 다를 수 있다.
  • '''평가 보증 레벨 (EAL)''' – 평가의 깊이와 엄격성을 설명하는 숫자 등급이다. 각 EAL은 주어진 엄격성 수준으로 제품의 전체 개발을 포괄하는 보안 보증 요구 사항(SAR, 위 참조) 패키지에 해당한다. 공통평가기준은 7단계로 나열하며, EAL 1은 가장 기본적인 단계이고 EAL 7은 가장 엄격한 단계이다. 더 높은 EAL은 ''반드시'' "더 나은 보안"을 의미하지 않으며, TOE의 주장된 보안 보증이 더 광범위하게 검증되었음을 의미한다.


TOE 내의 암호화 구현 세부 사항은 CC의 범위를 벗어난다. 대신, FIPS 140-2와 같은 국가 표준은 암호화 모듈에 대한 사양을 제공하고, 다양한 표준은 사용 중인 암호화 알고리즘을 지정한다.

3. 2. 평가 및 인증

CC 평가는 인증된 평가 기관에서 수행되며, 평가 결과에 대한 인증은 CCRA 회원국의 인증 기관에서 받을 수 있다. 한국의 경우 IPA가 운영하는 JISEC이 해당된다. 평가 기관은 ISO/IEC 17025 표준을 준수해야 하며, 인증 기관은 일반적으로 ISO/IEC 17065에 따라 승인된다.

ISO/IEC 17025 준수는 일반적으로 국가 승인 기관에 입증된다.

  • 캐나다: 캐나다 표준 위원회(SCC)가 시험소 인증 프로그램(PALCAN)에 따라 공통평가기준 평가 시설(CCEF)을 인증한다.
  • 프랑스: fr/Comité français d'accréditation프랑스어(COFRAC)가 일반적으로 fr/Centre d'évaluation de la sécurité des technologies de l'information프랑스어(CESTI)로 불리는 공통평가기준 평가 시설을 인증한다. 평가는 국가 정보 시스템 보안청(ANSSI)에서 지정한 규범 및 표준에 따라 수행된다.
  • 이탈리아: [http://www.ocsi.isticom.it/ OCSI (Organismo di Certificazione della Sicurezza Informatica)]가 공통평가기준 평가 실험실을 인증한다.
  • 인도: 전자정보기술부(Ministry of Electronics and Information Technology)의 STQC 국이 보증 레벨 EAL 1에서 EAL 4까지의 IT 제품을 평가하고 인증한다.[4]
  • 영국: 영국 인증 서비스(UKAS)가 [http://www.ukas.org/testing 상업 평가 시설(CLEF)] 를 인증했다. 영국은 2019년부터 CC 생태계의 소비자일 뿐이다.
  • 미국: 국립 표준 기술 연구소(NIST) 국가 자발 실험실 인증 프로그램(NVLAP)이 공통평가기준 시험소(CCTL)를 인증한다.
  • 독일: 연방 정보 기술 보안청(BSI)이 담당한다.
  • 스페인: [https://oc.ccn.cni.es/index.php?lang=en 국립 암호화 센터] (CCN)가 스페인 계획에서 운영되는 공통평가기준 [http://oc.ccn.cni.es/index.php?option=com_content&view=article&id=82&Itemid=81&lang=en 시험소]를 인증한다.
  • 네덜란드: [http://www.tuv-nederland.nl/nl/17/common_criteria.html IT 보안 분야 인증을 위한 네덜란드 계획](NSCIB)이 IT 보안 평가 시설(ITSEF)을 인증한다.
  • 스웨덴: [https://fmv.se/en/Our-activities/CSEC---The-Swedish-Certification-Body-for-IT-Security/ 스웨덴 IT 보안 인증 기관](CSEC)이 IT 보안 평가 시설(ITSEF)에 라이선스를 부여한다.


이러한 조직의 특징은 ICCC 10에서 조사 및 발표되었다.

공통 평가 기준 외에도, 평가 결과를 이해하고 비교 가능하게 하기 위한 평가 방법으로 '''CEM'''(Common Evaluation Methodology, 정보 보안 평가를 위한 공통 방법)이 개발되었다. CEM은 평가 기관이 CC 평가를 수행하기 위한 최소한의 활동을 기술한다. CEM 2.3판은 ISO/IEC 18045가 되었다.

4. 상호 인정 협정

공통평가기준 상호 인정 협정('''CCRA''', Common Criteria Recognition Arrangement)은 회원국 간에 공통평가기준(CC) 평가 결과를 상호 인정하는 국제 협정이다.[5] 1998년 캐나다, 프랑스, 독일, 영국, 미국이 처음 서명했고, 1999년 호주와 뉴질랜드,[5] 1999년 오스트레일리아와 뉴질랜드,[23] 2000년 핀란드, 그리스, 이스라엘, 이탈리아, 네덜란드, 노르웨이, 스페인이 참여했다.[5] 2000년에는 핀란드, 그리스, 이스라엘, 이탈리아, 네덜란드, 노르웨이 및 스페인이, 2003년부터는 일본도 참가했다.[23] 그 이후 이 협정은 '''공통평가기준 상호 인정 협정'''('''CCRA''')으로 이름이 변경되었고, 회원국은 계속 확대되고 있다.[5]

CCRA 내에서는 EAL 2까지의 평가만 상호 인정된다(결함 수정 보강 포함).[5] 다만, SOGIS-MRA 내의 유럽 국가들은 일반적으로 더 높은 EAL도 인정한다. EAL5 이상에서의 평가는 해당 국가 정부의 보안 요구 사항을 포함하는 경향이 있다.[5] 현재, 최고 EAL4(장애 수정 ALC_FLR의 추가를 포함)까지의 범위에서 CCRA 내의 국제적인 상호 인증이 이루어지고 있다.[23] 더 높은 EAL에 대해서는, 매우 복잡하기 때문에 국경을 넘어 승인할 의무는 없으며, 일부 국가에서 국내 한정으로 평가·인증이 이루어지고 있다.[23]

2012년 9월, CCRA 회원 다수가 상호 인정되는 CC 평가 제품의 범위를 EAL 2 이하로 낮추는(결함 수정 보강 포함) 비전 성명을 발표했다. 또한, 이 비전은 보증 수준에서 완전히 벗어나, 평가가 보증 수준이 명시되지 않은 보호 프로파일의 적합성에 국한될 것임을 나타낸다. 이는 전 세계적인 PP를 개발하는 기술 워킹 그룹을 통해 달성될 것이며, 아직 전환 기간이 완전히 결정되지 않았다.[5]

2014년 7월 2일, 2012년 비전 성명에 제시된 목표에 따라 새로운 CCRA가 비준되었다.[6] 이 협정의 주요 변경 사항은 다음과 같다.[6]


  • 협업 보호 프로파일(cPP) 또는 평가 보증 레벨 1~2 및 ALC_FLR에 대한 평가만 인정.
  • cPP의 생성을 담당하는 기술 전문가 그룹인 국제 기술 커뮤니티(iTC)의 등장.
  • 이전 CCRA에서 전환 계획, 이전 버전의 협정에 따라 발급된 인증서 인정 포함.


공통평가기준 승인 협정('''CCRA''', Common Criteria Recognition Arrangement)은 조약에 준하는 국제 협정이다.[23] CCRA의 각 가맹국은, 다른 가맹국에서 이루어진 CC 규격 평가를 상호 승인하도록 되어 있다.[23]

4. 1. CCRA의 발전

공통평가기준(Common Criteria) 표준 외에도, 각 당사자가 다른 당사자가 수행한 공통평가기준 표준에 대한 평가를 상호 인정하는 하위 조약 수준의 공통평가기준 MRA(상호 인정 협정, Mutual Recognition Arrangement)가 있었다. 1998년 캐나다, 프랑스, 독일, 영국, 미국이 처음 서명했고, 1999년 호주와 뉴질랜드,[5] 1999년 오스트레일리아와 뉴질랜드,[23] 2000년 핀란드, 그리스, 이스라엘, 이탈리아, 네덜란드, 노르웨이, 스페인이 참여했다.[5] 2000년에는 핀란드, 그리스, 이스라엘, 이탈리아, 네덜란드, 노르웨이 및 스페인이, 2003년부터는 일본도 참가했다.[23] 그 이후 이 협정은 '''공통평가기준 상호 인정 협정'''('''CCRA''')으로 이름이 변경되었고, 회원국은 계속 확대되고 있다.[5]

CCRA 내에서는 EAL 2까지의 평가만 상호 인정된다(결함 수정 보강 포함). SOGIS-MRA 내의 유럽 국가들은 일반적으로 더 높은 EAL도 인정한다. EAL5 이상에서의 평가는 해당 국가 정부의 보안 요구 사항을 포함하는 경향이 있다.[5] 현재, 최고 EAL4(장애 수정 ALC_FLR의 추가를 포함)까지의 범위에서 CCRA 내의 국제적인 상호 인증이 이루어지고 있다.[23] 더 높은 EAL에 대해서는, 매우 복잡하기 때문에 국경을 넘어 승인할 의무는 없으며, 일부 국가에서 국내 한정으로 평가·인증이 이루어지고 있다.[23]

2012년 9월, CCRA 회원 다수가 상호 인정되는 CC 평가 제품의 범위를 EAL 2 이하로 낮추는(결함 수정 보강 포함) 비전 성명을 발표했다. 또한, 이 비전은 보증 수준에서 완전히 벗어나, 평가가 보증 수준이 명시되지 않은 보호 프로파일의 적합성에 국한될 것임을 나타낸다. 이는 전 세계적인 PP를 개발하는 기술 워킹 그룹을 통해 달성될 것이며, 아직 전환 기간이 완전히 결정되지 않았다.[5]

2014년 7월 2일, 2012년 비전 성명에 제시된 목표에 따라 새로운 CCRA가 비준되었다.[6] 이 협정의 주요 변경 사항은 다음과 같다.[6]

  • 협업 보호 프로파일(cPP) 또는 평가 보증 레벨 1~2 및 ALC_FLR에 대한 평가만 인정.
  • cPP의 생성을 담당하는 기술 전문가 그룹인 국제 기술 커뮤니티(iTC)의 등장.
  • 이전 CCRA에서 전환 계획, 이전 버전의 협정에 따라 발급된 인증서 인정 포함.


공통평가기준 승인 협정('''CCRA''', Common Criteria Recognition Arrangement)은 조약에 준하는 국제 협정이다.[23] CCRA의 각 가맹국은, 다른 가맹국에서 이루어진 CC 규격 평가를 상호 승인하도록 되어 있다.[23]

4. 2. 상호 인정 범위

공통평가기준 상호 인정 협정(CCRA)은 회원국 간에 공통평가기준(CC)에 따른 정보기술(IT) 제품 평가 결과를 상호 인정하는 국제 협정이다.[5] 1998년 처음 체결된 이후 회원국이 지속적으로 확대되었다.

CCRA 내에서는 EAL 2 (결함 수정 보강 포함)까지의 평가만 상호 인정된다.[5] 다만, SOGIS-MRA에 속한 유럽 국가들은 일반적으로 더 높은 EAL도 인정한다. EAL5 이상의 평가는 해당 국가 정부의 보안 요구 사항을 포함하는 경향이 있다.

2012년 9월, CCRA 회원국들은 상호 인정되는 CC 평가 제품의 범위를 EAL 2 이하 (결함 수정 보강 포함)로 낮추는 비전 성명을 발표했다. 또한, 평가 보증 레벨(EAL)에서 벗어나, 평가가 보호 프로파일(PP) 적합성에 국한될 것임을 밝혔다.

2014년 7월 2일, 새로운 CCRA가 비준되었다.[6] 이 협정에서는 협업 보호 프로파일(cPP) 또는 평가 보증 레벨 1~2 및 ALC_FLR에 대한 평가만 인정하며, cPP 생성을 담당하는 국제 기술 커뮤니티(iTC)가 등장했다.

5. 비판 및 논란

2007년 8월, ''Government Computing News'' (GCN) 칼럼니스트 윌리엄 잭슨은 공통평가기준 방법론과 공통평가기준 평가 및 검증 제도(CCEVS)에 의한 미국의 구현에 대해 비판적으로 검토했다.[9] 칼럼에서는 보안 업계 임원, 연구원, 국가 정보 보증 파트너십(NIAP)의 대표를 인터뷰했다. 이 기사에서 언급된 반대 의견은 다음과 같다.


  • 평가는 비용이 많이 드는 과정이며 (종종 수십만 미국 달러로 측정됨) - 벤더가 투자에 대한 수익이 더 안전한 제품을 보장하지는 않는다.
  • 평가는 실제 보안, 기술적 정확성 또는 제품 자체의 장점이 아닌 평가 문서의 평가에 주로 초점을 맞춘다. 미국 평가의 경우, EAL5 이상에서만 국가안보국 전문가가 분석에 참여하고, EAL7에서만 전체 소스 코드 분석이 필요하다.
  • 평가 증거 및 기타 평가 관련 문서를 준비하는 데 필요한 노력과 시간은 너무 번거로워서 작업이 완료될 때쯤이면 평가 대상 제품은 일반적으로 구식이 된다.
  • 공통평가기준 벤더 포럼과 같은 조직을 포함한 업계의 의견은 전체 프로세스에 거의 영향을 미치지 않는다.


2006년 연구 논문에서 컴퓨터 전문가 데이비드 A. 휠러는 공통평가기준 프로세스가 자유 오픈 소스 소프트웨어 (FOSS) 중심 조직 및 개발 모델을 차별한다고 주장했다.[10] 공통평가기준 보증 요구 사항은 전통적인 폭포수 모델 소프트웨어 개발 방법론에서 영감을 받는 경향이 있다. 반면에 많은 FOSS 소프트웨어는 현대적인 애자일 소프트웨어 개발 패러다임을 사용하여 제작된다. 일부에서는 두 패러다임이 잘 맞지 않는다고 주장하지만,[11] 다른 사람들은 두 패러다임을 조화시키려고 시도했다.[12]

정치학자 얀 칼버그는 인증을 받은 제품의 실제 생산에 대한 통제 부족, 규정 준수를 모니터링하는 상시 인력으로 구성된 조직 기구의 부재, 그리고 공통평가기준 IT 보안 인증에 대한 신뢰가 지정학적 경계를 넘어 유지될 것이라는 생각에 대한 우려를 제기했다.[13]

2017년, ROCA 취약점이 공통평가기준 인증 스마트 카드 제품 목록에서 발견되었다. 이 취약점은 공통평가기준 인증 체계의 몇 가지 단점을 강조했다.[14]

  • 이 취약점은 암호 분석 커뮤니티에서 게시 및 분석되지 않은 자체 개발 RSA 키 생성 알고리즘에 있었다. 그러나 공통평가기준 시험 연구소인 독일의 TÜV Informationstechnik GmbH (TÜViT)는 해당 사용을 승인했고 독일의 인증 기관인 연방 정보 보안청 (BSI)은 취약한 제품에 대한 공통평가기준 인증서를 발급했다. 평가된 제품의 보안 대상은 RSA 키가 표준 알고리즘에 따라 생성된다고 주장했다. 이 취약점에 대응하여 연방 정보 보안청 (BSI)은 이제 구현된 독점 암호화가 권장 표준과 정확히 일치하지 않는 경우 최소한 인증 보고서에 이를 명시하도록 요구함으로써 투명성을 개선할 계획이다. 연방 정보 보안청 (BSI)은 어떠한 방식으로도 독점 알고리즘을 게시하도록 요구할 계획이 없다.
  • 현재 인증 기관은 공통평가기준 인증서에 명시된 보안 주장이 더 이상 유효하지 않다는 것을 알고 있지만, 국가 정보 시스템 보안청(ANSSI)도 연방 정보 보안청 (BSI)도 해당 인증서를 취소하지 않았다. 연방 정보 보안청 (BSI)에 따르면, 인증서는 오해를 받아 발급된 경우, 예를 들어 잘못된 증거가 제출된 것으로 밝혀진 경우에만 철회될 수 있다. 인증서가 발급된 후에는 개선되고 새로운 공격이 발견됨에 따라 인증서의 유효성이 시간이 지남에 따라 감소한다고 추정해야 한다. 인증 기관은 유지 관리 보고서를 발급하고 제품에 대한 재인증을 수행할 수도 있다. 그러나 이러한 활동은 벤더가 시작하고 후원해야 한다.
  • 여러 공통평가기준 인증 제품이 ROCA 결함의 영향을 받았지만, 인증과 관련하여 벤더의 대응은 달랐다. 일부 제품에 대해 3072 및 3584 비트 길이의 RSA 키만 최소 100 비트의 보안 수준을 갖는다는 내용의 유지 관리 보고서가 발급된 반면, 일부 제품의 경우 유지 관리 보고서에는 TOE에 대한 변경 사항이 인증된 암호 보안 기능에 영향을 미친다는 언급 없이, 해당 변경 사항이 지침 문서 수준이며 보증에 아무런 영향을 미치지 않는다고 결론 내렸다.
  • 연방 정보 보안청 (BSI)에 따르면, 인증된 최종 제품의 사용자는 벤더로부터 ROCA 취약점에 대한 정보를 받아야 했다. 그러나 이 정보는 취약한 제품을 75만 개 이상의 에스토니아 신분증에 배포한 에스토니아 당국에 적시에 전달되지 않았다.

5. 1. 인증의 가치

공통평가기준 인증은 보안을 직접 보장하지 않지만, 평가된 제품의 보안 속성에 대한 주장이 독립적으로 검증되었음을 보장한다. 즉, 공통평가기준 표준에 따라 평가된 제품은 사양, 구현 및 평가 프로세스가 엄격하고 표준적인 방식으로 수행되었음을 보여주는 명확한 증거를 제시한다.

마이크로소프트의 Windows Server 2003 및 Windows XP를 포함한 다양한 마이크로소프트 윈도우 버전이 인증을 받았지만, 보안 취약점을 해결하기 위한 보안 패치는 여전히 마이크로소프트에서 게시되고 있다. 이는 공통평가기준 인증 과정에서 공급업체가 특정 보안 기능 분석을 제한하고, 제품이 직면하는 운영 환경 및 위협 강도에 대한 특정 가정을 할 수 있기 때문이다. 또한 CC는 비용 효율적이고 유용한 보안 인증을 위해 평가 범위를 제한할 필요가 있음을 인식하며, 평가된 제품은 보증 수준 또는 PP에 지정된 세부 수준으로 검사된다. 따라서 평가 활동은 특정 깊이, 시간, 리소스 사용으로만 수행되며 의도된 환경에 대한 합리적인 보증을 제공한다.

마이크로소프트의 경우, TOE(평가 대상)가 통신하는 다른 모든 시스템이 동일한 관리 제어 하에 있으며 동일한 보안 정책 제약 조건 하에서 작동한다고 가정한다(A.PEER). TOE는 전체 네트워크가 동일한 제약 조건 하에서 작동하고 단일 관리 도메인 내에 있는 경우에만 네트워크 또는 분산 환경에 적용될 수 있다. 이 가정은 해당 제품이 준수하는 제어된 액세스 보호 프로파일(CAPP)에 포함되어 있다. 이러한 가정 등을 기반으로 윈도우 제품의 주장된 보안 기능이 평가된다. 따라서 이러한 제품은 '평가된 구성'이라고도 하는 가정된 특정 상황에서만 안전하다고 간주해야 한다.

마이크로소프트 윈도우를 정확한 평가된 구성으로 실행하든 그렇지 않든, 윈도우 취약점에 대한 마이크로소프트의 보안 패치를 적용해야 한다. 보안 취약점이 제품의 평가된 구성에서 악용될 수 있다면, 해당 제품의 공통평가기준 인증은 공급업체가 자발적으로 철회해야 한다. 또는 공급업체는 평가된 구성 내에서 보안 취약점을 수정하기 위한 패치 적용을 포함하도록 제품을 재평가해야 한다. 공급업체가 이러한 단계를 수행하지 않으면 해당 제품이 평가된 국가의 인증 기관에서 제품 인증이 강제로 철회된다.

인증된 마이크로소프트 윈도우 버전은 평가된 구성에 마이크로소프트 보안 취약점 패치를 적용하지 않고 EAL4+에 남아 있다. 이는 평가된 구성의 제한 사항과 강점을 모두 보여준다.

5. 2. 비판

2007년 8월, ''Government Computing News'' (GCN) 칼럼니스트 윌리엄 잭슨은 공통평가기준 방법론과 공통평가기준 평가 및 검증 제도(CCEVS)에 의한 미국의 구현에 대해 비판적으로 검토했다.[9] 이 기사에서 언급된 반대 의견은 다음과 같다.

  • 평가는 비용이 많이 드는 과정이며 (종종 수십만 미국 달러로 측정됨) - 벤더가 투자에 대한 수익이 더 안전한 제품을 보장하지는 않는다.
  • 평가는 실제 보안, 기술적 정확성 또는 제품 자체의 장점이 아닌 평가 문서의 평가에 주로 초점을 맞춘다. 미국 평가의 경우, EAL5 이상에서만 국가안보국 전문가가 분석에 참여하고, EAL7에서만 전체 소스 코드 분석이 필요하다.
  • 평가 증거 및 기타 평가 관련 문서를 준비하는 데 필요한 노력과 시간은 너무 번거로워서 작업이 완료될 때쯤이면 평가 대상 제품은 일반적으로 구식이 된다.
  • 공통평가기준 벤더 포럼과 같은 조직을 포함한 업계의 의견은 전체 프로세스에 거의 영향을 미치지 않는다.


2006년 연구 논문에서 컴퓨터 전문가 데이비드 A. 휠러는 공통평가기준 프로세스가 자유 오픈 소스 소프트웨어 (FOSS) 중심 조직 및 개발 모델을 차별한다고 주장했다.[10] 공통평가기준 보증 요구 사항은 전통적인 폭포수 모델 소프트웨어 개발 방법론에서 영감을 받는 경향이 있다. 반면에 많은 FOSS 소프트웨어는 현대적인 애자일 소프트웨어 개발 패러다임을 사용하여 제작된다. 일부에서는 두 패러다임이 잘 맞지 않는다고 주장하지만,[11] 다른 사람들은 두 패러다임을 조화시키려고 시도했다.[12]

정치학자 얀 칼버그는 인증을 받은 제품의 실제 생산에 대한 통제 부족, 규정 준수를 모니터링하는 상시 인력으로 구성된 조직 기구의 부재, 그리고 공통평가기준 IT 보안 인증에 대한 신뢰가 지정학적 경계를 넘어 유지될 것이라는 생각에 대한 우려를 제기했다.[13]

2017년, ROCA 취약점이 공통평가기준 인증 스마트 카드 제품 목록에서 발견되었다. 이 취약점은 공통평가기준 인증 체계의 몇 가지 단점을 강조했다.[14]

  • 이 취약점은 암호 분석 커뮤니티에서 게시 및 분석되지 않은 자체 개발 RSA 키 생성 알고리즘에 있었다. 그러나 공통평가기준 시험 연구소인 독일의 TÜV Informationstechnik GmbH (TÜViT)는 해당 사용을 승인했고 독일의 인증 기관인 연방 정보 보안청 (BSI)은 취약한 제품에 대한 공통평가기준 인증서를 발급했다. 평가된 제품의 보안 대상은 RSA 키가 표준 알고리즘에 따라 생성된다고 주장했다. 이 취약점에 대응하여 연방 정보 보안청 (BSI)은 이제 구현된 독점 암호화가 권장 표준과 정확히 일치하지 않는 경우 최소한 인증 보고서에 이를 명시하도록 요구함으로써 투명성을 개선할 계획이다. 연방 정보 보안청 (BSI)은 어떠한 방식으로도 독점 알고리즘을 게시하도록 요구할 계획이 없다.
  • 현재 인증 기관은 공통평가기준 인증서에 명시된 보안 주장이 더 이상 유효하지 않다는 것을 알고 있지만, 국가 정보 시스템 보안청(ANSSI)도 연방 정보 보안청 (BSI)도 해당 인증서를 취소하지 않았다. 연방 정보 보안청 (BSI)에 따르면, 인증서는 오해를 받아 발급된 경우, 예를 들어 잘못된 증거가 제출된 것으로 밝혀진 경우에만 철회될 수 있다. 인증서가 발급된 후에는 개선되고 새로운 공격이 발견됨에 따라 인증서의 유효성이 시간이 지남에 따라 감소한다고 추정해야 한다. 인증 기관은 유지 관리 보고서를 발급하고 제품에 대한 재인증을 수행할 수도 있다. 그러나 이러한 활동은 벤더가 시작하고 후원해야 한다.
  • 여러 공통평가기준 인증 제품이 ROCA 결함의 영향을 받았지만, 인증과 관련하여 벤더의 대응은 달랐다. 일부 제품에 대해 3072 및 3584 비트 길이의 RSA 키만 최소 100 비트의 보안 수준을 갖는다는 내용의 유지 관리 보고서가 발급된 반면, 일부 제품의 경우 유지 관리 보고서에는 TOE에 대한 변경 사항이 인증된 암호 보안 기능에 영향을 미친다는 언급 없이, 해당 변경 사항이 지침 문서 수준이며 보증에 아무런 영향을 미치지 않는다고 결론 내렸다.
  • 연방 정보 보안청 (BSI)에 따르면, 인증된 최종 제품의 사용자는 벤더로부터 ROCA 취약점에 대한 정보를 받아야 했다. 그러나 이 정보는 취약한 제품을 75만 개 이상의 에스토니아 신분증에 배포한 에스토니아 당국에 적시에 전달되지 않았다.

5. 3. 대안

공통평가기준(CC) 외에도 다양한 보안 평가 및 인증 제도가 존재한다. 암호화 승인은 캐나다/미국의 FIPS-140 구현, 영국의 CESG 지원 제품 제도(CAPS) 등과 같이 별도로 처리된다.[15]

영국은 상호 인정의 시간, 비용 및 간접비가 시장 운영을 방해하는 것으로 보고 여러 대체 방안을 내놓았다. 정부 시스템 보증을 위한 CESG 시스템 평가(SYSn) 및 패스트 트랙 접근 방식(FTA) 제도는 현재 CESG 맞춤형 보증 서비스(CTAS)로 통합되었다.[16] CESG 클레임 테스트 마크(CCT 마크)는 제품 및 서비스에 대한 덜 포괄적인 보증 요구 사항을 비용 및 시간 효율적인 방식으로 처리하는 것을 목표로 한다.

2011년 초, NSA/CSS는 보호 프로파일 중심의 평가 접근 방식을 제안하는 논문을 발표했다.[17] 이 접근 방식에서 이해 관계자 커뮤니티는 기술 유형을 중심으로 형성되며, 해당 기술 유형에 대한 평가 방법론을 정의하는 보호 프로파일을 개발한다. 이는 상호 인정에 부정적인 영향을 미칠 수 있다는 우려가 있다.[18]

2012년 9월, Common Criteria는 이전 해의 제안을 상당 부분 구현한 비전 성명[19]을 발표했다. 이 비전의 주요 요소는 기술 커뮤니티가 합리적이고, 비교 가능하며, 재현 가능하고, 비용 효율적인 평가 결과를 지원하는 보호 프로파일(PP) 작성에 집중하고, 가능하다면 이러한 PP에 따라 평가를 수행해야 하며, 그렇지 않은 경우 보안 대상 평가의 상호 인정은 EAL2로 제한한다는 것이다.

참조

[1] 웹사이트 Publications: CC Portal https://www.commoncr[...] 2024-01-06
[2] 웹사이트 Common Criteria - Communication Security Establishment https://www.cse-cst.[...] 2015-03-02
[3] 웹사이트 Common Criteria Certified Products https://www.commoncr[...] 2023-12-30
[4] 웹사이트 Indian Common Criteria Certification Scheme (IC3S) Overview https://www.commoncr[...] 2023-12-30
[5] 웹사이트 Members of the CCRA http://www.commoncri[...]
[6] 웹사이트 Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security http://www.commoncri[...] 2023-12-30
[7] 웹사이트 Common Criteria Management Committee Vision Statement http://www.commoncri[...] 2023-12-30
[8] 웹사이트 Versions of Windows obtain Common Criteria EAL level 4+ http://www.nist.org/[...]
[9] 뉴스 Under Attack: Common Criteria has loads of critics, but is it getting a bum rap http://gcn.com/artic[...] Government Computer News 2007-12-14
[10] 웹사이트 Free-Libre / Open Source Software (FLOSS) and Software Assurance / Software Security https://dwheeler.com[...] 2023-12-30
[11] 간행물 Security Engineering and eXtreme Programming: An Impossible Marriage?
[12] 웹사이트 Towards Agile Security Assurance http://lersse-dl.ece[...] 2023-12-30
[13] 웹사이트 Common Criteria meets Realpolitik - Trust, Alliances, and Potential Betrayal https://personal.utd[...] 2023-12-30
[14] 논문 Estonian Electronic Identity Card and its Security Challenges https://dspace.ut.ee[...] University of Tartu 2023-12-30
[15] 웹사이트 CAPS: CESG Assisted Products Scheme http://www.cesg.gov.[...]
[16] 문서 Infosec Assurance and Certification Services (IACS) http://www.cesg.gov.[...]
[17] 웹사이트 Common Criteria Reforms: Better Security Products Through Increased Cooperation with Industry http://www.niap-ccev[...]
[18] 웹사이트 Common Criteria "Reforms"—Sink or Swim-- How should Industry Handle the Revolution Brewing with Common Criteria? http://community.ca.[...]
[19] 웹사이트 CCRA Management Committee Vision statement for the future direction of the application of the CC and the CCRA https://commoncriter[...] 2023-12-30
[20] 웹사이트 ITセキュリティ評価及び認証制度（JISEC） https://www.ipa.go.j[...] IPA 独立行政法人情報処理推進機構
[21] 웹사이트 政府機関の情報セキュリティ対策のための統一管理基準(1.5.1.1 情報システムのセキュリティ要件及び1.5.2.2 機器等の購入) http://www.nisc.go.j[...] 内閣官房情報セキュリティセンター 2011-04
[22] 웹사이트 IT セキュリティ評価及び認証制度等に基づく認証取得製品分野リスト http://www.meti.go.j[...] 経済産業省 2011-04
[23] 웹사이트 国際承認アレンジメント（CCRA） https://www.ipa.go.j[...] IPA 独立行政法人情報処理推進機構


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com