블로그 이미지

my hiding place

삶이 힘들 때, 조금이라도 고개를 들고 위를 보세요. 푸른 하늘이 당신을 맞이해줄 날이 있을 테니까. by nulonge


'CC인증'에 해당되는 글 17건

  1. 2009.11.10 CC인증 일 하실 분? - 시큐위즈
  2. 2009.09.03 '인증 연속성: CCRA 요구사항'에 따른 재평가 & 변경승인 기준
  3. 2009.08.26 AhnLab Suhoshin Absolute v2.5 인증효력 정지(4)
  4. 2009.06.04 변경되는 정보보호제품 도입 절차
  5. 2009.05.05 CC에서 요구사항 추적이 반드시 필요할까?
  6. 2009.04.22 너무나 잘 씌여진 보안목표명세서
  7. 2009.04.22 CC 인증에서 사용되는 중요한 키워드들 - 2
  8. 2009.04.03 CC2.3 기반 개발 문서를 CC3.1로 변환할 때 참고할 자료
  9. 2009.03.25 CC 인증에서 사용되는 중요한 키워드들 - 1
  10. 2009.03.18 CC 인증을 추진하기 전에 생각해볼 것들(2)
  11. 2009.03.06 CISSP 시험에서 출제된 CC 인증 문제(1)
  12. 2009.01.22 CC 인증효력유지 평가를 받다가 생긴 일(8)
  13. 2008.12.20 IE 0-Day 취약성과 AtiveX, 그리고 CC 인증
  14. 2008.12.04 어울림정보기술, 통합보안제품 2종 CC인증 획득
  15. 2008.11.28 비평가 대상 VS 비보안 기능
  16. 2008.09.15 CC 인증 보안성 평가의 범위(2)
  17. 2008.08.22 CC 인증(IT 제품의 보안성 평가 기준)의 개요(9)

CC인증 일 하실 분? - 시큐위즈


시큐위즈에서 CC인증 인력을 채용한다고 합니다.
관심있는 분은 연락 부탁드립니다.

이왕이면 제가 아는 분이면 좋겠네요.
Comment 0 Trackback 0
Top

'인증 연속성: CCRA 요구사항'에 따른 재평가 & 변경승인 기준

변경승인이 허용되는 TOE의 변경은 다음과 같습니다.

  • 인증된 TOE의 변경없이 IT 환경이 변경되는 경우: 하드웨어 플랫폼 추가, 운영환경 라이브러리의 변경 (예: openSSH, openSSL 버전 업그레이드)
  • 인증된 TOE 변경이 보증 증거물에 영향을 주지 않는 경우: 이런 케이스는 거의 없을 것 같습니다. "EAL1으로 인증 받은 제품의 소스 수준 변경은 보증 증거물에 영향을 미치지는 않는다."는 점을 들 수 있겠네요.
  • 보증 증거물의 편집상 변경: 문서의 오타, 탈자 교정, 템플릿 변경 등이 해당합니다.
  • 소스 코드의 비실행문에 대한 변경: 그러나 EAL4와 같이 ALC_TAT가 선언된 경우, 컴파일러 명령어 변경은 주요 변경에 속하므로 재평가 대상이 됩니다.
  • 보증에 현저한 영향을 주지 않는 개발환경 변경: 형상관리 도구의 변경 등은 TOE의 보안 기능성에 전혀 영향을 줄 수 없겠지요?
  • 보안목표명세서의 표제어(frontmatter) 변경: 보안목표명세서의 식별정보, TOE 식별자에 대한 변경 등을 말합니다. 보안기능요구사항의 변경이 요구되지 않는 범위내에서 조직의 보안정책, 가정사항, 보안목적의 변경도 허용됩니다. 요구사항 서술의 변경은 주요변경이므로 재평가가 필요하다.

전형적인 주요변경 사항으로, 재평가를 거쳐 새로 인증서를 받아야 하는 변경은 다음과 같습니다.

  • 선언된 보증요구사항(SAR)의 변경
  • 선언된 기능요구사항(SFR)의 변경: TOE의 경계를 변경하는 것일 수 있으므로 그렇답니다. 만약에, 기존에 서술된 것보다 더 제한적인 기능을 요구하는 것이라면 변경승인이 가능하지 않을까요?
  • 최초 평가에서 심사되지 않은 절차의 사용: 새로운 배포 절차등을 도입하여 사용한다면 보안에 영향을 줄 수 있기 때문에(TOE의 형상이 바뀌거나 영향을 받을 수 있다는 의미) 그렇지요. 이런 케이스도 별로 없을 것 같습니다.
  • 함께 결합하면 보안에 주요 영향을 미치는 경미한 변경들: 경미한 변경이더라도 누적되면 큰 변화를 가져올 수 있기 때문에 누적된 보안 영향이 크다고 간주되면 재평가가 필요합니다.

버그 수정은 변경승인 대상이 될 수도, 재평가 대상이 될 수도 있습니다. 인증 효력 유지방법을 정말 모르겠다면, 국가정보원 IT보안인증사무국에 보안영향분석서를 작성해서 제출하면 답을 줄겁니다.
Comment 0 Trackback 0
Top

AhnLab Suhoshin Absolute v2.5 인증효력 정지


안랩 네트워크 제품군중 하나가 인증 효력을 정지당했습니다.

Comment 4 Trackback 0
  1. 떠돌이 2009.08.26 09:33 신고 address edit & delete reply

    자세한 내막에 대해서는 잘 모르지만은 새로운 취약점이 발견 되었지만 안랩에서는 하루 빨리 패치를 하지 않아서 보안 위협에 노출 되어 있어서 그런건 아닌가 생각 해 봅니다... 또한 보안제품의 취약점은 다양한 위협을 방어 하는 장비로써의 기능을 무력하게 할 수있기 때문에 중요할 것 같은데요..

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2009.08.26 10:01 신고 address edit & delete

      이미 패치된 펌웨어는 한달전에 나왔지요. 그리고 관리자 계정을 유출당하지 않았다면 악용할 수 없는 취약성이죠. 새로운 취약성은 아닙니다. 정상적인 기능이지만, 방화벽이라는 특성상 우회 통로로 악용될 우려가 있습니다.

      문제는, 관리자 계정을 알고 있어야 이용할 수 있다는 것인데, 이미 관리자 계정을 유출당했다면야, 이미 방화벽을 모두 장악한 것일겁니다.

  2. 떠돌이 2009.08.26 15:16 신고 address edit & delete reply

    한달전에 패치 되었음에도 불구하고 국정원 아저씨들은 왜 인정을 하지 않고 효력을 정지 해 버렸는지 의문이군요.. 솔직히 이게 우리 회사 방화벽 비밀번호요 하고 일부러 알려주지 않는 이상 다른 사람이 알기도 힘들 뿐더러 님의 말대로 이미 뚫렸다면 안랩 뿐만 아니라 카스퍼스키,노턴,맥아피등 쟁쟁한 회사의 제품들도 무기력 해 지는 건 마찬가지 아닐까 생각합니다.. 또 다른 방법이라면 해킹이나 기타 방법으로 감염 되어서 유출된 경우인데 사실 이 경우는 힘든 방법이겠죠..

    안랩 기업용 제품 담당 직원 분이시었군요..^^
    개인적으로는 365 쓰는 데 V3가 언젠가는 타 공룡회사들과 어깨를 나란히 할 수 있기를 바랄께요.. 화이팅!!

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2009.08.26 15:22 신고 address edit & delete

      사건사고 이야기는 그만할게요.

      제가 아는 떠돌이님은 리눅스 매니아.
      V3 365를 쓰신다니 참 고맙습니다. ㅎㅎㅎ
      (저에게 월급 주시는 분이군요? ㅋㅋㅋ)

Top

변경되는 정보보호제품 도입 절차

요즘 국가/공공기관에 정보보호제품을 공급할 때 필요한 인증 제도에 변화가 있어서 간단하게 정리해봅니다. 국가/공공기관에 제품을 공급할 때 적용되는 인증 제도로는 다음과 같은 것들이 있습니다. (클릭하면 IT보안인증사무국에서 각 항목을 설명하는 페이지로 이동합니다)

언뜻 보면 뭐가 뭔지 헷갈리고 이해하기 어렵습니다. 간단히 몇가지만 추려보면 다음과 같습니다.

  1. 검증필 제품 목록 제도 폐지 이전에 있던 '검증필 제품 목록'이 2009년 6월 1일부로 폐지되었습니다. 이에 따라 효력이 사라지는 제품들은 올해말까지 CC 인증 계약을 완료해야 합니다. 아직은 검증필 제품중에서 CC 인증을 취득한 제품이 없기 때문에, 국가/공공기관은 한시적으로 올해 말까지 CC 평가계약을 체결한 제품에 한해 도입이 허용됩니다. 그렇지 않으면, 2009년 12월 31일 이후 국가/공공기관 도입대상 제품에서 제외됩니다.
  2. 공공기관용 네트워크/컴퓨팅기반 제품의 CC 인증 획득 의무화 공공기관에 도입하는 모든 네트워크 기반 제품 및 컴퓨팅기반 제품은 EAL2 이상의 CC인증을 취득할 것을 원칙으로 합니다. (보호프로파일(PP)이 있다면, 보호 프로파일을 준수할 것이 적극 권장됩니다.)
  3. 암호 검증 암호 제품이 아닌 암호 모듈을 평가하는 제도입니다. CC 인증을 취득해야 하는 네트워크기반 제품인 VPN 제품군이나, 보안 USB 제품과 같이 행정정보의 유통/저장 용도로 도입되는 제품에 대해서 암호 검증은 의무사항입니다.
    • 다시 말해서, VPN 제품군이나 보안 USB 제품은 검증필 암호모듈을 탑재해야 합니다.
    • 검증필 암호모듈을 탑재한 제품은 우리나라의 평가 스킴에서 정한 절차에 따라 CC 인증(변경 승인) 평가를 받아야 합니다.
    • 예외사항으로, 저장자료 완전 삭제 제품이나 모바일기기 보안제품은 CC인증 또는 국가용 암호제품 지정제도의 적용을 받지 않습니다.
  4. 국가용 암호제품 지정제도 암호기반 제품은 국가용 암호제품 지정제도에 따라 검증을 받아야 합니다. 국가용 암호제품 지정제도는 검증필 암호모듈을 의무적으로 탑재해야 합니다.
    • 대상 제품군: PKI 제품, SSO 제품, 디스크/파일/문서 암호화 제품, 구간 암호화 제품(인터넷 뱅킹을 이용할 때 사용되는 통신 암호화 제품), 메일 암호화 제품, 키보드 암호화 제품, 하드웨어 보안 토큰 등
  5. 보안적합성 검증 CC 인증 또는 국가용 암호제품 지정제도에 따라 검증된 제품을 도입한 국가/공공기관은 검수 후 15일 이내에 국가정보원장에게 보안적합성 검증을 신청해야 합니다.[각주:1]

