태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

2011 정보보호제품 평가 인증 컨퍼런스 메모

2011.05.20 00:31 by 비회원


잠시 후 Google blogger로 이동됩니다.




다시 오랜만에 돌아왔습니다. 실무를 하면서, 아니 실무를 하니 일만해서 매번 글을 쓰고 정리하는 것이 어렵네요. 이제 심기 일전하여 차근 차근 정리하는 마음으로 글을 올려보도록 하겠습니다. 전규현님도 바쁘셔서 5월 들어 글을 못 올리고 계신 것 같은데 이 틈을 타서 해볼까 합니다. 대강 틀을 잡기는 했는데 정리가 다 된 글 보다는 전체 틀로서 '평가 준비 - 진행 - 완료 사후관리' 라는 순서로 올리려 합니다. 매번 공수표만 올려서 송구스럽습니다. 


오늘은 오늘 있었던 평가 인증 컨퍼런스를 참석하면 들었던 세션 중심으로 메모한 것을 정리하였습니다. 일반적인 내용보다는 참고할 만한 내용 중심으로 정리하였습니다. 

    평가인증제도

행사전에는 "변경된 제도"라고 했었던 것 같은데 (그래서 뭐가 변경이 있을 줄 알았습니다) 발표 내용으로는 크게 달라진 내용이 없었습니다. 그래서 못 봤는지 지금 보니 2012년에 PMS가 국내용 CC인증 대상에 추가된다고 장표에 있습니다. 

PP와 더불어 (요즘은 PP를 만들지 않고 있습니다) G-SFR이라는 이름으로 제품군별로 기능요구사항 문서를 만들어 배포하고 있고 이는 "지식정보보안산업협회(KISIA)"에서 책자로 받을 수 있다고 합니다. 아직 PP가 1.0 (CC 버전 2.3) 이 있는데 이는 SFR 만 참고하면 되겠습니다. 

이제 총 제품군이 25개 입니다. 이 제품군은 모두 CC인증 대상이고 추가적으로 2012년에 PMS도 추가하겠다는 것 같습니다. 

뭔가 제도 개선 사항이 있었는데 아직 발표할 때가 아닌지 아니면 안하기로 했는지 빠진 느낌입니다.


    보안관리의 기본과 원칙

발표자가 JS시큐리티 박태완대표이셨습니다. JS 시큐리티에 들어보신분 계십니까? 저는 처음 들었습니다. 바로 홈페이지 등을 찾아보았는데 오늘 발표하신 대표님은 보안 컨설팅, 교육으로 검색 결과가 몇개 나왔는데 회사 홈피는 못찾았습니다. 발표 자료도 책에 없으니 더 신기합니다.

보안 컨설팅에 대한 전반적인 이야기를 했습니다. 아직도 보안 컨설팅 이야기는 웃깁니다. 3년마다 컨설팅이 반복되고 재투자되고 있지만 항상 똑같다는 이야기입니다.

의미 있었던 이야기로 회사의 보안 점수는 여러 분야별로 점수를 매겨 보았을 때 평균이 아니라 낮은 점수로 해야 한다고 합니다. 맞는 이야기 같습니다. 
 

    모의제품, 제출물을 활용한 평가준비 편의성 제고

