인증을 꼭 받아야 하나요?
RSS Feed
이렇게 글을 쓸 수 있도록 팀블로그로 지면을 만들어주셔서 감사합니다. '인증'이라는 주제만으로는 큰 의미 혹은 필요성 없었겠지만 이렇게 '소프트웨어 개발' 이라는 주제와 함께 지식과 경험을 나눈다면 그것은 시너지 효과처럼 좋은 결과를 만들어 내리라는 확신에 잘 쓰지 못하는 글을 시작하게 되었습니다. 왜냐하면 어자피 인증이라는 것은 "잘" 개발된 소프트웨어를 정말로 "잘" 개발했는지를 평가하고 인증을 하는 것이기 때문입니다.
이러한 주제로 얼마나 많이 이야기하고 또 깊이 들어갈지는 지금으로서는 가늠하기가 어렵습니다. 글을 읽어 보시는데로 어떠한 것도 좋으니 피드백해주시고 가이드해주시면 더욱 열심히 글을 포스팅하겠습니다. 특별이 여기에서는 많은 '인증' 중에서도 'CC인증1'이라는 것에 대해서 다루려 합니다.
오늘 처음으로 함께 생각해보고자 하는 것은 그 '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인증 3부:보증요구사항에 나오는 '보증 패러다임'의 무엇을 가지고 '평가를 통한 보증'을 하는지 책을 표보시는 것으로 마무리하겠습니다. (이런 것들을 평가한다고 합니다) - 정보보호시스템 공통평가기준(CC인증) 3부: 보증 요구사항 2007. 9 Version 3.1 개정2판 (CCMB-2007009-003)의 6.2.4절
평가는 보증을 얻는 전통적인 방법이며 공통평가기준에 의한 방법론의 기초가 된다. 평가방법은 다음을 포함하지만 이에 국한되지는 않는다.
- 프로세스와 절차의 분석 및 검사
- 프로세스와 절차가 적용되고 있음을 검사
- TOE2 설계 표현간의 일치성 분석
- 요구사항에 대한 TOE 설계 표현의 분석
- 증거의 검증
- 설명서 분석
- 개발된 기능 시험 및 제공된 결과 분석
- 독립적인 기능 시험
- (결함 가정을 포함한) 취약성 분석
- 침투 시험
'인증' 카테고리의 다른 글
| 2011 정보보호제품 평가 인증 컨퍼런스 메모 (0) | 2011/05/20 |
|---|---|
| 변경된 CC 평가 인증 제도 (2) | 2010/05/03 |
| 인증을 꼭 받아야 하나요? (4) | 2008/11/06 |
회사에서 CC 인증을 추진 중에 있습니다. 얼마 전에 '수습 평가사' 자격증까지 땄지만 아는 것보다 모르는 것이 훨씬 많아 걱정이 앞서던 차, 너무 반가운 포스팅입니다. ^^ 앞으로의 좋은 글에 미리 감사 말씀 드리고 싶습니다. 자주 찾아뵙고 싶은 블로그입니다. ^^
감사합니다. 저도 얼마전 교육을 받았는데, 같이 받으신듯 합니다. 아마 얼굴을 뵈면 알것 같은데요, 반갑습니다^^. 자주 방문해주시고 많은 조언 부탁드립니다.
글을 보니 꽤 깔끔한 성격이신 듯합니다.
CC인증을 실제로 작업해보니, 현실과 괴리감을 느낄 때가 있습니다. 레이님 말씀대로 CC란 것도 소프트웨어 공학에서 IT 제품 자체와 개발환경에 요구하는 보안 측면을 다루는 것으로 생각하면 되겠습니다. 공감합니다. 문제가 있다면, CC에 따라 문서를 작성하는데는 어느정도 스킬이 필요하다는게 아닐까 싶습니다.
얼마전에 평가자에게 물어본 게 있습니다. 외국에서도 CC 인증을 취득할 때 실제 개발 문서를 CC에서 요구하는 형태로 변환해서 제출하느냐는 것이죠. 외국에서도 그렇게 한다는 군요. 좀 좌절이었습니다. -_-;a 결국 그렇게 문서를 컨버팅(혹은 포팅?)하는 과정이 오버헤드로 발생하는 셈이라서 개발자 측면에서 좀 불합리합니다. 올해 제주에서 있었던 9차 ICCC에서도 평가기관측과 개발자 측 사이에 격렬한 논쟁이 벌어진 세션이 있었다고 하죠. (그 세션에 저는 없었기에 실제로 어땠는지는 모르겠습니다.)
CC가 어느 정도 보편화되고 안정단계에 접어드려면, 개발자가 (문서를 변환하는 작업으로) 부담해야 하는 부하가 좀 줄어야 할 것 같습니다.
안녕하세요, DAVIDEUNG입니다. 이렇게 찾아와 주셔서 감사합니다. nulonge 하신 말씀이 아주 아주 동감합니다. 참 그리고 nulonge님의 블로그에서도 CC인증 관련 글 잘 읽고 있습니다^^.
그렇죠, 맞습니다. 괴리감이 심해도 너무도 심하죠. 그리고 말씀하신 격렬한 토론이 아마도 CC version 4.0에서는 개발업체의 개발문서를 그대로 CC인증 받도록 해야 하느는 것을 들었습니다. 그래서 국내의 관련 업체들도 반기는 분위기였다고 합니다. 그러나 다시 생각해보면 이것은 '인증'이고 '평가'입니다. '보증'을 한다는 것이 아마도 플러스+해야하는(변경작업해야하는) 어떤 요소가 아닌가 합니다.
그리고 그 괴리감이 완전 없어져서 아무리 개발문서를 바로 쓰게 해준다고 하더라도 또 하나의 기준이 생길 것입니다. 그러면 "개발문서의 표준은 뭐냐"로 시작할테니 말이죠. 그러나 평가 보고서를 위한 문서화는 줄 수 있겠죠. 이런 부분은 기대가 됩니다. 그리고 자연스럽게 개발자의 문서가 퀄러티가 높아진다면 더 좋은 방향일 것입니다.
아무튼 앞으로도 개발 업체로서는 이 문제가 논의의 중심이 될것 같습니다. nulonge님의 좋은 의견도 부탁드리고 좋은글도 기대하겠습니다. 경험을 통해서 얻은 지식을 많이 나누어주세요. 감사합니다.