즉, 제품에 따라 먼저 암호 검증을 필한 검증필 (암호화) 모듈을 탑재해야 합니다. 그 다음으로는 CC 인증을 취득하거나, 국가용 암호제품 지정제도에 따라 검증을 받아야 합니다. 그리고, 제품 판매 후, 국가/공공기관에서 이뤄지는 보안적합성 검증을 지원해야 합니다. 이래저래, 보안인증을 담당하는 실무자들은 많이 바빠지겠네요.

정보보호제품 도입 절차


이와 관련된 국가정보원 IT보안인증사무국의 공지사항은 다음 링크를 참조하세요: http://www.kecs.go.kr/bbs/detail_new.jsp?bi=NOTICE&di=406

  1. CC인증 또는 국가용 암호제품 지정제도는 제품의 보안성을 평가하는 것이고, 보안적합성 검증은, 운용 과정에서 잠재적인 보안취약점을 개선하기 위한 검증입니다. 즉, 제품에 대한 보안성을 평가하는 것, 운영 환경 상에서 보안성을 평가하는 것으로 볼 수 있습니다. [본문으로]
Comment 0 Trackback 0
Top

CC에서 요구사항 추적이 반드시 필요할까?

CC인증 취득에 필요한 보증문서를 다룰 때 중요한 요소중 하나는 각종 보증문서의 일치성을 추적하는 일입니다.

그게 무엇이냐 하면, 보안목표명세서에 명세된 보안요구사항 및 보증요구사항으로 개발문서에 기술된 보안기능을 추적하는 겁니다. 평가보증등급(EAL, Evaluation Assurance Level)에 따라 수준의 차이는 있기 마련인데, 보안목표명세서(ST, Security Target)에 제시된 보안기능요구사항(SFRs, Security Functional Requirements)을 기능명세서(FSP, Functional Specification) 수준에서 서브시스템의 외부 인터페이스로, 그리고 TOE 설계서(TDS, TOE Design) 수준에서 서브시스템 또는 모듈 사이에 있는 통신 인터페이스로 추적합니다.

CC 버전 3.1은 인증에 필요한 과도한 문서 작성이 불필요하다는 인식에서 개정된 버전입니다. 그래서 보안목표명세서에 기술된 보안기능요구사항으로 추적해야 하는 기능에 차등을 두었습니다. 이전에는 차등을 둔다는 개념이 없었고, 실제로 개발에 기여하지도 않는 말그대로 CC 인증에서만 사용되는 일치성 분석같은 문서작업이 있었습니다. 개발문서에 일치성 분석 근거가 되는 내용이 분명히 있는데, 이것을 다시 제출해야 해서 원성 높았던 작업이기도 합니다. (이런 저런 이유로, CC 버전 3.1은 일치성분석을 없애고, 대신 CC 인증에서 부족한 점으로 지적된 보안 구조에 대한 문서가 추가됩니다.) CC 버전 3.1 에서 TOE에 속하는 기능과 인터페이스를 다음과 같이 나눕니다.

  • 보안목표명세서에 명세된 보안기능요구사항으로 추적되는 기능, 인터페이스: SFR-수행
  • 보안기능요구사항으로 추적이 되지는 않지만 SFR-수행 기능, 인터페이스가 동작되는데 필요한 기능, 인터페이스: SFR-지원
  • TOE에 속하는 기능, 인터페이스이지만 SFR로 전혀 추적이 되지 않는 기능, 인터페이스: SFR-비간섭

CC 버전 3.1은 평가보증등급에 따라 SFR-수행, SFR-지원, SFR-비간섭 기능 또는 인터페이스 기술 수준을 다르게 가져갑니다. 국내에 CC3.1을 기준으로 등재된 보호프로파일들은 대부분 EAL3, 방화벽에 대해서는 EAL4의 평가보증등급 패키지 준수를 요구합니다. EAL4가 되면, SFR에 따라 외부 인터페이스, 내부 인터페이스 뿐만 아니라 특정 함수수준까지 추적합니다. 매우 힘들고 여려운 작업임에 틀림없습니다. CC 인증을 콕 집어서 이런 어려움을 표현한 것은 아니지만, 드디어 이런 요구사항 추적 무용론까지 나왔습니다. 공감이 갑니다 -_-;a

고해성사를 하자면, 말도 안되는 개발문서를 작성해본 적이 있습니다.[각주:1] 인증에서 요구하는 대로 보안기능요구사항에 따라 모듈 수준까지 추적되는 문서를 작성해야 했기 때문입니다. 제가 작성하던 개발문서는, 인증이 요구하는 요건에는 맞지만, 실제로 개발 현업에서는 사용할 수 없는 문서가 되버렸습니다. 인증 요건에는 맞지만, 사실 이런 문서들은 인증을 받고 나면 다음 인증 업무 때까지 열어보지도 않습니다. 이런 점을 전규현씨께서 제대로 짚어주셨네요. 헐~. ^^;

저는 본래 전산 전공이 아닙니다. 행정학을 전공하다가 경영학을 공부했고, 졸업하면서 전략기획팀에 들어갔지만, 회사에서 필요로 하는 인력은 기술에 가까운 마케팅 인력이어서, 회사의 요구에 맞추다보니 기술문서쪽으로 경력을 확~ 바꿔렸습니다. 네, 저는 전산 인력이 아니기에 약점도 많이 있음을 고백합니다. 프로그램 소스를 보면 다른 사람들보다 몇 갑절 노력이 필요하니까요… 그래도, 업무에 있어서는 전문인으로서 사명감을 갖고 살고자 많이 애쓰고 있습니다.

CC에서 요구사항을 추적하는 이유는, 보안제품이 보안목표명세서에 명세된 보안기능이 서술된 대로 정확히 수행됨을 보장하는데 있습니다. 그 이상도, 그 이하도 아닙니다. 그래서 서브시스템, 모듈 수준에서 어떻게 요구사항을 기술했는지 평가합니다. 참 까다롭지요. 그래서 더욱 더, 개발 프로세스가 갖는 중요성이 마음에 와닿습니다.

저는 어서 CC 버전 4가 나왔으면 좋겠습니다. 버전 4가 나온다고 해서 요구사항 추적이 사라지지는 않을겁니다. 보안성을 평가하려면 반드시 요구사항을 추적해야 하기 때문입니다. 그럼에도, 버전 4는 현업에서 사용되는 개발문서를 평가에 그대로 이용할 수 있게 하자는 취지를 담고 있기에, 평가 준비에 들어가는 부담을 많이 줄여줄 것으로 기대됩니다. 물론, 개발 과정에서 문서화가 제대로 되어 있지 않다면, 버전 4가 나오나, 현재 버전이나, 작업량은 마찬가지겠지만 말입니다.

새 버전이 나오면, 인증 과정이 소프트웨어 공학을 개발 실무에 적용할 수 있는, 유연하고 현실적인 프레임워크가 되었으면 하는 바램을 가져봅니다.
  1. 실제로, CC 인증 업무를 수행하다보면, 개발팀에서 충분한 문서를 제공해주지 않아서 개발문서를 인증 팀이 작성하는 경우가 흔할 겁니다. 개발자들이 당연히 받아야할 문서 작성 교육은 대학에서도 이뤄지지 않는 듯합니다. 그래서 어쩔 수 없이 인증 담당자가 개발문서를 작성하는 상황이 발생합니다. [본문으로]
Comment 0 Trackback 0
Top

너무나 잘 씌여진 보안목표명세서

CC 인증에서 너무나 중요한 위치를 차지하는 보안목표명세서. 읽으면서 아름답다는 표현이 나올만큼 반해버린 보안목표명세서가 있는데, 공교롭게도 안철수연구소에서 작성했습니다. 제가 안철수연구소에 입사하게 되서 그런 것은 아닙니다. 제 취향에는 이 문서가 딱입니다. : )

국가정보원 IT보안인증사무국 홈페이지에 등재된 것이라서 누구나 읽어볼 수 있는데, 편의상 제 블로그에 파일을 올려놓습니다. 보안목표명세서가 무엇인지 궁금하신 분들은 한번 보시기 바랍니다. 안철수연구소의 Suhoshin Absolute v3.0 보안목표명세서입니다. 이 제품은 침입차단시스템 보호프로파일 V2.0을 준수한 국제용 EAL4 인증을 취득했습니다.


이렇게 짜임새 있고 알록달록한 보안목표명세서를 만들기는 정말 쉽지 않습니다. 작성한 분이 얼마나 심혈을 기울였는지 읽으면서 느껴질 정도지요. 아마도, 국제용 EAL4로 인증을 취득하면서 외국에도 공개된다는 점을 고려하지 않았나 싶습니다. 평가자의 입김도 많이 작용했겠지요?
Comment 0 Trackback 0
Top

CC 인증에서 사용되는 중요한 키워드들 - 2

CC 인증에서 중요한 키워드 정리 두번째입니다. 이번에는 일일이 타이핑하기 귀찮아서 파일로 올립니다. 제가 학습용으로 정리하는 것이기 때문에, 개인적인 생각이 들어갈 수 있습니다. 따라서, 잘못된 내용이 있을 수 있습니다. 잘못된 내용이 있다면, 제게 알려주세요~.

이전에 정리한 내용중 일부도 포함되어 있습니다. 조금 수정되었을 수도 있으니 참고하시길.

Comment 0 Trackback 0
Top

CC2.3 기반 개발 문서를 CC3.1로 변환할 때 참고할 자료


http://www.commoncriteriaportal.org/adv_tg.html


CC2.3 기반 개발 문서를 CC3.1로 변환할 때 사용할 수 있는 가이드가 Common Criteria Portal에 있었군요. 2008년 6월에 작성된 것을 이제서야 발견하다니! ㅡㅡ;+

그동안 했던 삽질을 다시 돌아봐야겠습니다. OTL

Comment 0 Trackback 0
Top

CC 인증에서 사용되는 중요한 키워드들 - 1

CC 인증은 매우 추상적인 단어들이 사용되기 때문에 소프트웨어 공학에 익숙하지 않은 분들이라면 낯설게 느껴집니다. CC Part1에 용어 정의가 있기는 하지만, 상세한 설명은 제시되어 있지 않기 때문에 오래전부터, CC에서 사용되는 단어를 정리할 필요를 느끼고 있었습니다. 그런데 실행에 옮기기는 쉽지 않네요. 틈틈이 정리해보도록 하겠습니다.

TOE, Target of Evaluation
CC의 평가 대상이 되는 소프트웨어, 하드웨어, 펌웨어로 구성된 '집합'을 의미합니다.[각주:1] 일반적으로는 IT 제품과 같은 형태를 갖지만, 흔히 생각하는 제품(product) 개념과는 다릅니다. TOE는 어떤 기술이 제품화된 것일 수도 있고, 라이브러리일 수도 있고, 특정한 경계를 갖는 네트워크일 수도 있습니다. 제품의 일부분을 지칭하는 경우도 있고, 제품의 조합일 수도 있습니다. TOE는 그게 무엇이든 간에, CC를 근거로 보안성 평가의 대상이 되는 대상을 의미합니다. TOE는 동시에 설명서(guidance)를 포함합니다.

