본문 바로가기

인증

변경된 CC 평가 인증 제도

안녕하세요, 다시 CC인증에 대해서 이야기를 시작하려고 합니다. 제가 마지막 포스트를 한 것이 2008년 11월 이니까 거의 1년 반을 쉬게된 셈이네요.

다시 한번 심기일전하여 포스트를 해보록 하겠습니다.

마지막 포스트 이후 그간 많은 것들이 변했지만 4/30(금)에 열린 품질인증 컨퍼런스를 통해 국내 CC인증 평가 제도가 많이 변경이 된 것을 알 수 있었습니다. 오셔서 직접 듣고 보신 분들도 계시겠지만 그 변경된 제도를 다시 한번 정리해보고 실제적으로 어떤 의미가 있는지, 앞으로는 어떻게 예상이 되는지를 한번 알아보려고 합니다. (이 포스트는 평가기관 어떠한 관계도 없음을 알려드립니다.)



변경 승인 절차 간소화


이전에는 CC인증을 받은 평가 제품이 변경이 일어나 인증 효력을 유지하기 위해 변경 승인을 신청할 때 인증기관(국정원 IT보안인증사무국)으로 연락(전화)하여 필요한 서류와 제출물들을 준비하여 제출하면 인증기관이 해당 제품을 평가한 평가기관으로 평가 의뢰를 하는 식으로 진행이 되었었습니다.

그러므로 인해서 업체에서는 하루라도 빨리 변경 승인을 받은 후 제품을 배포해야 하는데 인증기관이나 평가기관의 다른 많은 업무들로 인해서 지연되는 경우가 있을 수 있었습니다.

그러나 이번에 변경되어 현재 시행하고 있는 "변경 승인 절차의 간소화"는 변경 승인 신청을 평가를 받은 평가기관으로 하게되어 중간 인증기관으로 했던 절차를 없애버린 것입니다. 평가기관은 변경 승인 신청을 받아 가능하면 해당 평가 제품을 평가한 평가자에게 직접 변경 승인 평가를 담당하도록 합니다. 해당 평가자가 다른 제품 평가를 진행 중에 있어도 변경 승인을 동시에 평가 진행하여 신청 업체는 바로 변경 승인 절차(평가)에 들어 갈 수가 있는 것입니다.

★ 요즘에는 민간 평가 기관들이 많이 있기 때문에 한 회사에서도 여러 평가 기관과 평가 계약을 맺고 평가를 진행하는데,  평가 신청 업체에서는 향후 이러한 변경 승인까지 고려한 제품의 유지보수를 계획해야만 시장에 발빠르게 인증 제품을 유지 할 수 있을 것입니다.



EAL2 평가자 간소화: 2명 -> 1명


이전에는 평가 제품에 따라 다르기는 하지만 보통 2명의 평가자가 배정되어 4-8개월 평가를 진행했었습니다. 그러다가 평가기관의 평가자가 평가 수요에 미치지 못하자 "3인 2평가반" 이라고 해서 1명의 "선임평가자"는 2개의 평가반에 걸쳐 각 평가반에 있는 1명의 평가자와 함께 평가를 진행하도록 개선안이 나왔었습니다. 그러는 가운데 1-2개의 민간 평가기관이 더 생기면서 이 제도가 아예 없어진 것은 아니지만 크게 영향을 미치지는 못했습니다.

그리고 근래에는 평가 등급이 EAL2 이상으로 다양한 등급으로 평가를 받는 제품들이 늘고 있습니다. 이것은 공공기관에 도입되는 제품은 EAL2 이상이면 된다는 정책으로 인한 것인데요, 현재 방화벽은 보호프로파일의 의도와 같이 공공 기관의 중요한 장비인 만큼 EAL4로 받고 있고, 그와 같은 중요 장비라고 판단되는 것은 수요 기관에서도 EAL4 정도의 등급을 원하고 있습니다만, 그 외 제품들은 시장 상황에 맞추어 EAL3 부터 EAL2 도 점차 많아지고 있는 추세 입니다.

