[강은성의 안전한 IT세상]보안취약점 공개의 문제점과 바람직한 대안

최근 한 언론매체에서 키보드보안 프로그램의 보안 취약점 문제를 제기한 바 있다. 모 교수가 준비하고 있는 논문을 인용해 키보드보안 프로그램이 설치된 인터넷 서비스 사이트라 하더라도 사용자가 입력한 패스워드, 계좌정보가 노출된다는 점을 몇 개의 기사로 낸 것이다.

여느 때와 마찬가지로 정보보호당국, 보안업체, 금융권 등 당사자들이 부산하게 움직이면서 대책을 수립하고 있다.

◆해외에서의 보안취약점 처리 사례

소프트웨어의 보안취약점을 발견하고 공개하는 것은 어제 오늘의 일이 아니다. 대표적인 것이 마이크로소프트(MS)사의 보안 패치이다. MS사는 아예 매달 한번씩 정기적으로 보안 패치를 내고 있다.

많은 해커그룹이나 보안전문업체에서 MS사 제품의 보안취약점을 연구, 발견하여 MS사에 제공하고 있고, MS사는 이 취약점을 보완하는 패치를 만들어 취약점 내역과 함께 공개한다. 취약점을 발견한 그룹이나 업체는 보안 패치가 공개되는 때에 맞춰 그것을 자신의 사이트에 올리거나 언론에 공개해 자신의 기술 역량을 자랑하기도 한다.

오라클이나 시스코 등 세계 유수 업체의 제품에 대해서도 이와 같은 방식으로 취약점과 패치가 공개되고 있다. 일부 악의적인 해커들이 보안 패치가 나오기 전에 보안취약점을 공개하여 제로데이(Zero-day) 공격의 위협을 야기하는 특별한 경우를 제외하고는 보안취약점의 발견과 제공, 보안 패치 배포, 취약점의 공개의 일련의 과정이 큰 무리 없이 이뤄지고 있다.

그런데 왜 우리나라에서는 보안취약점 공개가 큰 이슈가 되는 걸까? 가장 큰 이유는 보안취약점 발견자가 그것을 보완해야 할 개발업체에 제공하지 않은 채 언론에 공개함으로써 보안취약점에 대한 보안패치가 나오기 전에 그것을 공격하는 악성코드가 먼저 나오는 '제로데이 공격' 가능성이 생기기 때문이다. 그로 인해 해당 서비스를 이용하는 많은 사용자들의 주요 정보가 유출되는 위험에 처할 수 있다. 특히 금융 정보가 노출되면 사용자들이 큰 금전적 손실을 입을 수 있어서 사회적으로도 큰 혼란이 생긴다.

하지만 보안취약점 발견자가 개발업체나 서비스업체에 이를 제공하지 않은 채 언론에 공개하는 것도 전혀 이유가 없는 것이 아니다. 그것을 알려 줬을 때 개발업체들이 긴급하게 보안 패치 제공 일정을 제공하여 사용자의 정보 보호를 도모하기는커녕, 그것의 공개를 막는 데 주력하는 것이 일반적이기 때문이다.

또한 보안취약점에 대한 연구와 발견이 학문적 성과인 대학의 연구자들은 단지 개발업체에 연구 결과를 제공해서는 적절한 시기에 그들의 성과를 인정받기 어려울 수 있다. 보안 제품을 판매하기 위한 수단으로 보안취약점을 공개하는 경우도 있다. 아마도 보안취약점을 공개하는 최악의 이유일 것이다.

불시에 보안취약점이 공개되면, 이것을 해결해야 하는 쪽에서는 허둥지둥 긴급하게 대책을 세우게 된다. 준비 기간이 짧기 때문에 근본적인 대책을 세우기 보다는 드러난 사안만을 해결하기 위한 응급 처방을 내는 경우가 많다. 다시 보안취약점이 공개되고, 다시 응급 처방을 하는 악순환이 지속되는 한 원인이 된다.

◆국내 환경에 적합한 보안취약점 처리 체계를 만들어야

작년 10월에 열린 ‘금융정보보호컨퍼런스 2007’에서 ‘전자금융 보안 취약점 공유 방안’에 관한 패널 토의가 있었다. 대학 연구팀에 의해 2007년 7월에 USB 키보드보안의 허술함이 밝혀지고, 9월에는 인터넷 증권거래 사이트의 취약점이 공개되면서 한창 보안취약점 공개가 논란이 되었던 시기였다.

보안취약점 공개에 관한 주요 당사자인 금융감독원, 정통부, 정보보호진흥원, 보안업체, 언론에서 패널이 참석한 이 날 토의에서 각 주체의 입장이 개진되었고, 이에 대한 개선책이 논의되었다.

이 날 정통부 쪽에서 제안한, 보안취약점을 공공기관에서 접수하고 적절한 방법으로 관련 당사자들이 공유하는 방안이 눈길을 끌었다. 어느 정도 패널들의 공감대를 끌어 냈는데, 그 방안이 추진되지 못한 채 최근 보안취약점 공개 문제가 다시 이슈로 등장한 것은 참으로 안타까운 일이 아닐 수 없다.

필자 역시 그 방안에 기본적으로 동의하면서, 이를 다음과 같이 정리해 보았다.

보안취약점 발견자는 접수기관(정부 관련 기관)에 접수하고, 접수기관은 이를 검증하고 확인하여 종합적으로 관리한다. 발견자가 자신의 발견 내역을 다른 기관에 성과로 보여야 할 경우에는 접수기관의 증명을 사용할 수 있다.

접수기관은 보안취약점을 해결하거나 대비해야 하는 당사자에게 이를 공유하고, 보안 패치를 내야 할 주체(개발업체나 서비스업체)는 패치 배포 일정을 제출한다. 접수기관은 해당 일정을 발견자에게 통보하여, 패치 배포 이후에 보안취약점 공개를 준비할 수 있도록 한다. 보안 패치의 계획에 변경이 일어날 경우에는 개발업체는 접수기관, 취약점 발견자와 협의하여 일정을 재조정할 수 있다. 무작정 늦어지면 안되기 때문에 적절한 제한도 필요하다.

안철수연구소는 보안 제품을 개발하는 동시에 보안취약점을 연구하고 있어서 개발 업체와 보안취약점 발견자 양쪽의 상황을 실제 겪어 보니, 세계에 그 유례를 찾아 보기 어려울 정도로 개인정보나 금융정보를 필요로 하는 중요한 서비스들이 인터넷을 통해 대중적으로 서비스되고 있는 국내 환경에서는 각 관련 당사자들이 믿고 따를 수 있는 공적인 접수기관이 필요함을 절실하게 느낀다.

이를 통해 보안취약점을 적절하게 관리한다면, 보안취약점에 대한 연구와 발견이 소모적인 논쟁과 혼란의 출발지가 아니라 국민이 믿고 쓸 수 있는 안전한 IT 세상을 만들어 가는 동력이 될 수 있을 것이다.

/강은성 안철수연구소 상무