모의 제품 소개가 있었습니다. 아마도 제출물작성교육이나 평가인증교육 때 이를 가지고 하나봅니다. 현재 KISA 홈페이지 "개발자를 위한 도우미"에도 없는 것 같습니다. (추후에 교육 부분만 따로 정리를 해보겠습니다. 모의 제품으로 평가 제출물도 이미 되어 있어서 교육 때 활용이 될 것 같습니다.  

2011년에 제출물 작성 교육은 6월 20-24일, 12월 5-9일(예정)이 있고 평가 인증 교육은 다음주 23일-6월3일이 있고 2차는 미정이라고 합니다. 


    CC인증 제품과 암호모듈간의 평가 관계

공공기관에 도입되기 위해서는 검증필 암호모듈을 탑재하여 (VPN 같은 경우) CC인증을 받거나 보안적합성 제도를 통해 들어갑니다. 그런데 여기에 "암호지정"이 빠졌습니다. 공공기관에 도입될 수 있는 경우로 국정원이 지정한 암호 제품(PKI, SSO, 디스크/파일 암호화, DRM, 메일 암호화, 키보드 암호화, 하드웨어 보안 토큰, DB 암호화, 기타 암호화 전문)에 대해서 암호 지정을 받으면 됩니다. 국가사이버안전센터 => IT보안인증사무국 => 암호제품지정 참고

국외 동향으로 CC인증과 연계 하여 암호 모듈을 가지고 가려고 했으나 (암호 모듈을 꼭 탑재하여 CC인증) 미국, 일본, 캐나다를 중심으로 이를 분리하려 한다는 소식입니다. 

암호 검증 모듈의 유효기간은 5년이라고 합니다. 검증 받은 암호 모듈의 해시가 같아야 CC인증 할 수 있다고 하네요.

암호모듈 제출물설명회가 담주 26일 오후 3시 교육문화회관 금강 A홀에서 있다고 합니다. 


    보안업체를 위한 소프트웨어 테스팅 프로세스 

발표는 STA의 권영일대표(광운대 교수)께서 하셨습니다. 역시 발표를 대단히 잘 하십니다. 발표의 범위와 목적을 정확히 집고 넘어가고 시작 전에 시선을 끄는 작업이 매우 탁월 하십니다. 경력에 의한 포스가 느껴지십니다. 이분은 개인적으로 발표 후에 여러 사람에 둘려 싸여 질문 토론 답변 하는 모습이 매우 인상적이었습니다. 아직까지 열정이 느껴집니다. 

평가하는 모델 TMMi 가 있습니다. 모든 소프트웨어 속에 결국 CC인증 보안성 시험도 비슷 동일하군요. 우리는 평가 준비를 위한 시험을 어떻게 하고 있나요? 인증서를 위해서 우선 평가에 들어가기에 급급한 실정입니다. 테스팅 프로세스 평가하는 TMMi ISO33063는 한국이 주도하고 있다고 합니다. 

여러 시험 방법이 있는데 그 중 보안성 시험 (CC인증 시험) 이 있고 이는 일반 소프트웨어 시험과 크게 다르지 않다는 설명이십니다. 그래서 생각했습니다. 일반 시험 프로세스와 비슷 동일한데 별도의 짧게라도 프로세스나 방법이 있어야 하지 않을까 합니다. 

그리고 리스크기반 시험: 전세계 표준이라고 합니다. 오늘 소개해주신 TPAM 에 Security Test Management 영역이 따로 있습니다. 

비기능 시험은 성능, 신뢰성, 확장성, "보안" 시험이고 이 또한 추세라고 합니다.

이 세션을 마치면서 생각이 많아 졌습니다. 시험을 꼭 QA와 통합해서 할 필요는 없구나 CC인증 대상에 대해서 보안성 시험을 하면 되고 (CC인증 준비) 이를 확장하고 일반화 하여 프로세스를 만들 필요가 있겠다 생각이 들었습니다. 그런 측면으로 CC인증 개발 단계 부터 평가 준비 프로세스를 다시 한번 그려보고 정비해 봐야겠습니다. 


    동적 분석 기반 소프트웨어 보안 취약성 분석 연구 동향

동적이라는 것은 "실행"이라는 의미입니다. 소스 분석은 대표적인 정적 분석인데 반해 동적 분석은 실행 중인 소프트웨어를 공격자 입장에서 여러 시험 (침투 등)을 하는 것입니다. 

핵심 용어만 메모했습니다: 
실행, 비기능 시험, security testing, nagative, 공격, buildsecurityin.us-cert.gov, 위협, 위험, 위협 모델링(MS STRIDE model), fuzzing, symbolic execution

감사합니다.  

저작자 표시 비영리 변경 금지
신고

비회원 인증 CC, 컨퍼런스

변경된 CC 평가 인증 제도

2010.05.03 23:18 by 비회원


잠시 후 Google blogger로 이동됩니다.



안녕하세요, 다시 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)에 가입하는 노력이 허사로 돌아가지 않고 국내 제품들이 계속적으로 글로벌하게 해외 시장에 진출하는데 있어 일관된 기준이 적용되어야 경쟁력이 쌓이지 않을까 합니다.

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


