cleanUrl: /posts/korean-common-criteria-scheme-sucks
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 인증에 편향된 사고를 갖고 있어서, 인증 입장에서는 당연하다고 여기는 것들이 현실적으로 가능하지 않은 이유를 이해하지 못하는 것같고, 기술적인 지침을 제대로 제공해주지도 않는다. 이제 음지에서 양지로 나와 갑을관계도, 민관의 상하 관계도 아닌, 국가의 정보보안을 책임지는 파트너로서, 대등한 위치에서 협력관계를 가졌으면 좋겠다.