PP에서 TOE는 특정한 유형의 정보보호제품을 지칭합니다. 예를 들어 네트워크 침입방지시스템(IPS), 침입탐지시스템(IDS), 침입차단시스템(firewall), 무선랜 인증시스템, 웹 응용프로그램 침입차단시스템 등을 의미합니다.

ST에서 TOE는 특정한 정보보호제품 (또는 제품의 일부 기능)을 지칭합니다. 일반적으로, 특정한 정보보호제품의 모든 기능이 TOE가 되는 경우는 없습니다. 예를 들어 침입차단시스템이라면, 침입차단시스템 소프트웨어는 TOE이면서 하드웨어는 TOE 범위에서 제외될 수도 있습니다. SSL/TLS를 이용하여 원격 관리자 세션을 연결하는 경우, 정보보호제품에 탑재된 SSL 라이브러리가 TOE 범위에서 제외되기도 합니다. UTM을 표방하는 제품도 마찬가지입니다. UTM이라는 제품군에 대한 PP가 없기 때문에, 네트워크 침입방지시스템, 가상사설망시스템 등의 PP를 수용하여 특정 UTM 제품에 대한 ST를 작성했다면, 주요 IPS 기능과 VPN 기능을 제공하는 부분(소프트웨어, 하드웨어, 펌웨어, 설명서)을 묶어서 TOE로 정의하고, 나머지는 비-TOE(non-TOE)가 되는 겁니다.

ST에서, TOE의 모든 보안 기능은, ST에 명시된 보안기능요구사항(SFRs, Security Functional Requirements)과 관계있습니다. TOE를 포함하는 정보보호제품에서, ST에 명시된 보안기능요구사항으로 추적되는 기능을 제공하는 부분은 TOE, 추적되지 않는 기능을 제공하는 부분은 비-TOE가 됩니다.

보호프로파일(PP, Protection Profile)
보호프로파일은 특정한 유형의 TOE에 요구되는 보안기능요구사항과 보증요구사항을 정의하는 문서입니다. 보호프로파일은 구현 독립적인(implementation-independent) 문서이기 때문에, TOE가 구체적으로 어떻게 구현되어야 하는지 정의하지 않습니다. (제안요청서와 비슷하다고 볼 수 있습니다. 필요한 기능을 열거는 하지만, 구체적으로 어떻게 기능을 제공하는 지는 굳이 제시하지 않습니다.)

보호프로파일은 누구나 작성할 수 있습니다만, 국내의 경우, 주요 정보보호제품에 대한 보호프로파일은 국가정보원 IT보안인증사무국에서 관리합니다. 관련 링크는 여기를 참조하세요.

보호프로파일은 정해진 형식에 따라 작성되어야 합니다. 보호프로파일의 형식은 CC 1부 부록에 정의되어 있습니다.

보안목표명세서(ST, Security Target)
보안목표명세서는 특정한 TOE가 충족할 보안기능요구사항과 구체적인 구현에 대해 서술하는 문서입니다. 보안목표명세서는 특정한 보호프로파일을 준수하여 작성되기도 하고, 준수하지 않고 작성할 수도 있습니다. (제안서와 비슷하지요?) 보안목표명세서는 보호프로파일을 구체화하여 작성되는 경우가 일반적입니다.

보안목표명세서는 TOE 개발자가 작성하고, 보안목표명세서의 작성 형식도 CC 1부 부록에 정의되어 있습니다. ('개발자'라고 해서 TOE를 구현한 프로그래머를 의미하는 것은 아닙니다.)

보안목표명세서의 앞 부분은 보안목표명세서의 식별정보, TOE의 개요, 논리적/물리적 경계, TOE의 정상적인 실행에 필요한 소프트웨어/펌웨어/하드웨어, 운영 환경, TOE가 사용되는 환경에 대한 가정사항 등을 나열합니다. 그 외에 보호프로파일과 공통되는 항목인데, TOE를 운영할 조직의 보안정책, 위협, 자산, 보안목적 등을 정의합니다. (이러한 것들 없이 보안기능요구사항을 정리할 수는 없잖아요?)

중반 부분은 TOE가 보안기능요구사항을 만족하기 위해 구체적으로 어떻게 구현될/구현된 것인지 서술하고, TOE의 보안성 보증에 필요한 보증요구사항을 서술합니다. (덧붙임: CEM의 ST평가 항목중에는 보안기능요구사항을 서술할 때 사용되는 주체, 객체, 오퍼레이션을 정의했는 지 확인하도록 요구하고 있습니다. 굳이 명시적으로 정의할 필요는 없지만, 미리 정의해두면 여러모로 편리한 점이 많습니다.) 보증요구사항은 보호프로파일에 제시된 평가보증등급(EAL, Evaluation Assurance Level)을 그대로 차용하는 경우가 많습니다.[각주:2]

마지막으로, TOE 요약명세가 제공되는데, 보안기능요구사항을 중심으로 TOE가 어떻게 보안기능요구사항을 구현하는지 요약된 정보를 제공합니다.

보안목표명세서는 CC에 따른 보안성 평가가 종료된 후, 인증기관의 승인을 거치고 외부에 공개됩니다. 평가기간중 평가기관에 제공되는 보안목표명세서는 개발사의 기밀 사항이 포함될 수 있기 때문에, 외부 공개용 보안목표명세서는 평가기간중 사용되는 보안목표명세서와 그 내용이 다를 수 있습니다. (기밀에 해당하는 내용은 외부로 공개되지 않습니다.)

사용자, Users
CC 인증에서 사용자라 하면, 사람(human user)뿐만 아니라 TOE와 상호작용할 수 있는 외부 IT 실체 (external entities)를 포함합니다. 중요한 것은, 상호작용한다는 것이지요. 사용자가 TOE와 상호작용하지 않으면 아무 의미가 없습니다. 논의 대상이 되지 않는 다는 뜻입니다. TOE는 외부 인터페이스(external interfaces)를 통해 사용자와 상호작용을 주고 받습니다. (사용자도 TOE와 상호작용할 수 있는 인터페이스가 있어야 합니다.)

사용자는 인가된 사용자(authorized users)와 인가되지 않은 사용자(unauthorized users)로 구분됩니다. '인가되었다'는 건, TOE가 제공하는 보안기능을 사용할 권한을 승인해준다는 의미로 생각하시면 됩니다. 인가되지 않은 사용자가 TOE와 상호작용할 수 있는 인터페이스는 당연히 그 기능이나 호출방법 등에 제한이 있어야하고, 신뢰된 사용자와 다른 방법으로 (인터페이스를 통해) TOE와 상호작용하게 됩니다.

사용자와 TOE간 인터페이스는 '외부 인터페이스'라고 말씀드렸습니다. CC 평가에서 '외부 인터페이스'는 기능명세서(FSP, Functional SPecification)에 의해 확인할 수 있습니다.

방화벽 제품이 TOE라면, 사용자는 TOE를 통해 네트워크에 접근하고자 하는 네트워크상의 호스트, 네트워크에 연결을 시도하는 사람, 접근 제어 정책을 원격에서 관리하는 (인가된) 관리자 등을 예로 들 수 있습니다.

인터페이스, Interface
위에서 말씀드린 것 처럼, TOE가 외부 실체 또는 사용자와 상호 작용을 주고받기 위해 TOE가 제공하는 수단을 의미합니다.

사용자와 연결하여 방화벽을 예로 들자면, 네트워크상의 호스트가 TOE(방화벽)와 상호작용하는 인터페이스는 네트워크 인터페이스 카드가 됩니다. 사용자가 인증과정을 거쳐서 네트워크 연결을 사용할 수 있다면, 인증 과정에 사용되는 로그인 창(보통 CLI 또는 GUI가 되겠지요?)도 인터페이스입니다. 관리자가 TOE를 통해 구현하는 보안정책을 관리하기 위해 사용하는 웹 화면도 인터페이스입니다.

이런, 서술하다보니 혼동할 수 있는 여지를 남겼네요. 제가 위에서 설명한 인터페이스들은 모두 TOE 외부에 존재하는 사용자와 상호작용을 하는데 사용되기 때문에 '외부 인터페이스'라고 합니다. '외부 인터페이스' 외에도, TOE를 구성하는 서브시스템 수준에서 인터페이스가 있고, 서브시스템을 구성하는 모듈 수준에서 사용되는 인터페이스와 같은 인터페이스가 있습니다. 서브시스템 수준 인터페이스, 모듈 수준 인터페이스는 TOE 설계서(TDS, TOE Design Specification)에서 서술됩니다.

CC에서, 각 인터페이스는 사용 목적과 사용 방법, 인터페이스의 행동을 기술하도록 되어 있습니다. 인터페이스에 입력되어야 하는 것은 무엇인지, 인터페이스를 통해 어떤 기능이 수행된 후, 무엇을 출력값으로 내보내는지도 중요한 요소입니다. 인터페이스에 대한 서술 수준은 평가보증등급(EAL, Evaluation Assurance Level)에 따라 다릅니다. 평가보증등급이 높아질수록, 보다 상세하게 인터페이스를 기술합니다.

(외부 인터페이스와 관련있는 중요한 키워드는 TSFI가 되겠네요. 이건 나중에 다루겠습니다.)

주체, Subjects
주체란, 어떤 행동(오퍼레이션)을 시작하는 존재, 말 그대로 주체를 말합니다. 영문법에서도 Subject라는 단어는 '주어'를 의미하죠. 어떤 행동을 시작하는 '주체'를 의미하는 겁니다. 사용자(사용인, 외부 IT 실체)는 주체가 될 수 있겠군요. 사용자를 대신하여 행동하는 프로세스도 주체로 간주합니다. 주체는 객체를 대상으로 오퍼레이션을 수행합니다.

CC 용어 정의에서는 "객체에 대한 오퍼레이션을 수행하는 TOE 내의 능동적인 실체"로 정의합니다. 결국, 사용자를 대신하여 TOE에서 실행되는 프로세스를 의미합니다. Linux 혹은 Unix를 예로 든다면, 사용자가 로그온을 거친 직후 포크(fork)되어 실행되는 사용자 프로세스를 주체로 볼 수 있습니다.

덧붙임  CC에서 용어정의 부분을 작성한 국가는 미쿡~입니다. 미국에서는 주로 운영체제를, 유럽에서는 스마트 카드를 중심으로 CC 인증이 이뤄집니다. 운영체제를 주로 다루다 보니 주체를 "TOE 내의 능동적인 실체"로 정의했는데, 사실 주체는 TOE 외부에 있을 수도 있습니다. 객체도 마찬가지로 TOE 외부에 있을 수 있습니다. >_<