저작자 표시 비영리 변경 금지
신고

비회원 인증 CC, 인증, 제도, 컨퍼런스, 평가, 품질

  1. Blog Icon
    paeng

    글 감사합니다. ^^ 즐거운 하루 되세용~

  2. 잘읽고 갑니다.~

인증을 꼭 받아야 하나요?

2008.11.06 18:12 by 비회원


잠시 후 Google blogger로 이동됩니다.



처음 글을 올리면서 인사드립니다.^^/

이렇게 글을 쓸 수 있도록 팀블로그로 지면을 만들어주셔서 감사합니다. '인증'이라는 주제만으로는 큰 의미 혹은 필요성 없었겠지만 이렇게 '소프트웨어 개발' 이라는 주제와 함께 지식과 경험을 나눈다면 그것은 시너지 효과처럼 좋은 결과를 만들어 내리라는 확신에 잘 쓰지 못하는 글을 시작하게 되었습니다. 왜냐하면 어자피 인증이라는 것은 "잘" 개발된 소프트웨어를 정말로 "잘" 개발했는지를 평가하고 인증을 하는 것이기 때문입니다.

이러한 주제로 얼마나 많이 이야기하고 또 깊이 들어갈지는 지금으로서는 가늠하기가 어렵습니다. 글을 읽어 보시는데로 어떠한 것도 좋으니 피드백해주시고 가이드해주시면 더욱 열심히 글을 포스팅하겠습니다. 특별이 여기에서는 많은 '인증' 중에서도 'CC인증[각주:1]'이라는 것에 대해서 다루려 합니다.

오늘 처음으로 함께 생각해보고자 하는 것은 그 'CC인증'의 필요성입니다. 많은 회사에서 인증을 받아야 한다고 하면 반응이 거의 똑 같습니다. "왜 해야하느냐" 혹은 "꼭 해야하느냐"는 반응입니다. 물론 그도 그럴 것이 모두 적지 않은 비용이 들기 때문이죠. 하지 않았던 것을 해야 하니까요. 그렇지 않습니까? 모든 일은 하지 않으면 가장 좋죠^^.

그런데 인증, 특별히 CC인증의 그 안을 들여다 보면 소프트웨어를 잘 만들자라는 공학적인 개념과 너무도 흡사하고 또 철학적 기반이 그렇다고 말합니다. 즉, CC인증의 '보증적 패러다임'은 소프트웨어 공학적 학문에서 나온 것입니다.

그렇기 때문에 소프트웨어를 잘만드는 것과 CC인증을 받는 것은 '기차길'과 같이 나란히 달립니다. 아! 물론 이 개념이 현실적으로 사람의 하는일로 되었을 때 많은 괴리감과 차이점을 발생시키는 것은 당연합니다. 아무튼 그 시작의 의도는 그렇다는 것입니다. 그러니까 우리가 생각만 바꾸어 보면, 개발 조직이 소프트웨어 공학적인 접근으로 결함 없는 소프트웨어를 만들기위해 노력하고 있다면 그만큼 CC인증이라는 것도 쉽다는 것을 말하려는 것입니다.

소프트웨어 공학이라는 것이 소프트웨어를 잘 만들기 위해 1) 소프트웨어 개발 프로세스(요구명세-설계-시험-배포-유지보수)를 구분하고 이를 모델링하는 개발 방법론과 2) 이를 지원해 줄 형상관리, 문서화, 품질 품질 보증, 프로젝트 관리와 같은 관리 방법론으로 생각해 본다면, 이 모든 접근이 그대로 CC인증에서 소프트웨어의 보안성을 평가하기 위한 보증 방법론과 매칭이 된다는 점입니다.