보통, 국내 평가 제도인 경우 (제품에 따라, 평가 기관에 따라 다르지만) EAL4인 경우 5개월, EAL3는 4개월, EAL2인 경우는 약 3개월 정도 잡았었습니다. 물론 대강 그렇다는 것이고, EAL2 였어도 평가자 2명이 3개월은 족히 걸렸습니다. 물론 제품의 복잡도에 따라 다른 것은 당연하고요.

그러는 가운데 EAL2 등급의 평가 담당자를 2명에서 1명으로 줄인 다는 것은 기간을 줄인다기 보다는 평가 비용(수수료)를 줄인다는 의미로 받아들여집니다. 그렇다고 수수료 비용이 1/2로 줄어드는 것은 아닐 것입니다. 그렇다면 평가자 인건비 정도해서 수수료가 줄어들 것 같습니다. 이날 KISA 이강석팀장의 발표에 있어서도 27%의 비용이 감소할 것이라고 하는데 그것은 최소 순수 평가 수수료에 해당하는 것 같습니다. 물론, 앞으로 설명할 평가 제도가 변경되었기에 1인 평가가 가능할 것이고요.

★ 그렇다면, 평가 신청 업체의 비용은 수수료 외에 비용이 절감 되는 것은 없을까요? 실제로 업체가 느끼는 비용의 감소가 있을까요? (평가 수수료가 기간에 비례하기 때문에) 오히려 평가자가 1명이면 기간이 늘어나서 평가 수수료도 같이 늘어나지 않을까요? 2명이 하던 일을 1명이 해야 하니까요.  그러나 앞서 말씀드렸듯이 이것은 평가 제도가 변경이 되었기 때문에 가능한 것이라 생각됩니다. 실제로 평가 기간과 EAL2 등급의 평가 신청을 했는데 3개월이 넘지 않는 것으로 이야기가 되어 가고 있는 것을 보면 어느정도 비용 감소 부분은 반영이 되고 있는 것 같습니다. 그러나 이는 철저히 평가 제품의 복잡도 측면에서도 고려가 되어야 합니다.



제출물 간소화


가장 즁요한 변경 사항입니다. 이 부분이 아직까지는 변경된 평가 제도로 평가를 진행해 보지 않아서 정확히 실제적으로 얼마나 간소화가 되어 준비하는 업체가 피부에 느낄 수 있는 제도 개선인지 알수는 없습니다만 어떤 부분이 변경이 되었는지 간략히 살펴보겠습니다.

우선 개념은, 기존에 제출했던 보증 문서들을 평가하는 것이 주였다면 변경된 제도에서는 기능/취약성 중심의 평가로 제출물을 간소화 하겠다는 것입니다. 다음은 EAL4 기준으로 제도 개선 후의 제출물의 변경 사항입니다.

출처: 2010 품질인증 컨퍼런스 발표 자료 (KISA)

보안목표명세서(ASE_*):
  • 제출/평가 동일
  • TOE의 범위가 모든 제품으로 확대 서술
  • 비보안기능과 보안기능 연관 인터페이스도 포함

 설명서(AGD_*):

  • 제출/평가 동일
  • 인수/설치/준비/운영

기능명세서(ADV_FSP.4)

  • 제출 안함
  • 보안목표명세서(TSS: TOE 요약 명세)와 설명서도 대체

TOE 설계서(ADV_TDS.3)

  • 제출 하지만 평가 안함
  • 제출은 CC인증 문서가 아니가 신청 업체 자체 문서 가능
  • 평가시 (취약성 분석 등) 제품 파악을 위한 참고
  • 참고를 위해 추가 제출 요청이 있을 수 있음

구현검증명세서(ADV_IMP.1)

  • 제출/평가 동일
  • 기존 처럼 EAL4 경우 일부 제출

보안구조서(ADV_ARC.1)

  • 제출 안함
  • 취약성분석서로 대체 (추가 제출분)
 