객체, Objects
주체가 하는 행동(오퍼레이션)의 대상이 되는 것을 의미합니다. 영문법에서 Object는 '목적어'를 의미하죠? '동사'에 해당하는 오퍼레이션의 영향을 받는 대상으로 이해하시면 충분합니다. 객체는 데이터를 포함하거나, 데이터를 수신하는 프로세스와 같은 것들을 의미합니다. 객체로는 파일, 프로세스, 메모리, 패킷 등이 객체가 될 수 있겠습니다.

CC 용어 정의에서는 "주체의 오퍼레이션 대상이며 정보를 포함하거나 수신하는 TOE 내의 수동적인 실체"로 정의합니다.

(객체의) 오퍼레이션, Operation on objects
주체가, 객체를 대상으로 하는 행동을 의미합니다. 이것도 영문법으로 비유하자면, '동사'나 '동사구'와 비슷하다고 할 수 있습니다.
  • 객체가 파일이라면, 읽기, 쓰기, 실행, 삭제, 파일 속성/권한 변경, 해쉬값 생성, 압축과 같은 행동이 오퍼레이션이라 할 수 있겠습니다.
  • 객체가 프로세스라면, 프로세스 초기화, 프로세스 재구동, 프로세스 종료, 프로세스로 파라미터를 넘기는 것을 오퍼레이션으로 봅니다. 프로세스가 객체라면, 프로세스는 오퍼레이션에 사용될 인터페이스를 가질 수 있습니다.
  • 객체가 커널이라면, IOCTL 명령을 전달하는 행동이 오퍼레이션에 해당합니다.
  • 객체가 TCP 또는 IP 패킷이라면, 출발지/목적지와 같은 보안 속성에 따른 헤더 조작, 연결 제어(허용, 거부,  IPSec 암호화 등)이 오퍼레이션에 해당합니다.
  • 객체가 어떤 라이브러리라면, 라이브러리에 속하는 함수를 호출하기 위해 매개변수를 전달하는 것이 오퍼레이션에 해당합니다. (물론, 라이브러리 함수는 자신이 호출될 수 있도록 인터페이스를 제공해야 합니다.
오퍼레이션은 주체/객체의 보안 속성에 따라 오퍼레이션이 다를 수 있겠죠? 만약 주체로 동작하는 프로세스의 보안속성이 일반 사용자인데, 관리자 권한이 필요한 데이터를 읽는 (오퍼레이션을 하는) 것은 허용되지 않을 겁니다.

아이고… 꼬리에 꼬리를 물고 이어지네요. 오늘은 여기까지. 나중에 이어서 설명할게요. 다음에는 SFP, TSF, 보안속성 등을 설명해야겠습니다. :-)

할일이 많아서 이상 끝. >_<

PS. 첨부한 파일들은, CC 파트1~3입니다.

  1. A set of software, firmware and/or hardware possibly accompanied by guidance. (CC V3.1 Part 1에서 발췌) [본문으로]
  2. EAL3+, EAL4+와 같은 경우엔, CC 파트3에 정의된 평가보증등급(EAL)에서 요구하는 보증요구사항에 보증요구사항을 더 추가합니다. EAL3+라면, EAL3에 해당하는 보증요구사항과 EAL3의 상위 평가보증등급에 해당하는 보증요구사항을 더한 것입니다. EAL3+는 EAL4와 거의 대등하지만, EAL4보다는 보증등급이 약한 것으로 간주합니다. [본문으로]
Comment 0 Trackback 0
Top

CC 인증을 추진하기 전에 생각해볼 것들

CC 인증에 발을 들여놓고 3년이 훌쩍 지났습니다. 인증을 준비하면서 뜻하지 않게 시행착오를 겪을 때마다, CC 인증에 앞서 먼저 개발 프로세스를 확립할 필요를 많이 느낍니다.

CC 인증이라고 하면, 많은 회사에서 그저 "공공기관에 제품을 팔아먹으려면 어쩔 수 없이 해야 하는, 까라면 까야 하는" 오버헤드(overhead)로 간주할 때가 많습니다. 전혀 제품 개발에도 기여하지 못하고, 필요도 없는 그런 존재로 생각하기도 합니다. 그래서 CC 인증에 필요한 투자를 최소화합니다. 독립된 CC 인증 전담팀을 두고, "니들이 알아서 해결해"하는 식으로 대응하는 경우가 제일 많은 것 같습니다. 물론, 개발팀의 도움을 받습니다만, 이건 뭐, 샌드박스(sandbox)[각주:1] 안에서 끝나버리는 단독 CC 인증 프로젝트가 될 위험이 큽니다. 이렇게 되면, CC 인증이란, 제품 개발에, 혹은 개발 프로세스 개선에 전혀 기여하는 바 없는 천덕꾸러기 신세인거죠. 한 팀만으로 CC 인증에서 요구하는 요건을 충족한다... 솔직히 제 입장에서 그건 호박에 줄 그어놓고 수박이라고 우기는 일에 지나지 않습니다.[각주:2] 

CC 인증을 기업에서 도입하고, 정말 무언가 가치를 만들어내고자 한다면, CC 인증을 취득하기 이전에 먼저 수행해야 할 과제가 있습니다. 그건 바로, 제대로 된 개발 프로세스를 정립하고 실천하는 일입니다. ISO 9001같은 품질관리 인증을 취득하라는 것이 아닙니다. 정말 중요한 것은, 정말로 개발 프로세스에 따라 모든 과정을 실천하는 것입니다. 아무런 프로세스도 없으면서, 품질관리 인증을 취득했다거나, CMMI 몇 등급을 받았다… 이런건 그냥 조용히 쌈싸 드시기 바랍니다. 개발 프로세스가 잘 되어 있으면, CC 인증을 취득하기란 그렇게 어려운 일이 아니기 때문입니다.[각주:3]

CC 인증에서 다루는 많은 개념들은 모두 소프트웨어 공학에서 이미 확립되어 있는 것들입니다. 이미 존재하는 개념들을 보안 관점에서 구체화한 것으로 보는 게 맞습니다. PP, ST와 같은 문서는 CC에서만 존재하는 독특한 문서이기는 하지만, 개발 과정이 명확하다면, ST 작성에 참고할 수 있는 문서가 이미 존재하는 것이 정상이지요. 최소한 개발을 전제로 하는 구체적인 목표 스펙과 성능을 제시하는 제품계획서가 있을 테니까요.

이미 제품 개발 초기에 기능명세서, 설계서같은 문서들이 갖춰져 있고, 개발되는 제품이 설계서대로 구현된다면, 소스코드가 검증되고 모듈 시험이 충분히 이루어진다면, 블랙 박스 테스트가 철저히 이뤄진다면, 릴리즈에 맞추어 매뉴얼도 구비된다면, CC 인증을 준비하는데 들어가는 리소스는 그리 많을 이유가 없습니다. CC에서 요구하는 대부분의 평가 증거물들은, 정상적인 개발 프로세스에서 당연히 나와야할 산출물들로 구성됩니다. 물론, 평가자를 위해, 문서를 CC 인증에서 요구하는 요건에 맞도록 변형하는 작업은 있을 수 있겠지만, CC 인증을 위해 모든 문서를 "재생산"해야 한다면, 그건 정말로 오버헤드입니다.[각주:4]

눈치 빠른 분은 이미 알아채셨겠지만, CC 인증 취득 과정이 성공적으로 이뤄지려면, CC 프레임워크가 개발 프로세스에 녹아들어있어야 합니다. 따로 국밥마냥, 개발과 인증이 따로 가서는 성공할 수 없습니다. 그러자면, 개발자는 CC 인증 프레임워크를 이해할 필요가 있습니다. 개발 프로세스가 잘 확립되어 있다면, 굳이 이해하려 애쓰지 않아도 될 일입니다.[각주:5] CC 인증 담당자는 초기 설계 단계부터 개입하는 것이 좋습니다. 제품과 관련된 PP가 있다면, PP에 명시된 보안기능요구사항을 개발자가 알기 쉽게 전달하고, 필수 보안 기능이 누락되지 않게 해줄 수 있을 겁니다. 또한 구현 과정에서 버퍼오버플로우나 레이스 컨디션이 발생하지 않도록 코딩 규칙을 만드는데 기여할 수도 있을 겁니다. CC에서 요구하는 보증등급에 따라 개발 프로세스에 요구되는 역량을 분석하고, 어떻게 프로세스를 개선할 것인지 고민하는 것도 어느 정도까지는 담당해야 하지 않을까 싶습니다.

제대로 된 제품을 만들고 관리할 능력이 있어야, CC 인증이 의미있습니다. 제품이 불안정하거나, 실제 제품 버전과 CC 인증 취득 제품이 일치하지 않는다면 CC 인증은 정말 오버헤드가 되어 버립니다. 환자에게 필요한 것은 번지르르한 옷이 아니라, 건강을 회복하는 것이죠. CC 인증은 확고한 개발 능력이 갖춰져야 의미있습니다.

CC 인증을 개발 프로세스에 정착시킬 때 가장 먼저 겪는 어려움은 개발자에게 CC 인증이 중요하다고 설득하는 일보다는, 개발 프로세스 개선이 필요하다는 인식을 심어주는 일이 아닐까 합니다. 개발자들이 이것에 동의하지 않으면, CC 인증 따로, 제품 개발 따로 가는 최악의 상황이 벌어집니다. 정말 이것만은 피했으면 합니다.

  1. 샌드박스라는 표현이 어쩜 이리 잘 들어 맞을까요? 말 그대로 모래상자, 원래는 고양이들이 볼일 보는 모래 상자를 의미하지요. 샌드박스 안에서 무슨 짓을 했건, CC 인증서만 받고 나면 모든 것을 아낌없이 비워버린다는 점에서 똑같지요. -_- [본문으로]
  2. 개발자가 아니라 인증만 전담하는 팀이 설계서를 쓰는 건 흔합니다. 덕분에 저도 C, C++, Java까지 소스를 두루 두루 볼 수 있었습니다. CC 인증 담당자에게 설계서 작성이란, 매우 달갑지 않은 일이지요. 사후 약 방문이랄까? 이미 제품도 나왔고, 소스도 다 있는데, (있지도 않던) 설계서를 왜 써야 하나요? OTL [본문으로]
  3. 어째 제 이야기가 "시장만능주의"를 주장하는 신자유주의 경제학자의 이야기 같이 들린다면 안될 텐데 하는 걱정이 앞서네요. 저는 "개발 프로세스 만능주의자"는 아니라고 말씀드리고 싶습니다. [본문으로]
  4. 아쉽지만, 그게 현재의 관행이죠. 그래서 CC 버전4에서는 개발문서를 그대로 가져와 사용하도록 하려는 움직임이 있습니다. [본문으로]
  5. CC가 뭔가 외계어와 비슷하긴 하지만, 이해못할 것은 아닙니다. [본문으로]
