태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

2011/05/20 00:31 by davideung
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


다시 오랜만에 돌아왔습니다. 실무를 하면서, 아니 실무를 하니 일만해서 매번 글을 쓰고 정리하는 것이 어렵네요. 이제 심기 일전하여 차근 차근 정리하는 마음으로 글을 올려보도록 하겠습니다. 전규현님도 바쁘셔서 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

감사합니다.  

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

'인증' 카테고리의 다른 글

2011 정보보호제품 평가 인증 컨퍼런스 메모  (0) 2011/05/20
변경된 CC 평가 인증 제도  (2) 2010/05/03
인증을 꼭 받아야 하나요?  (4) 2008/11/06

davideung 인증 CC, 컨퍼런스

Trackback Address: http://allofsoftware.net/trackback/221 관련글 쓰기

변경된 CC 평가 인증 제도

2010/05/03 23:18 by davideung
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
안녕하세요, 다시 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)에 가입하는 노력이 허사로 돌아가지 않고 국내 제품들이 계속적으로 글로벌하게 해외 시장에 진출하는데 있어 일관된 기준이 적용되어야 경쟁력이 쌓이지 않을까 합니다.

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


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

'인증' 카테고리의 다른 글

2011 정보보호제품 평가 인증 컨퍼런스 메모  (0) 2011/05/20
변경된 CC 평가 인증 제도  (2) 2010/05/03
인증을 꼭 받아야 하나요?  (4) 2008/11/06

davideung 인증 CC, 인증, 제도, 컨퍼런스, 평가, 품질

Trackback Address: http://allofsoftware.net/trackback/186 관련글 쓰기
  1. 2010/05/04 12:11
    다윗의 생각 Tracked from davideung's me2DAY
  1. Blog Icon
    paeng

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

  2. 잘읽고 갑니다.~

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..

우리 식대로
우리 식대로 2011/10/30

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..