시험서(ATE_*)

  • ATE_COV.2(범위) 나 ATE_DPT.2(깊이) 같은 분석서는 제출하지 않고 평가자 직접 수행
  • ATE_FUN.1에서 요구하는 시험서(기능/모듈) 제출/평가
  • 대신 내용 중에 "예상 결과"와 "실제 결과" 중 "실제 결과"는 생략 가능 (화면 캡처 필요 없음)

형상관리문서(ALC_CM*)

  • 평가 안함
  • 개발 환경 보안 점검시 평가

배포문서(ALC_DEL.1)

  • 평가 안함
  • 개발 환경 보안 점검시 평가

개발보안문서(ALC_DVS.1)

  • 평가 안함
  • 개발 환경 보안 점검시 평가

생명주기정의문서(ALC_LCD.1)

  • 제출/평가 동일

개발도구문서(ALC_TAT.1)

  • 제출/평가 동일
* 개발환경 보안 점검의 유효 기관은 이전과 동일 2년 (그간 환경의 변화가 없을 시)


개발자 취약성분석 서(AVA_VAN.3)

  • 제출/평가
  • 이전 제도에는 제출하지 않고 평가만 했으나 제출하는 것으로 변경
  • 위 "보안구조서"에 취약성 항목 추가하여 제출
  • 분석의 범위는 EAL4 경우 소스코드 까지

제출물들만 보자면 분명히 간소화가 된 부분이 있습니다. 실제 평가 계획도 문서 평가 보다는 시험위주로 하는 것으로 보아 신청 업체로서는 문서에 대한 부담이 줄었습니다.

신청 업체가 준비하는 문서 중 가장 많은 비중을 차지 할 수 밖에 없는 (그래서 시간이 많이 걸렸던) "설계서"는 평가를 하지 않지만 제출(내부 설계서를 그대로라도)을 하므로, 이것은 신청 업체의 개발 문화에 따라 많이 차이가 날 것으로 판단이 됩니다. 기존에 개발 문서가 잘 되어 있는 회사에서는 이를 인증 문서로 "재작성" 하지 않아서 확실히 제출 문서 작업의 양이 줄겠지만 그마저 없는 회사의 경우는 회사 전체로 보았을 때 준비해야 하는 문서는 그리 차이가 나지 않을 것입니다. 물론 평가 시, 보완 요청(OR: Observation Report)을 받지 않는 것은 개발 문서가 있던지 없던지 상관 없이 문서에 대한 부담이 준 것은 사실이고요.

그러나 설계서 또한 평가자가 평가의 이해를 위해 얼마든지 추가 요청을 할 수 있어 이 또한 평가 시 업체의 개발 문서를 작성하는 개발 문화에 따라 업무량이 많이 판가름이 날 것 같습니다.

★ 그렇다고 한다면 예상 하셨듯이, 개발 프로세스(문화)가 역시 국내에서 CC인증을 받을 때 더 지대한 영향을 주 수 밖에 없습니다. 국내 CC 인증 평가가 기능/취약성 시험 위주로 간다는 것은 그만큼 제품의 보안성/안정성이 큰 문제가 될 수 있게 되고 이것의 결과는 개발 문화의 차이가 벌여 놓을 것이기 때문입니다.

그리고 한가지 평가의 경향이 기능/취약성 시험 위주로 간다고 하지만 거꾸로 평가를 통해 공개되는 문서인 "보안목표명세서"와 "설명서"는 더욱 더 세밀하게 평가하고 보완요청을 하고 있으니 더 잘 준비해야 할 것입니다.



보안성 강화


이것은 기존에 CC의 개념에서 제공하고 있는 것 중 TOE(평가 대상)의 범위를 개발 업체가 지정할 수 있었던 것을 아예 없애고 "TOE = 제품" 이라는 논리로 개발 업체가 임의로 선택할 수 없음을 의미합니다. 즉, 사용자에게 제공되는 제품 (더 정확히는 패키지, 설치본, 장비) 그대로 모두 다 평가를 받아야만 한다는 것입니다.