Comment 2 Trackback 0
  1. 2010.06.29 16:42 address edit & delete reply

    비밀댓글입니다

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2010.07.17 21:10 신고 address edit & delete

      네, 괜찮습니다.
      세미나에서 활용하신다니 부끄럽습니다. ㅋ~

      요즘 일에 치여 글을 쓸 겨를이 없는데, 이렇게 봐주시다니 영광. : )

Top

CISSP 시험에서 출제된 CC 인증 문제

얼마전에 보았던 CISSP 시험에서, CC 인증과 관련된 문제를 몇가지 정리해보면, 개념적인 키워드만 물어보았던 것이라 매우 쉬웠습니다. 앞으로는 보다 더 구체적이고 어려운 것들을 물어볼 것이리라 예상은 됩니다.

이번 시험에서는 ST, PP를 묻는 문제가 나왔었지요. 두 문서의 차이점을 알면 됩니다. ST와 관련해서는, ST를 통해 보안성 평가와 관련해서 기준을 얻을 수 있는지 물어보는 문제가, PP는 PP의 재사용을 묻는 문제가 나왔습니다. 더불어 CC가 ISO/IEC 15408이라는 것도 알아야 합니다. CC에 근거한 평가 방법론은 CEM, Common Evaluation Method라 합니다. CEM은 ISO/IEC 18405입니다. CC와 번호가 매우 유사하죠. 구성하는 숫자가 동일한데 위치만 다르다는. (Permutation? ㅎㅎ)

PP, Protection Profile은 CC 한글판에서 보호프로파일이라는 다소 애매한 표현으로 번역되어 있습니다. Profile이라는 단어의 의미를 알아야 하는데, 범죄수사에서도 사용되는 프로파일이라는 개념과 유사하다는 생각이 듭니다. 프로파일이란, 일련의 범죄사건에서 나타난 범죄자의 특정한 패턴, 특이 사항들을 정리해놓은 것을 말하죠. PP도 마찬가지입니다. 어떤 제품군이 보안 기능을 제공할 때 반드시 고려해야할 특이 사항들, 특히 보안기능 요구사항에 중점을 둔 문서입니다. 동시에 보안기능 구현을 보증할 수 있는 방법도 명시합니다. PP는, 특정 제품에 종속되어 있지 않다는 것, 제품을 개발할 때 참고하는 문서라는 점에서, ST 작성의 기초 자료가 된다는 점에서 제품 구현과 관계없이 독립적이고, "재사용성"이 있는 문서라고 답을 하셔야 합니다.

ST, Security Target은 CC 한글판에서 보안목표명세서로 번역되어 있습니다. Target for Security라고 하면 더 명확하지요. ST는 특정한 제품이 제공하는 보안 기능을 서술하는 문서입니다. CC인증의 기초가 되는 문서이면서, 특정한 제품을 설명하는 문서이기 때문에 구현 종속적이고 재사용이 불가능합니다.

ST가 PP를 수용해서 작성되었다면, PP에서 요구하는 보안기능요구사항을 모두 반영하되, 제품에 맞게 변형하게 됩니다. 보안기능요구사항은 더 추가될 수도 있지요. PP에서 요구하는 보안기능요구사항중 일부가 제외된다면, 이론적 근거가 있어야 합니다. PP가 '엄격한 준수'를 요구한다면, 보안기능요구사항은 모두 반영해야 합니다.

앞으로는 무엇이 나올까요? 각 평가등급별 특징 정도는 알아두어야 하겠네요. TCSEC에서 각 보증등급별 특징을 나열했듯이 말이지요…
Comment 1 Trackback 0
  1. Favicon of http://izzang.tistory.com BlogIcon 홍진태 2009.04.04 12:17 신고 address edit & delete reply

    저는 2월 28일 시험보고 불합격 했습니다. ^^
    CC인증문제로 참 어려움을 겪었는데....좋은 자료네요...

Top

CC 인증효력유지 평가를 받다가 생긴 일

어제 CC 인증효력유지 신청 건으로 KISA 평가자와 함께 신규제품 평가를 받는 시간을 가졌습니다. 평가기간은 이틀 걸렸습니다. 준비하는 시간은 좀 더 되죠.

CC 인증효력유지
인증효력유지 신청이 무엇인지 설명하자면, CC 인증을 취득한 제품에 변화가 있을 때, 변화된 내용을 CC 인증 요건에 따라 평가하는 작업입니다. 예를 들자면, 방화벽 제품에서 소프트웨어 부분만을 인증받았는데, 소프트웨어가 구동되는 조건으로 명시된 하드웨어 플랫폼이 변경되거나, 새로운 하드웨어 플랫폼 등을 추가해야 한다든가 하는 것이죠. 혹은, 보안 취약성이 발견되어 해당 부분을 수정한 경우도 해당될 수 있습니다. 예전에 IPSec에서 사용되는 프로토콜에서 보안결함이 발견되거나, openSSL에서 취약성이 발견되어 해당 취약성이 발생하지 않도록 기능을 수정한 적이 있습니다. 여기에는 중요한 조건이 하나 붙습니다. 변경된 내용이 TOE의 보안기능에 영향을 미쳐서는 안됩니다. 만약 보안기능이 변경된다면, 재평가 대상이 될 수도 있습니다.

인증효력유지 신청을 하자면 보안영향 분석서라는 문서를 작성해서 인증기관에 제출합니다. (평가기관이었던가? 헷갈리네요. 이건 확인해서 나중에 수정하도록 하겠습니다.) 보안영향 분석서는 변경되는 내역이 TOE의 보안 기능에 어떤 영향을 주는 지, 분석해서 보고하는 것이죠. 인증기관은 보안영향 분석서를 보고 변경된 부분만을 평가할 것인지, 인증을 새로 갱신해야한다든가 하는 판단을 하게됩니다.

저는 이번에 기존에 인증 받은 TOE에 새로운 하드웨어 플랫폼을 추가하는 인증효력유지 작업에 투입되었습니다. 평가과정중에 이런 과정을 거칩니다. 이전에 인증받을 때 사용한 제품 소스를 이용해서 TOE를 컴파일합니다. 인증 평가 시점에 사용한 소스라는 것을 검증할 수 있도록 평가기관은 인증 시점에서 TOE의 마지막 소스의 hash를 갖고 있습니다. 인증효력유지신청에서 사용하는 소스는, 평가자가 다시 hash를 생성해서 비교해봅니다. 그렇게 해서 hash가 일치하면, 해당 소스를 갖고 컴파일해서 새로 추가할 하드웨어 플랫폼에서 TOE를 구동하면서 기능 시험과 취약성 분석을 재수행합니다. 여기서 문제가 없으면, 무난하게 인증효력을 변경된 제품에 대해 유지할 수 있게 됩니다.

개발 환경도 지난번 인증을 받았던 시점에 비교해서 많이 변경되었습니다. 이 사실을 모르고 있었던 덕분에, 개발자들을 좀 고생시켰습니다. 컴파일 환경을 다시 만들어야 했고, 최신 소스 빌드도 아닌 1~2개월 전 소스로 컴파일해야하니 컴파일과정에서, 컴파일된 이미지를 갖고 시험하는 과정에서 에러가 많이 나더군요. 평가 취득 업무를 진행해야 하는 입장에서, 저는 참 많이 미안했습니다. 앞으로도 이런 게 몇 건 더 있을 텐데.

HASH의 저주
지금은 며칠동안 끙끙대며 겨우 인증효력유지를 위한 평가를 마무리하고 있는 상황입니다. 평가 과정중에 웃지 못할 일이 있었습니다. 그건 인증받은 소스에서 일부 코드의 hash가 일치하지 않는다는 겁니다... -_-; 소스가 변경되었다면, 보안영향 분석서에 당연히 기술했어야 하는 건데, 당연히 소스는 수정하지 않았습니다. 당황스럽죠. 그래서 다시 hash를 떠봐도 마찬가지 결과가 나옵니다. 문득, 소스를 압축한 프로그램이 의심가더군요.

소스 코드는 파일 서버에 zip으로 압축되어 있었고, 압축된 파일을 풀어서 평가자의 노트북에서 hash를 뜬 것인데, 동일한 소스에서 다른 hash 값이 나오니 이상하죠. 더 이상한 건 hash가 일치하지 않는 코드 파일을 열어보니, 일부 문자열이 반복해서 몇십줄 들어가 있다는 겁니다. 의심할 건 압축프로그램 뿐이었습니다. 그래서 리눅스 머신에서 압축된 소스를 풀어보니, 평가자 노트북에서 보고 있는 것과 문자열이 다릅니다. 결국, 압축이 풀리는 과정에서 문제가 생긴 것이라는 결론에 이르렀습니다. 알집이 CRC 검증이라든가, 이런게 잘 안된다는 소리는 들었지만, 직접 겪으니 황당하군요.

미안하다 알집아. 다시는 너를 쓰지 않겠다!
Comment 8 Trackback 0
  1. xeraph 2009.01.23 09:35 신고 address edit & delete reply

    전 빵집으로 대용량 압축 했다가 날려먹은 적도 있고 -_-;;
    리눅스에서만 압축/해제하는게 제일 안전한 것 같아요.

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2009.01.28 09:19 신고 address edit & delete

      윈도우에서 소스코드 대소문자라든가, 파일 개행문자좀 건드리지 않았음 좋겠습니다. 해쉬뜰 때 저런 것들도 영향을 주더군요. 업무용 PC는 윈도우, 개발서버는 리눅스라서, 종종 애를 먹습니다. 맥 너마저. -_-;

  2. Favicon of http://ww0jeff.blogspot.com BlogIcon ww0jeff 2009.01.29 10:54 신고 address edit & delete reply

    정말 버그라면 아주 심각한데요.
    좋은 경험 공유해주셔서 감사합니다~

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2009.01.29 11:16 신고 address edit & delete

      국민 소프트웨어라는 소리를 듣는 제품인데, 많이 아쉽습니다. >_<

  3. Favicon of http://www.sis.pe.kr BlogIcon 엔시스 2009.01.29 18:08 신고 address edit & delete reply

    참..황당했겠습니다..결국 해쉬값이 틀린다는것은 소스 파일 변경이 있었다는 것을 의미 할텐데 다른 어플리케이션인 압축 프로그램이 그렇게 되었다는 것은 어이가 없을수도 있겠네요..

    언제 한번 테스트 한번 해 봐야겠습니다..^^

  4. Favicon of http://ilovealps.com BlogIcon 알프스소년 2009.01.30 13:24 신고 address edit & delete reply

    ㅋ 왜 일자목이세요?? 궁금합니다~ ㅎㅎ

  5. Favicon of http://kopil.tistory.com BlogIcon 박코필 2009.10.26 09:54 신고 address edit & delete reply

    CC인증 업무를 맞게 되었는데
    글 하나 하나가 제게 도움이되는 글들입니다.
    이번에 변경승인을 받게 되는데 같은 문제가 생기면 바로 해결할 수 있겠네요. 감사합니다. ^^

  6. Favicon of http://hyacinth.byus.net BlogIcon hyacinth_kr 2011.04.04 14:28 신고 address edit & delete reply

    알집... -_-;;;

