인증을 꼭 받아야 하나요?

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

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

이러한 주제로 얼마나 많이 이야기하고 또 깊이 들어갈지는 지금으로서는 가늠하기가 어렵습니다. 글을 읽어 보시는데로 어떠한 것도 좋으니 피드백해주시고 가이드해주시면 더욱 열심히 글을 포스팅하겠습니다. 특별이 여기에서는 많은 '인증' 중에서도 '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부 용어정의) [본문으로]