게다가, 보안 기능 뿐만 아니라 비보안 기능 까지도 기능/취약성 위주의 평가를 해야 하기 때문에 제품이 제공하는 모든 기능을 시험해야 하며, 추가적으로 (여기에 대해서는 상황도 다양하고 논의가 되어야 할 부분이 많은데) 비/보안 기능의 외부 3'rd party 프로그램 (혹은 같은 회사의 제품) 간의 인터페이스 또한 어떤 식으로든 시험이 되어야 한다는 것입니다.

요즘 보안 제품의 특성은 융합/연동이기 때문에 이 부분은 잘못하다가는 배보다 배꼽이 더 커지는 불상사가 발생할 수도 있을 것입니다. 그리고 실제 취약성의 경우 이러한 인터페이스에서 주로 일어나고 있기 때문에 더욱 관심이 가는 부분이 아닐 수 없습니다. 그래서 이날 발표한 KISA의 선임평가자는 이러한 인터페이스의 SQL Injection과 같은 취약성 분석을 위해서 소스 코드 제출도 요청할 수 있다고 합니다.

이런 저런 측면을 다 고려한다면, 평가를 위해 제출해야 하는 제출물의 개수는 줄어 들 수 있겠지만 각각의 제출물의 양은 늘어서 비슷해지지 않을까 모르겠습니다.



CC 버전 호환성 강화


KiSA 홈페이지에 공지된 바와 같이 CC v2.3은 올해 6월 30일이면, CCv2.3으로는 평가 신청을 할 수 없었습니다. (기존 인증서는 계속 유지 가능) 변경승인은 그렇지 않은 것으로 알고 있었는데, 재평가도 신청을 하려면 모두 다 CC v3.1로 다시 신청을 해야 해서 자동으로 신규 평가가 됩니다.

그러나 변경된 제도에서는 이 둘 모두(변경 승인, 재평가 신청) CC v3.1로 재평가/변경승인을 그대로 할 수 있도록 그 호환성이 강화 되었다는 것입니다.

★ 그래도 문서의 CCv3.1로의 변경은 불가피한데, 이는 평가기관에서 발표하기로는 최소한으로 할 수 있도록 한다는 코멘트를 했습니다. 적어도 "보안목표명세서"는 수정이 완벽하게 되어야 하겠고 그 변경의 정도에 따라 (보안영향분석) 평가시 요청을 하겠지요.

그렇다면 이러한 제도가 재평가/변경승인 시에 어떻게 되는지도 궁금합니다.



적용 실행


전면 시행(반듯이)은 올해 7월 1일 부터 입니다. 그 전까지는 업체의 선택
으로 할 수 있다고 합니다. 그리고 이날 발표에 의하면 "인증효력유지신청" 시 기 적용된 기준을 적용한다고 했는데 - 그렇게 된다면 기존에 개발 업체가 임의로 정한 TOE의 범위를 그대로 적용한다는 것인데 - 매우 관대하다 생각이 되어 한번더 문의를 했습니다.

기존 제도로 인증 받은 제품의 경우 재평가나 변경 승인 신청 시에는 TOE를 임의로 선택할 수 없다고 합니다. 그러니까 변경 된 후의 제도를 반듯이 (7월 1일 이후) 따라야 하는 것이지요. 제출 문서의 경우 기존의 것을 그대로 수용 한다는 취지로 그런 것이라고 하는데, TOE의 범위가 변경되면 "보안목표명세서"는 분명히 바뀔 것이고, 바꾸어야만 하는 것은 명백하고, 그리고 나머지 문서들은 변경된 제도에 의해서 제출하지 않는 것이 많은데 오히려 더 혼돈되는 것이 많을 것 같습니다. (제출하는 문서가 있고, 그렇지 않은 문서가 있고... 등) 아무튼 보안성 강화 측면에서의 재평가/변경승인은 어쩔 수 없는 것 같습니다. 이번 개선의 주요 변경 사항이니 말입니다.