Top

IE 0-Day 취약성과 AtiveX, 그리고 CC 인증

마이크로소프트에서 인터넷 익스플로러 보안 업데이트 패치를 내놓음에 따라 제로데이 공격이 다소 안정국면으로 접어들겠지만, 이번 일은 참 많은 것을 생각하게 합니다. 그중 하나가, ActiveX의 설계 결함이죠. 마이크로소프트에서도 고치려고 노력하고 있고, 그래서 이제는 ActiveX 모듈이 실행되려면 사용자의 실행 승인이 필요합니다. Vista에서는 더욱 보안을 강화했기 때문에, 관리자 권한으로 ActiveX를 실행하기란 더 어려워졌다고 합니다. 그렇지만 ActiveX가 가진 태생적 한계를 생각해보면, 사용을 권장할 만한 기술은 못됩니다.

CC 인증에서 다루는 보안 이슈중에 영역 분리(domain separation), 우회불가성(non-bypassability), 자체 보호(self-protection)라는 것이 있습니다. 다른 것은 생략하고 영역 분리만 생각해보면, ActiveX는 설계 단계에서 보안을 충분히 고려하지 않았다는 결론에 이르게 됩니다.

영역 분리란 각 기능이 수행될 때, 기능에 따라 영역은 분리되어야 함을 의미합니다. 운영체제의 영역과 웹 브라우저의 메모리 영역을 분리하고, 웹 브라우저 실행에 필요한 사용자 권한을 제한함으로써 웹 브라우저에서 발생할 수 있는 문제를 웹 브라우저 프로세스에 제한시켜야 합니다. 그래야 안전하다는 것이죠.

ActiveX는 웹 브라우저를 통해 다른 응용 프로그램을 설치하거나, 실행시킬 수 있도록 해줍니다. ActiveX로 설치되는 프로그램은 인터넷 익스플로러에서만 사용되는 일종의 애드온(add-on) 프로그램일 수도 있고, ActiveX의 형태를 빌려서 사용자의 PC에 설치되는 응용 프로그램일 수도 있습니다. 이렇게 설치된 프로그램이 인터넷 익스플로러 내부에서 호출되어 실행되거나 단독 실행되는데, 문제는 이렇게 실행되는 프로그램이 관리자 혹은 시스템 권한으로 실행될 수 있다는 점과, 시스템 라이브러리를 이용한다는 점이죠. 영역 분리가 되지 않는 겁니다.

이런 문제를 해결하려면, ActiveX 모듈을 호출하는 프로그램의 실행 계정은 제한된 권한만을 허용하고 레지스트리 접근을 차단할 필요가 있습니다. 참조하는 라이브러리 접근도 제한해야합니다. 이런 노력이 Vista에서는 이루어지고 있다는게 참 다행이죠.

저는 ActiveX가 없으면 참 좋겠습니다. 맥이나 리눅스 같이 Windows 기반 기술을 전혀 사용할 수 없는 운영체제를 사용하거나, Windows를 이용하더라도 파이어폭스나 구글 크롬과 같이 ActiveX를 지원하지 않는 웹 브라우저를 사용하는 사람들에게 ActiveX는 아예 사이트 출입 금지 푯말과 같습니다. 만약 금융권이 ActiveX 기반 공인인증서를 사용하지만 않았어도 괜찮았을 텐데하는 아쉬움이 남습니다. 

* 사이드 스토리

우리나라 국가 표준 암호화 알고리즘은 국내에서 개발된 SEED, ARIA, NES와 같은 것을 사용합니다. (NES는 국가기관에서만 사용하기 때문에 일반에 공개되지 않습니다.) 다른 나라들은 SSL/TLS를 사용해서 인터넷 상거래를 하지만, 우리나라에서는 국가 표준 암호화 알고리즘을 준수해야 하는 것 같습니다. 그래서 인터넷 뱅킹을 할 때 공인 인증서를 사용하면서 국가 표준 알고리즘의 사용 방법을 고민하다가 내린 결론이 ActiveX를 사용하기로 했다고 합니다. 출처를 기억하지 못해서 아쉽습니다. 아마도 이것이 국내 인터넷 환경에 ActiveX를 보편화한 시작점이 아니었을까요.

Comment 0 Trackback 0
Top

어울림정보기술, 통합보안제품 2종 CC인증 획득

http://www.itdaily.kr/news/articleView.html?idxno=17375

이로써 올 한해 프로젝트 하나 마무리. PM으로써 첫 프로젝트 마무리입니다.

지금은 또 다른 CC 인증 프로젝트 준비 작업중입니다. CC 버전3.1에 따라 보안목표명세서를 작성중이죠. 이건 언제나 끝나려나.
Comment 0 Trackback 0
Top

비평가 대상 VS 비보안 기능

지금은 점심시간입니다. 점심을 후딱 먹어치우고 앉아 있는 현재 시각은 2008년 11월 28일 12시 12분. (12.12사태?) 아, 우리회사의 점심 시간은 11시부터랍니다. :-)

이달 말이면 그동안 진행하던 CC 인증 프로젝트를 종료합니다. 이미 제 손을 다 떠났기 때문에 인증기관의 승인만 기다리고 있는 상태죠. 저는 벌써 또 다른 CC 인증 프로젝트를 준비중입니다.

평가의 시작은, 먼저 TOE, 즉 평가대상(Target of Evaluation)를 정의하는데서 시작합니다. 근데, 고민입니다. 이미 제품은 (이미  일년 전에) 개발완료된 상태이기 때문에, 평가 대상이 될 제품은 명확합니다. 동작상의 오류도 없고, 제품으로써는 명쾌하지만, TOE 개념 잡기는 어렵습니다. 왜냐면...

제품에서 평가받을 기능과 평가 받지 않을 기능을 먼저 정의해야 하는데 이게 쉽지 않기 때문입니다. 평가받을 기능은 "보안 기능성(Security Functionality)"을 제공하는 녀석이고, 평가에서 배제할 기능은 "비평가 대상", 혹은 "비보안기능"이 될 겁니다. 그런데, 좀 "보안 기능성"과 "비평가 대상"을 구분하는 기준이 모호하지 않은가요? 인증을 준비하면서 문서를 작성하다보면 비평가 대상과 비보안 기능의 모호한 경계에 존재하는 것들이 나타나서 괴롭히곤 합니다.

보안 기능성의 반대말은 비보안 기능성일테고, 비평가 대상의 반대말은 평가 대상이죠. 그래서 나름대로 개념을 정리해보려고 합니다.

먼저, TOE 입니다. 말 그대로 평가의 대상이죠. 그럼 무엇이 평가의 대상일 수 있겠느냐? CC에서 정의한 용어로는 "(이용) 가능한 설명서가 수반되는 소프트웨어, 펌웨어 및/또는 하드웨어 집합"이라고 합니다만, 이렇게 정의 내리면 너무 모호해집니다. 그래서, 저는 TOE란, "PP 또는 ST에 명시된 보안기능요구사항을 제공하는 소프트웨어, 펌웨어 및/또는 하드웨어와 및 관련 설명서"로 정의하려고 합니다. (이건 공식적인 정의가 아니므로 어디가서 이렇다 라고 이야기하지는 마세요.)

그 다음으로는 비평가 대상입니다. 비평가 대상을 영어로 정의한다면, "Non-TOE"가 맞을 것 같습니다. (우리 팀에서는 무의식적으로 'Out of Scope'이라고 표현 하는데 좀... 맞지 않는 말이라는 생각이 듭니다.) 비평가 대상이란, 평가 범위에서 배제된 소프트웨어, 펌웨어 및/또는 하드웨어이겠네요. 왜 배제될까요? 이건 아마도 TOE가 운영되는 환경 또는 IT 실체로 존재하는 것들을 지칭하기 때문이라고 봐야 합니다. 환경에 속하는 것들은 CC 인증의 평가 대상이 아닙니다. 그럼에도, 비평가 대상이라 하더라도, IT 환경에 요구되는 보안기능요구사항이 PP 또는 ST에 명시되어 있다면, 이것을 만족시켜야 한다는 것에 주의해야 합니다. (물론, 가정사항으로써 안전하다고 간주합니다.)

세번째로는, 보안 기능성입니다. CC 2.3에서는 "Security Function"으로 표기했지만, CC 3.1에서는 "Security Functionality"로 바뀌었습니다. 원어민이 아니어서 둘 사이에 어떤 차이가 있는지 뉘앙스는 모릅니다. 그런데 이상하게도, CC 용어 정의 부분에 보안 기능성을 정의해놓지 않았습니다! 작성자가 졸았던 걸까요? 뭐, 아쉬운 사람이 뭔가 해야겠지요. 저는 나름대로 이렇게 정의해봅니다: 보안기능성은 CC 파트 2에 정의된 보안기능요구사항(SFR, Security Functional Requirement)으로 추적이 되는 기능이다. (관건은 SFR을 얼마나 잘 이해하는지에 달려있겠습니다.) CC에서, 보안 기능성을 TOE의 보안 기능성과 IT 환경의 보안 기능성으로 구분했던가요? 보안 기능성은 TOE에게 요구되는 것일 겁니다. (CC 뒤적이면 되는데...)

보안 기능성을 정의할 때는 SFR이 기준이 된다고 했는데, CC 파트2는 너무나 많은 SFR로 구성된 일종의 라이브러리이기 때문에, 이 모든 SFR을 사용할 수는 없습니다. 그건 지옥이지요. 그래서, 보안 기능성을 정의할 때 사용되는 보안기능요구사항은 TOE에 대해 정의한 PP 또는 ST에서 사용된 것으로 한정합니다. (아... CC 인증을 이야기 할 때는 모든 것이 꼬리에 꼬리를 뭅니다. 아... -_-;)

네번째로는, 비보안 기능성입니다. 보안 기능성을 제 나름대로 정의해보았으니, 비보안 기능성은 그 반대라고 생각해볼 수 있을 겁니다. SFR로 추적이 되지 않는 기능성입니다. 분명히, TOE의 기능이기는 한데, PP 또는 ST에 명시된 SFR로 추적이 되지 않습니다. 이러한 것들이 비보안 기능성들입니다.

자, 그럼, 한가지만 물어보고 싶습니다. TOE는 보안 기능성만을 제공할까요?

아니죠? TOE를 구성하는 모든 소프트웨어, 펌웨어, 하드웨어가 오직 보안 기능만을 제공하지는 않습니다. (드물지만 그럴 수도 있겠죠.) 그럼, 물리적으로는 분명히 TOE의 영역인데, 논리적으로는 전혀 보안기능성과 무관한 것들은 어떻게 해야하는 걸까요? 이것들은 비평가 대상일까요? 아니면 비보안 기능일까요? 제가 무언가 놓친 것이 분명합니다...