거기에 CC인증이 중요시 생각하고 있는 점을 추가하라고 한다면 바로 '취약성'입니다. 취약성은 나중에 따로 보도록 하고 CC인증에서 말하고 있는 보증의 패러다임에 대해서 계속 살펴보겠습니다.

공통평가기준의 철학은 보안에 대한 위협과 조직의 보안정책을 명확하게 표현하고, 제안된 보안수단이 본래 의도된 목적을 만족히키는데 충분함을 입증하는 것이다. - 정보보호시스템 공통평가기준(CC인증) 3부: 보증 요구사항 2007. 9 Version 3.1 개정2판 (CCMB-2007009-003)의 19단락

즉, 'CC인증'이라는 것이 결국은 개발 조직이 정의한 개발 방법론 대로 '안전하게' 개발을 하고 있으며 또 개발 조직이 정의한 제품의 위협과 그 제품이 쓰일 곳의 보안정책이 개발한 제품에서 제공하는 보안 수단(기능)에 모두 대응하는지(충분성)를 평가자의 '능동적인 조사'에 의해서 보증되는 것입니다.

보증은 신뢰의 기초가 된다고 합니다. 그렇기 때문에 평가자의 능동적인 조사를 통해 보증을 제공한다고 합니다(CC인증). 그래서 평가를 통해서 보증을 얻는데 요약하면 1) 제품과 문서(설계), 2) 생명주기에 따른 신뢰성을 평가하면서 이루어지는 것입니다. 

그러니까 거꾸로 개발 조직에서 생각해볼 때 결함 없는 (보안제품이기 때문에 그것이 곧 보안성) 제품과 설계를 하고(위 소프트웨어 공학 측면의 1)번) 그리고 잘 개발되도록 지원하는 관리 방법론이 신뢰성(예를 들어 형상관리를 안전하게 잘 한다)이 있다면(위 소프트웨어 공학 측면의 2)번) CC인증은 하고 있는 그대로를 평가 받으면 되는 작업이 되는 것입니다.

자, 그러면 CC인증이 너무도 소프트웨어 개발과 동 떨어진 - 단지 제품을 하나라도 '더' 파는데 있어서 불필요한 요구 조건만은 아닌 것을 결론으로 내려도 될까요? - 소프트웨어 공학처럼 개발에 필요한 여러 요소들을 담고 있다는 것만 인지한다면 조금은 다르게 봐 줄 수 있지 않나 합니다.

마지막으로, CC인증 3부:보증요구사항에 나오는 '보증 패러다임'의 무엇을 가지고 '평가를 통한 보증'을 하는지 책을 표보시는 것으로 마무리하겠습니다. (이런 것들을 평가한다고 합니다) - 정보보호시스템 공통평가기준(CC인증) 3부: 보증 요구사항 2007. 9 Version 3.1 개정2판 (CCMB-2007009-003)의 6.2.4절

평가는 보증을 얻는 전통적인 방법이며 공통평가기준에 의한 방법론의 기초가 된다. 평가방법은 다음을 포함하지만 이에 국한되지는 않는다.
  1. 프로세스와 절차의 분석 및 검사
  2. 프로세스와 절차가 적용되고 있음을 검사
  3. TOE[각주:2] 설계 표현간의 일치성 분석
  4. 요구사항에 대한 TOE 설계 표현의 분석
  5. 증거의 검증
  6. 설명서 분석
  7. 개발된 기능 시험 및 제공된 결과 분석
  8. 독립적인 기능 시험
  9. (결함 가정을 포함한) 취약성 분석
  10. 침투 시험




 

  1. CC라는 "공통평가기준"을 사용하여 인증을 획득하는 일련의 작업.

공통평가기준(CC: Common Criteria) - IT제품의 보안 기능성과 평가 과정에서 그 제품들에 적용되는 보증수단에 대한 공통의 요구사항들을 제시함으로써, 독립적으로 수행된 보안성 평가의 결과들을 비교할 수 있도록 한다.




 [본문으로]
  2. 평가 대상(TOE: Target of Evaluation) - 기능한 설명서가 수반되는 소프트웨어, 펌웨어 및/또는 하드웨어 집합 (공통평가기준 1부 용어정의)


 [본문으로]
