2006년부터 CC 인증 업무를 해왔다(지만… KCCUF 활동에 참여하지도 않으니 아웃사이더라고 해야겠지). 어울림정보기술, 안랩을 거쳐 지금은 시큐아이에 있다. 중간에 2년 6개월 정도는 테크니컬 라이팅 업무만 했었으니, 대략 7년 6개월 간 인증 업무를 한 셈이다. 2012년 즈음에 CC 인증 제도에 대한 회의감때문에 CC 인증 업무를 손놓았었다. 그 회의감이 요즘 다시 든다. 그 좋은 테크니컬 라이팅을 왜 놓았을까. 2012년 즈음이나, 지금이나 여전히 인증 제도는 구태를 벗어나지 못했다.
우리나라의 CC 인증의 이력은 국가정보원에서 태동했다. 어울림정보기술이 국정원, KISA와 함께 호주에서 EAL4 인증을 받은게 그 시작이다. (물론 그 전엔 K4, K4E 인증이 있었지…) 인증 주체는 국정원에서 국가보안기술연구소 산하 IT 보안인증사무국으로 변경되었다. 그러던 것이 2014년에야 IT보안인증사무국이 미래창조과학부로 이관되었다.
인증기관의 못된 버릇, 비밀주의
국정원 시절부터 인증기관의 가장 큰 고질병은 비밀주의다. 그들의 신분상 특성 때문에 인증담당자가 누구인지 신원을 알 수 없었고, 모든 전달 사항은 평가기관을 통해 구두로 전달될 뿐, 문서화되지 않았다. 인증 평가에 중대한 영향을 미치는 결정사항이나 지침은 평가기관을 통해 면대면으로, 전화로, 혹은 메일로 전달되었다. 평가신청업체의 직접적인 연락이 허용되지 않는 블랙박스. 공문 요청도 허용되지 않는 블랙박스, 오직 평가기관을 통해서만 간접 인터페이스를 갖는 블랙박스.
“지금도” IT보안인증사무국 산하 인증자들은 자신이 노출되는 걸 꺼린다. 어느 정도냐면, 인증 업무가 있어 평가신청업체에 방문할 때 자신의 이름이 노출되는 걸 원치 않아서 임시 출입증을 발급해줄테니 개인정보활용동의서를 쓰라해도 쓰지 않는다. “지금도” 인증기관의 지침이나 결정사항을 문의하려면 평가기관을 거쳐야 하고, 공식적인 문서로 내용을 받는 일이 별로 없다. 예나 지금이나 인증기관의 태도는 변한 게 없다.
문서화되지 않은 내용들은 그저 업체의 평가 인증 업무 실무자들에게 “전승”으로 전해진다. 누구는 알고, 누구는 모른다. CC 인증을 처음으로 받아야 하는 업체 입장에서는 눈뜬 소경이 된다. 그냥 모든 규정을 명문화해라… 힘들다.
행정부의 산하기관이라면, 행정정보는 투명하게 공개해서 운영하길 바란다. 비밀주의는 단순히 인증자나 인증기관의 행태로만 끝나지 않고, 각종 문서와 지침을 다루는 관행으로 이어진다. 평가지시서가 그렇고, 국가용 정보보호제품 보안 기능 요구사항 문서가 그렇다.
평가지시서는 규화보전?
인증기관은 평가기관에게 기술적인 평가 지침을 담은 평가지시서를 제공한다. 이 문서는 국내용 CC 인증 평가에서 CEM과 같은 지위를 갖는다(PP와 같은 위치에 있는 문서가 ‘국가용 정보보호제품 보안요구사항’이다). 인증 신청업체라면 누구나 참고하고 싶은 문서이지만, 단 한 번도 전문이 공개된 적이 없다. ‘국가용 정보보호제품 보안 기능 요구 사항’의 경우 하드카피, 혹은 필사본과 같은 형태로 알음알음 전해진다. 반면에 평가지시서는 평가 진행 중 이슈가 있을 때, 문서의 일부분을 캡처(길어야 한 두 단락?)해서 보여줄 뿐이다. 이게 무공의 비기를 담은 규화보전인가? 왜 평가신청업체에겐 접근을 제한하는지 알 수 없다.
평가지시서는 인증평가 신청업체가 열람할 수 있도록 공개할 필요가 있다. 인증기관 입장에서는 평가규정문서에 불과한 이 문서는 평가자의 평가 활동에 영향을 미치고, 국가용 정보보호제품 보안요구사항의 적용, CEM에 대한 인증기관의 유권해석을 담고 있기 때문이다. 법 체계에 비유하자면 시행 세칙과 같다. 인증기관이 움켜쥐고 보여주지 않는 이 문서는 인증 대상 제품에 대한 기능 제한도 정의하고 있고, 심지어 평가 신청 업체의 형상 관리 정책에도 영향을 미친다.
평가지시서, 또는 보안요구사항으로 제시되는 내용들을 보면, 보안 관리 정책으로 풀어야 할 문제들을 기술적인 방법으로 풀도록 요구함으로써 평가 신청 업체의 불만을 일으키는 것들도 많다.
예를 들자면, 네트워크 제품(예: 방화벽, IPS같은 네트워크 장비)에 접근 가능한 관리자 IP 주소를 최대 2개로 제한한 규정은 과연 기술이나, 보안 관점에서 바람직한 것일까? 왜 2개인지 기술적인 근거가 없다. 그냥 국가정보원의 지침이 그런 것으로 알려져 있을 뿐이다. 합리성이 결여된 IP 주소 제한은 다른 보안 기술의 적용마저 퇴색하게 한다. 관리자 계정을 IP 주소와 바인딩해서 접근을 제한할 수도 있고(이 경우 접근할 수 있는 IP 주소는 관리자 계정 개수만큼 필요하다), 관리자 권한 연결이 필요한 ESM이나 장비 전용 관리 시스템의 제어를 이용할 수 있지만 2개라는 제한은 이러한 수단을 무력화해버린다. 게다가 관리자의 IP 주소를 스푸핑해 계속 접근을 시도하면 제품의 관리 인터페이스를 무력화하는 서비스 거부 공격이 가능해진다.
네트워크 통신으로 연결되는 TOE의 구성요소들은 반드시 암호화 채널을 이용하도록 하는 강제 사항은 반드시 지켜야 하는 것일까? TOE와 상호작용하는 외부 실체(예: 서버)와의 통신은 암호화 채널을 이용해야 한다거나, TOE 외부로 내보내는 데이터는 내용 불문, 통신 목적 불문하고 무조건 암호화해야 한다는 건 대체 무슨 심산인지 모르겠다. TOE가 아무리 보안을 중요하게 여긴다한들, 레거시 시스템 환경에서 상호운용성(interoperability)나 하위 호환성을 배제해야 하는 것일까?
모바일 VPN 클라이언트를 배포할 때엔 WiFi 연결을 사용하지 말라는 이야기도 있던데, 정말인지 모르겠다. 코드사인을 검증할 수 없어서? WiFi 구간을 믿을 수 없어서? 그리고, 지금도 충분히 안전하게 구현해 사용할 수 있는 TLS 1.0/1.1은 왜 신뢰할 수 있는 채널로 사용하면 안되는 것인지?
평가지시서는 심각하게 기술 표준을 훼손하기도 한다. 대표적인 예가 syslog의 암호화 전송이다. 이 요구사항 때문에 514 포트를 사용하는 syslog 통신에 DTLS를 적용해서 인증을 받는 업체도 있다. 이것은 현저하게 상호운용성을 떨어뜨릴 뿐더러, 무엇보다 기술 표준이 아니다. 2010년에 발간된 RFC 문서(시스코와 화웨이 등에서 제안)는, DTLS 기반 syslog 통신 포트로 6514를 사용하도록 정의하고 있다(국내 벤더 중에서는 이 문서의 존재를 아는 곳은 많지 않은 것같다). 지시서의 내용은 불충분하고 명료하지 않다. 언제부턴가 암호화를 요구하기 시작했는데, 왜 해야 하는지, 무엇을 참고해야하는지 가이드가 없었다.
그뿐인가? 국가용 정보보호제품 보안요구사항에 오타가 나거나, 내용이 앞뒤가 맞지 않는 경우가 있다. 정오표가 있어서 오류 내역을 제공해주는 배려는 전혀 기대할 수 없다(공개 문서도 아니고). 이런 상황에서 평가자가 보안요구사항을 “문자 그대로” 요구하는 경우를 본적도 있다.
평가신청업체가 인증기관에 직접 문의할 수 없는 “이상한” 관행과 객관적인 기술 검토가 불가능한 상황에서 평가 신청 업체는 변경불가한 보안요구사항이라는 이유 하나만으로 알아서 따라 가야 한다.
기술적인 이슈를 검토하기 위해 기술검토위원회가 있는 것으로 안다. 기술검토위원회는 인증기관과 평가기관 외에, 기술자문을 할 수 있는 전문가들이 포함되어야 한다고 본다. 가능하면 평가신청업체도 포함되었으면 한다. 인증기관과 평가기관은 CC 인증에 편향된 사고를 갖고 있어서, 인증 입장에서는 당연하다고 여기는 것들이 현실적으로 가능하지 않은 이유를 이해하지 못하는 것같고, 기술적인 지침을 제대로 제공해주지도 않는다. 이제 음지에서 양지로 나와 갑을관계도, 민관의 상하 관계도 아닌, 국가의 정보보안을 책임지는 파트너로서, 대등한 위치에서 협력관계를 가졌으면 좋겠다.
불분명하거나, 신뢰하지 않거나
대한민국 CC 인증 평가 제도에 내려오는 하나의 불문율은 “방화벽 PP와 IPS PP의 동시 수용 금지”이다. 놀랍게도, 어떤 배경에서 그런 것인지, 명문화된 설명이 없다. 국정원으로 거슬러올라가는 시점부터 그러했던 것이라 그런지도 모르겠다. UTM 장비들은 필요에 따라 IPS 처럼 쓸 수도 있고 방화벽처럼 쓸 수도 있다. IPS에 대한 인증기관의 해석은 일반적인 IPS 운용 상식과도 어긋난다. IPS를 IDS와 방화벽 기능이 결합한 것으로 보기 때문에 기본 정책은 모두 차단이어야 한다고 본다. 하지만, IPS는 보통 방화벽 뒷단에서 이미 접근 제어를 거친 트래픽에서 공격을 탐지하는 목적으로 쓰는 게 일반적이므로 모든 연결을 허용한 상태에서 공격만 차단하면 된다. 그럼에도 fail-close, deny all을 기본 정책으로 가져가도록 하는 건 대체 왜 그런건지. 우리 회사만 그런건지. 내가 이해가 부족한건가?
여하튼, 우리나라의 CC 인증 평가 스킴은 특정 제품군을 분류하고, 하나의 제품은 한 두 개 범주를 넘어설 수 없게 제한하고 있는데, 그 결정 주체는 인증기관이고, 그동안 인증기관의 결정에 대해 평가신청업체는 거부할 힘이 없다.
평가 진행 중 이슈가 되어 결정된 사항은 다른 평가신청업체들의 평가에도 영향을 미칠 것이 뻔해도 공개된 정보 형태로 재검토되거나 공개적으로 문서화/공지되지 않는다. 평가 중 평가기관과 평가 신청 업체 사이에 해결되지 않는 이슈가 있으면 인증기관, 평가기관, 평가 신청 업체의 3자 회의를 여는게 원칙이다. 그렇지만 열리는 걸 본 적이 없다. 이때도 평가 신청 업체는 직접 인증 기관을 대면하지 못하고 평가기관이 인증기관의 프록시가 된다. 평가기관이 평가 신청 업체의 입장에서 인증기관과 협의하는 경우도 꽤 된다는 점은 부정할 수 없지만, 여기서 다시 인증기관의 직접적인 소통 의지는 없는 것으로 확인된다.
단일 인증 건 뿐만 아니라 앞으로 진행될 모든 인증에 영향을 미칠 안건에 대해 이런 식이다. 이런 과정에서 결정된 사항들은 선례로 남아 다른 인증에도 영향을 미친다. 만약 하나의 (인증요구사항 준수라는 명목의) 나쁜 선례가 생기면 다른 인증 제품에도 적용되기 때문에 악순환이 반복된다.
새로운 보안 기술이 적용된 제품에 대한 인증기관의 대응은 굼뜨기도 하고(굼뜨더라도 방향이 옳다면야…), 기술 흐름을 전혀 이해하지 못하고 있다. 국내에서 최초로 APT 대응 제품 인증을 받은 곳은 안랩이다(아니라면 알려주시길). APT 대응제품은 악성코드 분석을 위해 샘플 파일을 외부로 전송해 자동화된 시스템으로 분석하거나 전문가가 직접 진단을 내려야 한다. 그렇지만 기관의 기밀정보가 노출될 것을 우려해 파일 전송을 금지하고 해시값만 전송하라는 지침으로 내려왔다. 따르지 않으면 인증은 진행불가다.
생각해보라. 특정 사이트나 사용자를 공격하려고 만든 전혀 새로운 악성코드라면, 해시값만으로 탐지가 가능한지?
이렇게 APT 제품을 사용한다면 그건 그냥 클라우드에 보관된 안티멀웨어 DB에 질의를 던지는 것과 다를 바없다. 그렇게 해서는 APT 기능이 의도하는 보안 목적을 전혀 달성할 수 없다. 안타깝게도, 지금까지 인증기관의 결정 사항은 APT 기능을 통해 외부로 파일을 전송하면 안된다는 것이다. 그게 싫다면 APT 제품 내부에서 악성코드 분석을 할 수 있도록 하거나 로컬 네트워크 내 분석장비만 사용하라는 것인데, 이렇게 해서는 전문가 시스템을 전혀 활용할 수 없다. 도대체 어쩌라는 것인지 모르겠다. 이건 명백하게 개발 주체의 독립성을 훼손하는 것이고, 더 나아가 제품의 상품성과 기능성을 훼손하는 일이다.
어쨌거나, 안랩 제품이 APT 제품의 평가 기준이 된 것같은데, 이런 지침은 나쁜 선례다. 내부 기밀이 유출될 것을 우려한다면 그건 SLA같은 계약을 통해 기밀 유지를 보장받는 식으로 얼마든지 풀 수 있다. 단지 유출될 가능성이 있다는 이유 하나만으로 기능의 변경을 요구하는 건, 인증기관이 특정 기능의 보안 목적을 이해하지 못했거나, 평가신청업체를 믿을 수 없다는 의사의 표시일 것이다.
결국, 문제는 신뢰다. 평가신청업체에 대한 신뢰, 보안제품에 대한 신뢰. 인증기관은 평가신청업체, 보안소프트웨어/하드웨어 제조사를 믿지 않는다. 몇 건의 CC 인증 오용 사례가 있기는 하다. DLP 제품이 아닌데 DLP 인증 제품으로 판매한다든가 하는 일이 있었다. 그렇지만 벼룩잡자고 집에 불을 놓을 수는 없는 노릇이고, 모든 업체가 오용을 목적으로 인증을 받는 것은 아니잖는가?
인증기관이라는 지위 혹은 권위에 근거한 판단은 으례 국내 IT 보안업체에게 역차별로 작용한다. 인증기관의 바람과 달리 외산 제품은 이런 인증기관이 정해놓은 제약에서 자유롭다. 국내 인증 제품이 외산 제품과 같은 기능을 제공하는데 인증이라는 뜻밖의 제약을 만나 고전한다. 보안기능을 제공하면 CC 인증을 받은 제품의 베이스라인이 변경되는 것이고, 더 이상 CC 인증은 효력이 없어지니말이다.
어떤 인증자는 책임 회피로 일관하는 것처럼 보인다. 선례가 있다면 검토없이 무조건 따른다거나, 다른 업체는 이렇게 했으니, 너희도 이렇게 해야 한다는 자세를 취하면 곤란하다. 어느 업체는 빌드 번호를 사용할 수 있고, 어느 업체는 리비전 번호를 사용할 수 있다. 형상 식별 수단은 개발업체의 고유 권한인데, A사가 그렇게 관리한다고 B사도 그렇게 해야한다는 주장은 어디서 나오는 것일까.
그래서일까? 모든 벤더의 제품은 각 벤더마다 특징이 있고 차별화되는 기능들이 있는데, 인증을 받다보면 벽돌 찍어내듯 다 동일한 기능 집합을 갖는 모양이 되어버리는 것같다. 꼭 그렇게 요구해야 했었을까?
인증기관의 평가기준이나 지침이 바뀌는 경우가 있다. 그 때엔 기준이 바뀌었다가 아니라강화되었다고 하는데, 현실적이지도 않고, CC 인증 측면에서만 바라보면서 균형을 잃어도 한참 잃었다 싶을 때가 있다. 그럼에도 평가 신청 업체 입장에서 대꾸하지 못하는 건 순전히 미운털 박힐까봐 그렇기도 하고(모든 평가 인증 실무자들은 자신이 진행하는 인증 프로젝트의 지연을 두려워한다), 문서화된 기록이 없으니 아예 이슈화하기 힘들다는 현실적인 이유가 있다. 어쨌든, 인증기관의 실수는 인정하지 않는다.
국내용 인증 제도의 폐혜
좋게 생각해 “인증기관도 나름의 사정이 있겠지”할 수도 있겠다. 현재 평가 스킴의 가장 큰 문제는 아마도 국내용 CC 인증제도일테다. 어찌보면 인증기관도 국제용과 국내용으로 이원화한 인증제도의 피해자일 수 있다.
대부분의 국내 업체는 국내용 인증 제도를 활용한다. 대부분은 비용문제 때문에 국내용 인증 제도를 선호한다. 평가 기간도 약간 짧고, 인증 준비에 필요한 문서 준비 부담도 적다. 일부 업체만 해외에서 제품을 팔 때 필요하다는 이유로 국제용 인증을 받는다. 그런데, 수출할 때 CC 인증이 없으면 못 파느냐… 그건 또 아니다.
국내용 인증 제도는 CC 인증의 틀만 갖춘 “전혀 다른 인증”인데, 이것을 금융기관이나 일반 기관의 보안관리자들은 잘 모른다.
국내용 인증 제도는, 정부의 조달정책의 일환으로 국가정보원의 보안적합성 기준을 만족시키기 위한 평가 과정이다. 국가용 정보보호제품 보안 요구 사항을 준수했는지 검증하는 것이 주요 평가 포인트이다. 진심으로 정부기관용이라는 데에 방점을 찍고 싶다.
국내용 인증 제도는 CC 인증과 달리, “TOE = 제품”이라는 개념에서 출발한다. 원래 CC 인증은 “TOE ≠ 제품”이다. “제품의 전 기능을 다 평가하니 더 평가범위가 넓은 것 아니야?” 이렇게 반응할지 모르겠지만, 여기서 출발하는 문제점은 이런 것들이다.
첫째, 특정한 정보보호제품군에 속하는 제품으로서, 해당 제품군에 적용되는 국가용 정보보호제품 보안요구사항을 만족해야 한다. 제품의 특정 보안 기능이 외부 실체에 의존한다면, 그 기능을 제품의 베이스라인에서 빼야 하거나, 외부에서 보안 기능을 제공하는 실체가 보안기능의 일부를 수행하는 것으로 간주해 TOE 범위에 넣어야 한다. 이 경우, 국제용 CC 인증이라면 TOE의 범위를 평가 신청 업체가 정의하고 시작하므로 외부에서 제공하는 보안 기능은 별도의 TOE로 평가받아도 상관없겠지만, 지금까지 인증기관의 반응을 볼 때 난 회의적이다.
두번째, 국가용 정보보호제품 보안요구사항의 가장 높은 우선 순위는 기밀성과 책임추적성에 있다. 이를 위해서 CC 인증의 베이스라인은 상호운용성, 하위호환성의 희생을 감수해야 한다. 성능도 논외다. CC 인증 베이스라인을 만족하기 위해 변경된 기능 그대로 운영 환경에 적용하려하면 사용하기 불편하거나 성능의 불이익이 생길 수 있다.
세번째, VPN과 같이 암호화 기능이 중요한 제품들은 사용할 수 있는 암호 알고리즘이 매우 제한적이다. AES는 비검증대상 암호 알고리즘이므로 보증하지 않는다. ARIA, SEED와 같은 국내 표준 알고리즘을 사용해야 한다. 국제용 인증에서는 비검증대상 암호 알고리즘도 허용된다.
만약 금융권이나, 일반 기업에서 제품을 구입한다면, 국내용 CC 인증 제품에 기대할 수 있는 건 제품이 취약성 검증을 거쳤다 정도로 생각하면 될 것같다.
국내용 CC 인증 제도를 운용하는 한, 제대로된 CC 인증 평가는 정착되기 어렵다. 업체 입장에서는 저렴하고 기간도 짧은 국내용이면 그만이다. 그리고, 국제용 CC 인증 평가에 국내용 평가 기준을 들이대는 평가자들이 있는 것같은데, 얼마 전에 모 인증자가 국제용 CC 인증은 국가용 정보보호제품 보안 기능 요구 사항을 준수하지 않아도 된다고 말했으니 기억해두면 좋겠다. 심지어는 그렇게 하면 ‘월권’이라고 했다.
CC 인증 제품은 레퍼런스 모델일 뿐
어느 제품이 CC 인증을 받았다면, CC 인증을 받은 특정 버전은 하나의 레퍼런스 모델로 생각하는 게 맞다. 이에 대해서는 Red Hat의 공통평가기준(Common Criteria) FAQ에서 잘 다루고 있다. 어느 제품이 CC 인증을 받았다는 의미는, 보증 수준(EAL)이 요구하는 요건에 따라 형상관리를 하고 있고, 주어진 가정 사항을 만족하는 특정한 환경에서, 제품의 보안 기능이 의도한대로 동작함을 보증하는 것일 뿐이다. CC 인증은 제품에 대한 보증이므로 실제로 제품이 운영 환경에 적합하다는 보증을 하지 않는다(운영 환경에서 보안 제품의 적합성을 검증하는 제도는 따로 있는데, 그게 국정원이 운영하는 보안 적합성 검증이다).
공공기관이라면 CC 인증 버전이 탑재된 제품을 사용하는 게 의무사항이지만, 미국은 공공기관이 CC 인증을 받은 제품을 도입하고 나서 관리만 잘하면 관대한 것같다. 국내에서는 주기적인 감사가 있고, 이때마다 CC 인증 버전인지 아닌지를 갖고 보안 관리자들이 많이 시달린다. CC 인증 받은 버전만 고집하다보면 오히려 취약성에 노출될 수도 있다. OpenSSL 라이브러리가 탑재된 CC 인증 제품이 있다고 가정하고, 취약성이 발견되어 OpenSSL 새 버전이 나오면 당장 제품의 보안 업데이트를 하는 것이 안전하다. 하지만, 보안 업데이트를 하는 순간 그 제품은 이미 CC 인증을 받은 형상이 아니다. 제품 제조사는 제품의 형상이 변경되었으므로 CC 인증 효력 유지를 위한 변경 승인 절차를 진행해야 하는데, 모든 버전을 대상으로 변경 승인을 받는 것은 시간이나 비용을 고려하면 불가능한 미션이다. 그러니, CC 인증 버전에 집착하지 말고, 이미 제품을 도입한 이후에는 꼬박 꼬박 취약성이 패치된 제품을 사용하는 것이 오히려 바람직하다. 물론, 우리나라 공공기관의 현실은 CC 인증 버전이 아니라면 담당자가 곤란해지겠지…
인증자/평가자에게 필요한 것, 보안 실무 혹은 개발 경험
대학원을 갓 졸업한 초짜, 그냥 랩실에서 연구만 하다가 나온 사람은 인증자와 평가자가 되지 않았으면 좋겠다. 최소한 보안 실무를 경험해보았거나, 개발 경험이 있는 사람이 평가자, 인증자의 자격을 갖춰야 한다. (정말 이들이 제대로 평가하려면 감리사, 기술사같은 경험과 지식을 갖고 있고, 그에 맞는 대우를 받아야 하는 것 아닐까?) 평가 수수료 대부분이 인건비라서, 경력과 경험이 많은 평가자를 무턱대고 선호할 수는 없겠지만 말이다. 최소한… 평가 신청 업체에서 평가 인증 실무라도 해본 사람이 해야 하는 것 아닐까?
그들이 선무당같은 결정을 내리거나 평가를 함으로써 평가 대상 제품을 쓰지도 못할 고물로, 형상 관리를 누더기로, 한 업체의 개발 환경을 아수라장으로 만들어버린다는 것은 알고 있을까?
어울림정보기술에 근무할 때 연구소장이 인증자들을 ‘헛똑똑이’라고 이야기했었다. 그들의 요구나 보완 요청은 이론적으론 옳을 때가 있었지만 보안도 결국은 비용 대비 효과라는 측면에서 비효율적이거나, 실제 제품의 보안성을 향상시키기는 커녕 쓸데없는 서류작업만 유발하는 경우가 많았다. 엉뚱하게도, OpenSSL 설계서를 요구하거나, 웹 기반 도움말을 열어볼 때 다시 로그인하도록 요구하는 평가자도 있었다… 더러는 너무 기밀성에 초점을 맞추어 수정을 요구하는 바람에 가용성이 심각하게 훼손되거나, 보안 기능성이 더 축소되는 경우도 있다.
CC 인증 평가는 IT보안제품 혹은 제품의 묶음, 혹은 제품의 특정 기능에 대한 보안성 평가일 뿐이다. CC 인증 평가에 사용하는 프레임워크인 CC/CEM은 물론 소프트웨어 엔지니어링에 근거한 것이지만, 이것만 알아서는 제대로 평가하기 어렵다. 평가 스킴 준수에만 초점을 맞춘 평가가 제품이 의도한 보안 목적과 기능과 늘 같지는 않다.
보증문서로부터의 자유
전에도 언급했었지만, CC 인증 초창기에는 인증을 받기 위해 인증용 개발 문서 작성이 필요했다. 우리나라는 평가 스킴에서 평가 착수 전에 모든 문서가 다 구비되어 있어야 한다. 이것은 올바른 요구 사항도, 평가 방법도 아닌 것같다.
인증 제도가 일찌감치 시작된 미국은 CC 인증 대상 제품의 개발 단계부터 평가기관이 참여한다. 평가기관은 자유롭게 평가 증거를 수집할 수 있다. 이를 위해 평가기관과 신청업체 사이엔 기밀유지협약이 필수이리라 본다. 그리고, 미국의 평가 스킴에서 문서의 비중이 높지 않다는 것도 눈여겨 볼 일이다.
회계감사를 생각해보면, (CC 인증도 결국은 감사 활동과 같으니까) 회계 감사를 위해 별도로 장부나 전표를 작성하지 않는다. 감사인이 스스로 감사 증거를 수집하듯, 평가자도 스스로 평가 증거를 수집해야 한다. 왜 CC 인증을 위해 다시 한 번 문서를 작성해야 할까? CC 인증을 좀더 가볍게 가져갔으면 좋겠다. 설계서는 소스 코드 내 주석으로도 충분히 가능하지 않은가(그러자면 잘 정착된 개발 문화와 관행이 우선해야 한다는 것도 문제)? 기능 시험서는 QA의 테스트 케이스만으로도 충분하다(테스트 케이스의 성실한 문서화가 전제). 난 오히려 개발문서에 TOE라는 용어가 등장하는 게 어색하다. 그건 100% 인증을 고려해 사후에 작성된 문서다.
CC 인증 업무는 하면 할수록 한숨만 나오는 일인지도 모르겠다. 점점 열정은 사그러든다. 내가 하는 일을 사랑하고 싶은데, 요즘 왜 이렇게 힘든거냐.