CC 3.1은 TOE에서 제공하는 기능과 인터페이스를 크게 셋으로 나눕니다. "SFR-수행(SFR-enforcing)", "SFR-지원(SFR-supporting)", "SFR-비간섭(SFR-non-interfering)"이 그것이죠. 이름 붙인 그대로, 모든 기준은 SFR로 추적이 되느냐, SFR을 구현하는데 기여하느냐 입니다. SFR이 기준입니다! 이제, TOE의 모든 기능이 보안기능성이 아니라는 것은 자명합니다. CC에서도 인정하잖아요.

그런데, SFR을 수행하는 것으로 생각되지만, 평가에서 제외되는 것들이 있습니다. 이런 것들은 무엇이라고 해야 할까요? 참 헷갈립니다. 예를 들면, 안티바이러스 엔진 같은 겁니다. 안티바이러스 엔진을 다른 업체에서 라이선스로 공급받아 사용하는 업체들이 몇 있습니다. 알약이나, 네이버 PC 그린이나 모두 스스로 개발한 안티바이러스 엔진을 사용하지 않고 라이선스 받아서 공급받는 겁니다. (방화벽 업체에서도, 안티바이러스 엔진을 공급받아서 탑재하는 경우가 흔합니다.) 이스트소프트나 네이버에서 자기네 안티바이러스 제품을 CC 인증 받고 싶어도, 자신들이 개발하지 않았기 때문에 소스도 없고, 평가자에게 안티바이러스 엔진과 안티바이러스 DB의 평가에 필요한 보증문서를 제출할 수 없습니다. 방화벽 업체들도 마찬가지지요. 방화벽이 아무리 안티바이러스 기능을 제공한다고 하더라도, 보증할 수 있는 수준은 안티바이러스 엔진과 연결된 인터페이스 수준까지에 불과합니다. 이런 것들은 무엇이라고 불러야 할까요? 비평가 대상? 비보안기능? 아니면 그냥 평가 범위에서 제외(Out of Scope)? 아... 고민입니다. 누가 이런 사례를 설명해주실 분이 있으면 좋겠습니다.

저는 다시 고민의 수렁속으로 빠져듭니다. 다들 즐거운 주말 되세요.
Comment 0 Trackback 0
Top

CC 인증 보안성 평가의 범위

[업데이트] TOE에 대해서는 별도로 설명하고자 글을 쪼갭니다. 여기서는 보안성 평가의 범위만을 다룹니다. (2008-09-15)


CC인증의 평가 범위
CC 인증은 IT 제품의 보안성을 평가하는 기준입니다. "보안성"이라는 표현이 애매할 수 있기 때문에 CC에서는 다음과 같은 것들은 평가의 범위에서 제외합니다. (평가 대상을 정의하기 어려울 때는 일단 평가 대상이 아닌 것을 먼저 걸러내는 것이 더 간편한 방법이죠.)

  • 보안 기능성과 직접적인 관련이 없는 관리적 측면에서의 보안성 평가
  • 물리적인 측면에서 발생할 수 있는 기술적인 보안성 평가 - 예를 들어 잔자파 방출 통제 같은 것은 보안성 평가의 대상이 아닙니다.
  • CC를 실제로 IT 제품의 보안성 평가에 적용하는 평가 방법론 - 이것이 CEM입니다. CEM은 별도로 규정되어 있기에, CC에서 평가 방법론은 평가 대상이 아닙니다.
  • 인증기관이 정한 CC의 적용에 관한 관리 및 법률 체제 - '평가 스킴(evaluation scheme)'은 CC의 평가 대상이 아닙니다. 평가 스킴은 특정 공통체 내에서 인증기관에 의해 공통평가기준이 적용되는 관리 및 규정 체제를 의미합니다.
  • 암호 알고리즘의 고유 특성 평가 - 암호 알고리즘 자체에 대한 평가는 CC에서 제외됩니다. 이와 관련해서 미국은 FIPS 140, 우리나라는 국가보안연구소에서 평가하는 암호검증제도가 있습니다. 암호 알고리즘은 CCRA 가입국이라 해도 자국의 보안과 직결되는 사안이라 양보할 수 없는 듯 합니다.
  • 평가 결과를 사용하기 위한 절차 - 평가 결과를 어떻게 사용할 것인가 하는 것은 CC의 범위를 벗어납니다.

결국, CC 인증은 IT 제품을 대상으로 하되, 보안과 관련된 기능성(TSF, TOE Security Functionality) 측면에서 보안성을 평가하는 기준이라 할 수 있습니다. CC에서는 "평가(evaluation)"을 다음과 같이 정의합니다.

평가 - 보호프로파일, 보안목표명세서, TOE가 정의된 기준을 만족하는지 사정하는 것(assesment of a PP, a ST, or a TOE, against defined criteria)

즉, PP, ST, TOE가 평가 대상입니다. PP와 ST는 이미 간략하게 설명드린 바 있습니다. (조만간 CC 인증에서 사용되는 용어들 중 중요한 것만 추려서 정리하도록 하겠습니다.) TOE라는 개념은 조금 모호해서 설명이 필요합니다.

보호프로파일(PP, Protection Profile)과 보안목표명세서(ST, Security Target)가 평가 대상이 되는 이유는, 이 문서들이 TOE로 표현되는 평가 대상의 보안 기능성을 정의하고 있기 때문입니다. PP와 ST가 올바로 정의되어 작성되었는지 먼저 검증하고, 이에 따라 TOE가 정의된 보안 기능성을 구현했는 지 검증하는 순서로 평가가 진행됩니다.

제안요청서같은 역할을 하는 PP - TOE가 갖추어야할 보안요구사항
대한민국 공공기관이라면, 방화벽이나 VPN 장비, IPS 장비같은 정보보호제품을 구매할 때에는 CC 인증을 취득한 제품만을 구입하도록 법으로 정해놓았습니다. 금융권에서도 정보보호제품을 구매할 때에는 CC 인증을 취득한 제품을 선호합니다. 아마도 정부에서 권장하는 이유에서겠지요.

국정원 IT보안인증사무국은 주요 정보보호제품이 반드시 수용해야하는 PP를 관리합니다. PP는 한국정보보호진흥원이나 국가보안기술연구소와 같은 기관에서 개발하여 IT보안인증사무국의 최종 승인을 거칩니다. 즉, PP는 우리나라 공공기관에 납품되는 정보보호제품들이라면, 반드시 수용해야할 기준과 같은 역할을 합니다. (PP는 여기에서 다운로드할 수 있습니다.) 따라서 국내에서 CC 인증을 취득한 제품들은 PP에서 정의된 보안요구사항을 반영했다고 볼 수 있습니다.

공공기관에서는 PP의 수용여부가 제품 입찰의 조건으로 제안요청서에 박혀 있는 경우가 자주 있습니다. 우리나라에서, CC인증의 획득은 곧 영업의 성공과 실패를 좌우하는 조건이 됩니다.
Comment 2 Trackback 0
  1. Favicon of http://itnbt.tistory.com BlogIcon JCEO 2008.09.17 15:04 신고 address edit & delete reply

    좋은 글 감사합니다. 마침 CC인증과 관련된 일을 해야 하는데 많은 도움이 되겠습니다. 한 가지 질문을 드린다면, 어떤 신제품 또는 신기술에 대하여 CC인증을 받으려면 어떻게 해야 하나요? CC인증 받는 회사가 이에 필요한 PP나 ST, TOE등을 만들어야 하나요?

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2008.09.21 20:24 신고 address edit & delete

      TOE는 추상적인 개념이고, 개발회사의 입장에서 TOE는 개발중인 제품이나 제품에 탑재되는 기술을 의미합니다. 네트워크 보안장비 회사라면, 방화벽, VPN, IPS 등의 기능을 가진 제품의 주요 보안 기능을 TOE의 범주로 볼 수 있습니다.

      PP는 보안제품에 대한 일종의 "제안요청서"로 생각하세요. 제품 개발사가 자신이 만든 제품에 대해 PP를 쓸 일은 없겠지요. ST는 "보안제품 제안서"로 생각하세요.

      CC 인증을 취득하려고 하신다면, 먼저 국가정보원 IT보안인증사무국 http://www.kecs.go.kr 로 가셔서 해당 PP가 등록되어 있는지 확인하시기 바랍니다. 제품에 해당하는 PP가 있다면 수용하시는 것이 좋습니다.

      국가기관은 모두 CC인증을 취득한 제품을 공급해야 하는데, 보통 특정 PP를 수용한 제품을 요구하는 경우가 많습니다.

      요약하자면,
      1. 수용할 PP 확인: CC 인증을 취득하고자 하는 제품과 관계있는 PP가 있는지 국정원 IT보안인증사무국 홈페이지에서 확인합니다. (없다면, PP를 수용하지 않으면 됩니다.)
      2. TOE의 범위 확인: 제품의 기능중 CC 인증에 의해 보안성을 평가 받을 기능과 평가 받지 않을 기능을 정의합니다. 여기에서, 평가 대상 기능을 구현하는데 사용되는 소프트웨어, 하드웨어, 펌웨어 등이 TOE에 해당합니다.
      3. ST 작성: PP를 수용하는 경우, PP에서 요구하는 평가보증등급(EAL)에 따라 보안기능요구사항, 보증요구사항을 정의하여 작성합니다. (PP를 수용하지 않는 경우에도 목표로 하는 평가보증등급에 맞추어서 보안기능요구사항, 보증요구사항을 정의하여 작성해야 합니다. 민간제품의 최상위 평가등급은 EAL4로 보시면 됩니다.)
      4. 보증증거자료의 수집/작성: 평가보증등급에서 요구하는 각종 증거 문서를 수집/작성 합니다. (각종 증거 문서는 CC 파트3에서 정의된 증거요구사항을 지켜야 합니다. CC 파트3는 CC인증의 평가 방법론 CEM의 기초가 됩니다. 보증증거자료는 평가기관과 인증기관 외부에 공개되지 않으며, 평가를 위한 목적으로만 사용됩니다.)

      CC 버전 3.1을 기준으로, 증거문서로는 일반적으로 다음과 같은 것들이 필요합니다.

      * 매뉴얼: 설치지침서, 관리자 설명서, 사용자 설명서 등
      * 개발문서: 기능명세서(ST의 보안 기능 요구사항을 기능 명세서에 대응해야 함), 설계서(기능 명세서의 각 기능을 서브시스템 또는 모듈 수준에서 설계), 구현검증명세서(실제 소스코드와 설계서의 대응관계), 보안구조 분석서(제품의 보안기능 우회 방지, 보안기능의 자체보호, 보안 기능간 영역분리 등에 대한 구조 분석)
      * 시험문서: 기능시험서, 모듈시험서
      * 형상관리문서: 제품수명주기, 개발도구(개발도구및 개발 환경, 컴파일 방법 등을 명세), 형상관리절차, 개발환경의 물리적 보안 지침

      국내에서는 아직 개발회사를 위해 CC 인증을 대행해주는 업체가 없습니다. 그러나 평가기관과 컨설팅 계약을 맺고 작성된 문서에 대해 컨설팅을 받는 것은 가능하니 참고하시기 바랍니다.