그래서 이번 제도 개선이 문서의 측면 보다는 TOE 범위의 확대(전체)에 따른 보안성 개선이 개발 업체에게 더욱 큰 부담으로 돌아오지 않을까 합니다. 문서 위주 였던 이전 보다 더욱 실제적인 부담이기를 바라고 또 시장의 요구사항과의 충돌이 아니라, 전체 사용자 측면의 개선도 같이 이루어 지면서 개선되는  보안성 측면이라면 발전 가능성이 있어 보이기도 합니다. 굵게

★ 사용자의 보안 측면과의 충돌에 대해서는 다음에 더욱 자세히 알아보도록 준비하겠습니다. 이것이 중요한 이유는 보안이라는 것은 개발 업체만 "완벽한" 보안 기능 제품을 만든다고 이루어 지지 않기 때문이라는 점을 누구나 다 알기 때문입니다. 수요측(사용자)와 그리고 또 정책 기관 또한 못지 않게 중요하기 때문입니다. 특히 이러한 인증 시장에서는 오히려 사용자에게 교육이나 정책으로 가이드하고 개발 업체에게는 자육성과 창의성을 주어서 혁신적인 제품을 만들도록 하는것이 장기적인 국가 보안과 경쟁력에 도움이 되지 않을까 합니다.



평가 수수료 할인 계속


KISA는 평가 신청 업체가 중소기업법 제2조에 따른 중소기업이면 년 1회 50% 할인하는 정책은 유지할 것이라고 합니다. 현재는 3차년도로 올해 8월부터 201년 7월까지 인증 받는 것은 50% 할인이 됩니다. 한 회사에서 2차년도로 7월에 할인 받고 또 8월에 할인 받을 수 있는 것입니다.

★ 그러나 KISA는 정책적으로 국내 평가반을 줄이고 정책 연구나 고등급/국제 인증에 비중을 더욱 두므로 얼마나 많은 중소 기업이 이러한 혜택을 받을지는 모르겠습니다. 현재 국내 평가의 경우 대기기간(평가 신청 후, 평가 착수까지의 시간)은 민간 평가 업체들이나 KISA나 비슷한 것으로 알고 있습니다.



마치며


이번 제도 개선은 그간의 중복작업이니, 효용 없는 문서 작업이니 하면서 소위 "쓸 데 없는 짓"으로 치부 되었던 국내 CC인증 제도의 한 부분이었던 문서 평가 보다는 실제적으로 기능/취약성 시험 평가로 개선이 된 점은 보안성 측면에서는 더욱 좋아진 것은 사실입니다.

그러므로 평가자의 자질과 능력이 더욱 중요시 될 것입니다. 그래서 평가 기술 위원회가 이를 조정 할 것이라고 합니다만 이미 평가를 몇년간 진행해 왔고 인증 시장이 성숙해 있는 시점에서 어떻게 바꾸어 갈 수 있을지 귀추가 주목이 되는 부분입니다. 그리도 또한 평가를 하는 평가기관과 평가 받는 개발 업체에 대해서만 개선할 것이 아니라 사용자 측면에 있어서도 제도/정책적으로 개발 업체가 좀 더 혁신적인 방법으로 경쟁력을 갖도록 가이드 하는 것이 필요 할 것 같습니다.

그리고 국내에서는 CC 인증이 더 이상 공통평가기준(ISO/IEC 15408)과 멀어져 사용자-평가자-개발자가 공통의 기준으로 사용하고 평가하고 개발하는데 그 중요한 목적이 달성되지 않아 보안성 평가 측면에 있어서 퇴보를 하지 않을까 하는 우려점도 남습니다. 우리나라가 이 국제 공통평가기준을 도입하고 또한 그렇게 빠르게 CCRA(Common Criteria Recognition Arrangement)에 가입하는 노력이 허사로 돌아가지 않고 국내 제품들이 계속적으로 글로벌하게 해외 시장에 진출하는데 있어 일관된 기준이 적용되어야 경쟁력이 쌓이지 않을까 합니다.

막상 정리하다보니, 매우 긴~ 글이 되고 말았습니다. 여기까지 읽어주셔서 너무도 감사드립니다. 의문 사항이 있거나 잘못된 내용이 있다면 언제든지 관심어린 지적을 부탁드립니다.