신고

비회원 인증

  1. 회사에서 CC 인증을 추진 중에 있습니다. 얼마 전에 '수습 평가사' 자격증까지 땄지만 아는 것보다 모르는 것이 훨씬 많아 걱정이 앞서던 차, 너무 반가운 포스팅입니다. ^^ 앞으로의 좋은 글에 미리 감사 말씀 드리고 싶습니다. 자주 찾아뵙고 싶은 블로그입니다. ^^

  2. 감사합니다. 저도 얼마전 교육을 받았는데, 같이 받으신듯 합니다. 아마 얼굴을 뵈면 알것 같은데요, 반갑습니다^^. 자주 방문해주시고 많은 조언 부탁드립니다.

  3. 글을 보니 꽤 깔끔한 성격이신 듯합니다.

    CC인증을 실제로 작업해보니, 현실과 괴리감을 느낄 때가 있습니다. 레이님 말씀대로 CC란 것도 소프트웨어 공학에서 IT 제품 자체와 개발환경에 요구하는 보안 측면을 다루는 것으로 생각하면 되겠습니다. 공감합니다. 문제가 있다면, CC에 따라 문서를 작성하는데는 어느정도 스킬이 필요하다는게 아닐까 싶습니다.

    얼마전에 평가자에게 물어본 게 있습니다. 외국에서도 CC 인증을 취득할 때 실제 개발 문서를 CC에서 요구하는 형태로 변환해서 제출하느냐는 것이죠. 외국에서도 그렇게 한다는 군요. 좀 좌절이었습니다. -_-;a 결국 그렇게 문서를 컨버팅(혹은 포팅?)하는 과정이 오버헤드로 발생하는 셈이라서 개발자 측면에서 좀 불합리합니다. 올해 제주에서 있었던 9차 ICCC에서도 평가기관측과 개발자 측 사이에 격렬한 논쟁이 벌어진 세션이 있었다고 하죠. (그 세션에 저는 없었기에 실제로 어땠는지는 모르겠습니다.)

    CC가 어느 정도 보편화되고 안정단계에 접어드려면, 개발자가 (문서를 변환하는 작업으로) 부담해야 하는 부하가 좀 줄어야 할 것 같습니다.

  4. 안녕하세요, DAVIDEUNG입니다. 이렇게 찾아와 주셔서 감사합니다. nulonge 하신 말씀이 아주 아주 동감합니다. 참 그리고 nulonge님의 블로그에서도 CC인증 관련 글 잘 읽고 있습니다^^.

    그렇죠, 맞습니다. 괴리감이 심해도 너무도 심하죠. 그리고 말씀하신 격렬한 토론이 아마도 CC version 4.0에서는 개발업체의 개발문서를 그대로 CC인증 받도록 해야 하느는 것을 들었습니다. 그래서 국내의 관련 업체들도 반기는 분위기였다고 합니다. 그러나 다시 생각해보면 이것은 '인증'이고 '평가'입니다. '보증'을 한다는 것이 아마도 플러스+해야하는(변경작업해야하는) 어떤 요소가 아닌가 합니다.

    그리고 그 괴리감이 완전 없어져서 아무리 개발문서를 바로 쓰게 해준다고 하더라도 또 하나의 기준이 생길 것입니다. 그러면 "개발문서의 표준은 뭐냐"로 시작할테니 말이죠. 그러나 평가 보고서를 위한 문서화는 줄 수 있겠죠. 이런 부분은 기대가 됩니다. 그리고 자연스럽게 개발자의 문서가 퀄러티가 높아진다면 더 좋은 방향일 것입니다.

    아무튼 앞으로도 개발 업체로서는 이 문제가 논의의 중심이 될것 같습니다. nulonge님의 좋은 의견도 부탁드리고 좋은글도 기대하겠습니다. 경험을 통해서 얻은 지식을 많이 나누어주세요. 감사합니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바