Top

CC 인증(IT 제품의 보안성 평가 기준)의 개요

블로그를 시작하면서 정보보호와 관련된 이슈를 다루려고 생각했는데, 그동안 다룬 것들은 막상 제가 일하는 것과는 다소 다른 분야였습니다. 그랬더니, 힘드네요. -_-;a (시작한지 얼마나 되었다고 벌써 그러냐!!) 오늘부터는 "CC 인증"에 관한 글들을 연재하고자 합니다. (그렇다고 CC 인증만 다루면 지루하겠죠?) 제가 하는 일은 CC 인증과 관련되어 있습니다. CC 인증을 다루자니, 많은 부담을 갖게 됩니다. 제가 아는 한, CC 인증 분야를 다루는 블로그는 보지 못했기 때문입니다. 그리고, 이 분야에서 7년 이상 일하고 계시는 분들이 계십니다. 그분들이 보시기에, 제가 다루는 내용은 얕은 지식일 수도 있겠습니다.

그래도, CC 인증을 다루고자 하는 건, 나름대로 일하면서 느낀 것과 생각을 다룸으로써 보다 나 스스로에게 정리할 시간을 주기 위한 것이라는 점을 덧붙이고 싶습니다.

전자신문, 보안뉴스 같은 곳에서 종종 "A사의 방화벽 XX가 EAL4 등급 CC 인증을 받았다"라는 내용의 기사가 뜹니다. EAL4라는 말도 낯설거니와, 도대체 CC 인증이라니 이게 무슨 소리일까요? 언뜻 봐서는 방화벽이 무슨 인증을 취득했다라는 소리로 밖에는 안들릴 겁니다. 앞으로 저런 기사를 보면 이렇게 생각하세요: "A사에 XX라는 방화벽 제품이 있는데, CC라는 정보보호제품 보안성 평가 기준에서 정한 평가 보증 등급 4 수준의 인증을 받았다."

CC인증 = IT 제품의 보안성 평가에 사용되는 국제 표준
CC는 Common Criteria의 줄임말이며, 국제 표준 ISO/IEC 15408로 제정된 정보보호제품의 보안성 평가 기준을 의미합니다. CC는, 컴퓨터 보안과 관련된 IT 제품의 보안성을 평가하는 국제 표준이라고 생각하시면 됩니다.

알아두세요: CCRA - CC 상호 인정 협약


CC는 지속적인 검토를 통해 업데이트되고 있습니다. (CC의 개정은 CCMB에서 진행합니다.) 우리나라에서 사용되고 있는 CC는 2.3 버전과 3.1 버전입니다. 2.3 버전은 2009년부터는 사용이 중지되고 3.1 버전으로 이행해야 합니다. (그러고보니 벌써 버전 4가 논의되고 있다는 군요.)

CC 인증을 소개하면서 CEM을 다루지 않을 수 없겠네요. CC에 따라 개발된 IT 제품의 평가 방법론을 CEM (Common Evaluation Methodology)이라고 합니다. CEM도 국제 표준이며, 국제 표준 번호는 ISO/IEC 18045입니다. CC에 따라 평가하는 기관은 반드시 CEM을 준수하여 평가하도록 되어 있습니다.

CC 인증에 따라 평가하고 인증하는 기관들
현재 우리나라에는 3개의 평가 기관 (한국정보보호진흥원 KISA, 산업기술시험원 KTL, 한국시스템보증 KOSYAS)과 1개의 인증기관 (국가정보원 IT 보안인증사무국)이 있습니다. 평가기관은 문자 그대로 보안성 평가를 수행하는 기관을 의미하고, 인증기관은 국내에서 수행되는 CC 보안평가 스킴을 총괄하는 역할을 수행하면서 평가기관이 수행한 평가 결과를 최종 승인하는 기관을 의미합니다. 인증기관은 CC 인증서 발행국당 1개가 있습니다. 예외적으로, 호주와 뉴질랜드는 1개의 인증기관에서 모두 포괄합니다. CC 인증 평가기관과 인증기관은 인증 과정과 결과의 객관성을 보증하기 위해 국제 표준(ISO/IEC 17025, 또는 BS EN 45011)에서 요구하는 기준을 획득하고 준수해야한다는 까다로운 조건이 붙습니다. =_=;a

평가보증등급 (EAL, Evaluation Assurance Level)
평가보증등급(EAL)은 CC에 따라 정의된 보안성 평가 보증 등급(Evaluation Assurance Level)을 의미합니다. 평가 보증 등급은 1부터 7까지 모두 7 등급으로 구성되어 있습니다. 7 등급이 가장 높은 등급입니다. 그러나 아직까지 EAL7 등급을 받은 IT 제품은 없습니다. 전 세계에서 현존하는 가장 높은 등급은 EAL5+입니다. 국내에서는 아직까지 EAL5+를 받은 제품은 없습니다. 그런데, '+'가 왜 붙었는지 말씀을 안드렸군요. 그건 나중에 설명드리기로 하겠습니다. 다만, 평가등급 숫자(4가 1보다 크죠?)가 클수록 보다 엄격한 기준으로 깊이있게 보안성을 평가했다는 의미로 받아들이시면 됩니다.

알아두세요: CEM과 EAL


평가보증등급이 높을 수록, IT 제품의 보안성을 더 신뢰할 수 있습니다. 그렇지만, 과연, "평가보증등급이 높을 수록 더 좋은 것일까?"하는 의문의 여지가 있습니다.

평가보증등급을 결정짓는 중요한 요소는, IT 제품이 수용한 보호프로파일(PP, Protection Profile)과/또는 보안목표명세서(Security Target)입니다. (PP는 일종의 제안요청서(RFP), ST는 일종의 IT 제품의 제안서에 해당한다고 생각하세요.) PP와 ST는 모두 CEM에 명시된 평가보증등급 기준에 따라 작성되고, 제품이 사용되는 환경, 보안 위험 요소, 보안목적, 보안요구사항 등을 명시하도록 되어 있습니다. 따라서, CC 인증을 취득한 제품의 구입을 고려한다면, 반드시, 해당 제품의 ST를 확인해보고 제품의 도입이 사용 목적과 사용 환경에 적합한지 확인해야 합니다.

CC의 전체적인 구조
CC는 모두 3개 부분으로 구성되어 있습니다.

파트 1 (소개 및 일반모델)은 CC의 기본 프레임워크와 보호프로파일(PP, Protection Profile), 보안목표명세서(ST, Security Target)이라는 CC의 기본 문서에 대해 다룹니다. PP와 ST는 보안성 평가에서 매우 중요한 시작점입니다. ST가 보안성 평가의 절반을 차지한다는 이야기도 있을 정도입니다.


알아두세요: ST가 중요한 이유


파트 2 (보안기능요구사항)는 IT 제품에 요구되는 각종 보안 기능과 관련된 요구사항의 정의에 사용됩니다. PP와 ST는 파트2에서 정의된 보안기능요구사항(SFRs, Security Functionality Requirements)을 참조하여 작성됩니다. 즉, 파트2는 파트1에서 정의된 PP, ST와 같은 문서에서 가장 중심이 되는 내용을 기술할 때 사용합니다.

보안기능요구사항은 동일한 요구사항에 대해 계층화하거나 세분화함으로써 PP/ST 작성자가 선택하여 사용할 수 있도록 구성되어 있습니다. 다양한 요구사항을 기술할 수 있도록 매우(!) 추상적인 진술들이 많기 때문에, 각 보안 기능요구사항에 대한 부록이 달려 있을 정도입니다. 부록은 각 보안기능요구사항이 어떤 상황에서 사용되어야 하는지 사용 시 주의사항등을 다룹니다. IT 제품은 반드시 PP/ST에서 기록된 보안기능요구사항을 구현해야 합니다.

파트 3 (보증요구사항)는 보안성을 평가할 때 요구되는 평가 범위와 평가 수준에 대하여 등급(이것이 EAL입니다.)을 정하고, 등급에 따라 IT 제품의 보안성 평가에 사용할 보증요구사항(SARs, Security Assurance Requirements)을 정의하고 있습니다. CEM은 파트 3에서 명시된 보증요구사항에 대한 검증방법을 다룹니다. 보안성 평가를 수행하는 평가자의 입장에서 CEM은 보안성 평가의 바이블이 됩니다. CEM에서는 파트 3에서 명시된 요구 사항 하나가 하나의 평가 작업 단위가 됩니다.

평가보증등급이 높아질 수록 보증요구사항으로 요구하는 자료가 많아지고 평가기간도 길어집니다. 당연히, 비용도 적잖게 들어갑니다. 제품의 복잡도가 클수록 더욱 그렇죠.

글을 줄이며
이렇게 해서 CC 인증의 기본 개념에 대해 간략히 정리해보았습니다. 간략히 쓴다는게 쓰다보니 길어졌습니다. 앞으로는 CC 인증에 관련된 내용을 꾸준히 포스팅하도록 하겠습니다.


Comment 9 Trackback 1
  1. Favicon of http://nchovy.kr BlogIcon xeraph 2008.08.22 11:28 신고 address edit & delete reply

    오오 앞으로 나올 글들도 기대되는군요 ^^

  2. Favicon of http://www.sis.pe.kr BlogIcon 엔시스 2008.08.23 08:45 신고 address edit & delete reply

    CC 에 대한 글 잘 보았습니다. 앞으로 글 기대하겠습니다...

  3. 최작 2008.09.12 09:06 신고 address edit & delete reply

    와~ 정말 오아시스 같은 글입니다. 감사합니다~ ^^

  4. Favicon of http://blog.paran.com/lovefev BlogIcon 김동현 2008.09.24 11:52 신고 address edit & delete reply

    좋은 내용 잘 보고 갑니다. ^^

  5. centia 2008.11.24 16:13 신고 address edit & delete reply

    cc 인증 업무를 하는 사람으로서 다름 글도 기대되네요 ^^

  6. eloi 2008.11.27 16:11 신고 address edit & delete reply

    좋은 글 잘 보았습니다. 그런데 한가지 질문이 있습니다.
    CCRA 설명 박스 안에서 "...CCRA 가입국은 크게 CC 인증서 발행국과 CC 인증서 발행국(현재 12개국..." 으로 둘 다 'CC 인증서 발행국'으로 표기 하셨습니다. 오타가 아닌가 합니다.

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2008.11.28 12:05 신고 address edit & delete

      앗~ 그렇죠. 정정했습니다. ㅎㅎ

  7. 지나가다 2015.09.16 13:41 신고 address edit & delete reply

    잘 정리해주셔서 입문하는데 많은 도움이 되었습니다. 참고로, ISO 18045가 18405로 오타 났네요~ ^^

    • Favicon of http://nulonge.tistory.com BlogIcon nulonge 2015.11.19 23:42 신고 address edit & delete

      고맙습니다. 지금껏 잘못 알고 있었네요 ㅋㅋ

Top

prev 1 next