시작하며
하트블리드 (Heart Bleed)는 보안 전문가가 아닌 필자가 관심을 가져야 했을 정도로 필수 프로토콜인 OpenSSL의 보안 취약점이였습니다. 하트블리드 버그에 영향받은 장비는 보안, 웹 및 인터넷 전화 (IP Telephony)까지 광범위합니다.
이 글을 쓰게 된 계기는 보안을 강조하면서도 비용 절감을 위해 유지보수 서비스를 구매하는 않아 발생되는 보안 위험성을 강조하기 위함입니다. 유지 보수 서비스를 구매하지 않는 것과 보안의 위험성이 어떤 관계가 있는 지를 살펴보기 위해 하트블리드 보안 취약점 발견 당시부터 지금까지의 상황을 복기해 보겠습니다.
우리나라 주요 보안 사고들
국내외 금융 기관에서 발생한 주요 정보보안 사고 유형 및 특징을 정리한 정보통신산업 진흥원의 자료를 보면 한국은 직원 및 협력업체 직원에 의한 정보유출이 가장 많고, 외국계 은행은 악성 공격(해킹)에 의한 유형이 많습니다.
금융 관련 기관 이외에 큰 사고는 2011년 7월 26일 네이트와 2014년 3월 6일 KT의 개인정보 유출 사건이였습니다.
우리나라는 다른 나라와 달리 사람에 의한 정보 유출이 자주 발생하는 보안 사고이므로 내부 직원 및 협력업체 직원에 대한 신뢰도가 없다는 가정 하에 이루어진 물리적인 보안 정책을 위주로 강화하였습니다. 특히, 금융기관은 정보를 다루는 국가 기관이나 기업 연구소 수준의 물리적인 보안 정책이 적용되었습니다. 금융기관과 공공기관의 보안은 스마트워크가 거의 불가능할 뿐만 아니라 평상시 업무를 보는 것도 불편한 수준으로 강화되었습니다. 일례로 장애가 발생한 상황해도 외부 노트북이 반입되지 않을 뿐만 아니라 협력업체 담당자에게 인터넷을 연결할 방안을 제공하지 않아 외국 최고 전문가를 원격으로 투입할 수도 없습니다. 사람에 의한 정보유출이 하도 많다보니 보안은 최상으로 유지하면서 업무 효율은 심각하게 저하된 된 상황입니다.
오픈소스 또는 애플리케이션 자체의 보안 결함인 하트블리드와 같은 버그는 물리적인 보안을 강화한다고 해결되지 않습니다. 이런 버그는 어떻게 대처할 지도 생각해 보겠습니다.
하트블리드 취약점의 초간단 이해
2014년 4월 7일 OpenSSL 프로토콜에서 하트블리드라 불리는 보안 취약점이 발견되었습니다. OpenSSL은 거의 모든 시스템에서 보안을 강화하기 위해 사용하는 필수 프로토콜로 웹 서버 및 다수의 애플리케이션 등에서 사용됩니다. 실제 발생할 가능성은 매우 낮지만, 최악의 경우 시스템의 루트 패스워드나 사용자 패스워드가 해커에게 공개될 위험이 있습니다. 사실 하트 블리드는 광범위하게 영향을 미치기에 인터넷 역사상 최악의 보안 결함이라는 평가를 받았습니다.
우리나라는 국가에서 주도적으로 최신 버전인 TLS 1.2 버전 사용을 권장하면서 피해가 많았습니다. 국내 주요 시스템의 약 56% 정도가 패치가 필요한 상황이였습니다. 또한, 하드블리드는 2011년에 출시된 TLS 1.2용 OpenSSL 버전의 소스코드에서 발견된 문제점으로 약 3년간 인지가 되지 않아 잠재적으로 위협이 매우 큰 결함으로 반드시 해결을 해야 했습니다.
하트블리드와 같은 취약점은 Open Source Library의 보안 결함이므로 패치를 통해 취약점을 해결한 새로운 OpenSource Library로 업데이트를 해야 합니다. 하지만, 기업이나 공공기관에서 사용하는 B2B 솔루션들에 대한 패치는 사이드 임팩트나 연동 솔루션과의 충돌 고려하여 패치를 적용하기 전에 충분한 테스트를 거쳐야 합니다. 즉, 해결책은 단순할 수 있지만 적용은 복잡합니다.
이해 당사자들의 대응
초점은 해결책을 찾는 것이 아니라 해결된 라이브러리를 모든 시스템에 적용하는 것입니다. 패치가 필요한 수많은 보안 장비와 서버 가운데 보안 강화를 위해 TLS 1.2를 적용한 인터넷 전화 시스템 (IP PBX, 전화기, 게이트웨이, SBC 등) 도 패치 버전을 설치해야 했습니다.
하트블리드의 직간접적인 영향을 받은 이해 당사자들이 공공기관의 Secure IP Telephony 솔루션에 보안 패치를 적용하기 위해 어떤 일들이 있었는 지를 복기해 보겠습니다.
- 정부의 대응 (공공기관이 모든 제품에 대한 OpenSSL 버전 확인과 패치 적용을 권고 )
취약점 발견일 로부터 10일 만에 정부 관계 부처가 만나서 첫 회의를 가졌고, 관련 문의를 KISA (한국 인터넷 진흥원, Korea Internet & security Agency) 를 중심으로 단일화하였습니다. KISA는 민간 기업및 공공기관은 제조사로 부터 제공받은 패치를 빠른 시일내에 적용할 것을 권고하였습니다. 공공기관은 운영중인 장비의 하트블리드 취약점 대상 여부를 확인하기 위해 OpenSSL 버전을 보고하도록 하였습니다.
제조사는 하트블리드 취약점에 노출된 제품을 웹페이지에 공시하였고, 패치의 출시 여부를 실시간으로 업데이트하였지만, 보안 관련 정부 기관의 요청 사항은 사용중인 OpenSSL 버전 확인이였고, 패치가 필요한 지 필요없는 지에 대한 것은 알고자 하지 않았습니다.
제조사의 하드웨어 또는 소프트웨어 버전에 따른 패치 여부만 공지 받아서 공공기관에 가이드를 제시해도 될 것이지만, 공공기관을 통한 OpenSSL 버전 확인과 그에 따른 패치 여부를 응답하기 위한 조치였습니다. - 제조사의 대응 (제품별 패치를 유지보수 계약과 상관없이 무료 공개)
하트블리드 취약점에 대한 제조사들의 해결책은 문제가 된 OpenSSL Library 버전을 문제가 해결된 OpenSSL Library 버전으로 대치하는 것입니다. 라이브러리가 교체되면 제조사는 정해진 프로세스에 의해 정상 동작 및 성능에 문제가 없는 지를 테스트하여 정식 버전으로 출시합니다. 제품이 많은 제조사는 2주에서 3주 정도 소요가 되었습니다.
제조사들은 4월 말즈음 대부분의 제품에 대한 패치 버전을 공개하였고, 제조사와의 유지보수 계약에 상관없이 하트블리드 취약점을 해결한 패치를 무료 배포하였습니다. - 공공기관의 대응 (쉽지 않은 패치 적용)
정부의 권고에 따라 하트블리드 버그가 발견된 OpenSSL 버전을 사용하는 제품의 패치 적용을 해야 했습니다. 각 공공기관의 관리자들은 패치 적용을 위해 기존 납품 업체나 제조사에 요청을 하기 시작했습니다.
발생일로 부터 약 4개월이 지난 2014년 8월이 다가도록 패치가 적용은 생각보다 느리게 진행되고 있었습니다. 패치 적용전에 연동 솔루션과의 충돌 문제나 사이드 임팩트 등을 테스트해야 했지만, 별도의 테스트 환경을 가지고 있지 않았습니다. 패치를 적용해야 할 시스템들이 유지보수 서비스가 없어서 관리자가 직접해야 하거나 유지보수 서비스가 단종된 버전을 여전히 사용하고 있어서 패치가 없는 경우도 있었습니다.
시간이 지남에 따라 하트블리드 취약점을 해결하기 위한 패치 작업이 제대로 진행되지 않은 이유를 공공기관의 관리자도, 정부 관계자도, 제조사도, 공공기관에 기술지원하는 협력업체 등의 모든 이해 당사자들이 알게 되었습니다.
하트블리드 취약점을 해결하다가 알게된 사실들
하트블리드 취약점 발견 후 제조사들이 발빠르게 대응했지만 기업과 공공기관의 현장에서는 여전히 패치 적용이 답보상태에 있었던 이유는 다음과 같이 요약할 수 있습니다.
- 제조사는 유지보수 서비스가 단종된 제품에 대한 패치를 만들 지 않는다
- 기업이나 공공기관의 관리자가 협력업체의 도움없이 패치를 적용하는 것은 불가능에 가깝다
- 한 시스템에 연동된 제품간의 사전 테스트를 위한 테스트베드 환경을 가진 곳이 많지 않았다.
- 많은 기관이 비용 절감을 이유로 주요 시스템에 대한 유지보수 계약을 체결하지 않았다.
하트블리드 문제를 해결하기 위해 정부는 빠른 패치 작업을 위한 제조사 간담회도 진행했고, 각 기관의 관리자에게 패치 적용을 독려하였습니다. 하지만 유지 보수 계약이 없는 기업이나 공공기관에 패치를 무료로 적용하고 시스템을 관리해줄 곳은 많지 않았습니다.
하트블리드 사태에서 우리는 무엇을 배웠어야 했는가?
2014년 이후 OpenSource 및 애플리케이션의 보안 취약점이 지속적으로 보고되고 있기에, 제조사들은 발견된 버그를 해결하여 신속하게 패치를 웹페이지에 업데이트 하고, 각 기관의 유지보수 업체는 패치를 다운로드 받아 연동 테스트를 진행하고, 관리자와 상의하여 적정한 시점에 실망에 적용합니다.
위의 진행 과정이 자연스럽게 진행되기 위해서는 각 기업이나 공공기관에서 다음과 같은 사항이 충분히 고려되어야 합니다.
- 테스트베드 구축
아무리 작은 규모라도 사용중인 시스템간 상호 운영성을 확보하기 위한 테스트베드가 있어야 합니다. 장비 테스트를 매번 실망에서 진행하는 것은 위험한 일입니다. - 유지보수 서비스가 지원되지 않는 소프트웨어의 최신 버전 업그레이드
단종된 하위 버전을 유지하는 것은 매우 위험한 환경입니다. 시스템이 고장이 나지 않는다는 이유로 업그레이드를 하지 않고 사용하는 것은 매우 위험한 일입니다. 하트블리드 사태와 같은 보안 취약점에 대응할 방법이 없습니다. - 유지보수 서비스 계약의 지속적인 유지
방화벽 및 주요 보안 장비들 뿐만 아니라 구동중인 주요 서비스는 반드시 유지보수 서비스를 유지해야 합니다. 갑작스런 보안 취약점 발생이나 장애 발생시에 답이 없습니다. 각 기업의 관리자가 아무리 뛰어나도 모든 사용 제품을 잘 다룰 수는 없으므로 솔루션마다 협력업체의 도움이 필요할 수 밖에 없습니다.
정부는 공공기관의 보안을 강화를 위해 통화에 대한 암호화를 적용하고, 행정기관 인터넷전화 보안 인증 제도를 강화하였고, 공공기관의 시스템 점검도 강화하고 있습니다. 이제는 암호화를 적용했는 지만 보지말고 유지보수 서비스가 유지되고 있는 지도 점검해야 합니다.
보안 강화의 기본은 새롭고 안전한 보안 기술을 적용하고 새로운 보안 정책을 설정하는 것뿐만 아니라 지속적인 유지보수 서비스를 계약을 유지하고 단종되지 않은 애플리케이션을 사용하는 것입니다. 유지보수 서비스는 비용절감을 위해 양보해야 한다면 기업의 보안 강화는 요원합니다.
2016년 병신년이 시작되었지만 하트블리드 패치가 적용하지 않은 곳도 있을 것이고, 지속적으로 발생되는 비슷한 사례로 인해 제조사가 제공하는 추가 보안 패치를 제 때 적용하지 못하는 곳도 있습니다.
마치며 - 곤이불학 민사위하의
우리는 하트블리드와 같은 보안 취약점 사고를 경험한 후 무엇을 시스템화하였을까요? 2년이 지난 지금 다시 생각해 볼 필요가 있을 것입니다. 아래의 글은 논어의 계시편에서 발췌한 것입니다.
生而知之者 上也(생이지지자 상야)
學而知之者 次也(학이지지자 차야)
困而學之 又其次也(곤이학지 우기차야)
困而不學 民斯爲下矣(곤이불학 민사위하의)
곤이불학 만사위하의의 뜻은 "곤란을 겪고도 배우지 못하는 자는 멍청이다"입니다.
지속적인 곤란이 발생할수 밖에 없는 구조에서는 빠르게 해결할 수 있는 시스템을 갖추어야 합니다. 새로운 유형의 사고가 발생한다면 대응 체계가 부족해서 해결하는 데 시간과 노력이 많이 필요할 수 밖에 없습니다. 하지만, 계속 발생되는 같은 유형의 사고에 제대로 대응할 수 없다는 것은 체계화된 대응 전략을 세워야 해결할 수 있습니다.
하트블리드에 대해 자세히 알고 싶다면
2014/04/17 - [Secure UC] - 하트블리드 (HeartBleed)에 대처하는 우리의 자세
참조자료
동아닷컴 : .kr 도메인 56% 하트블리드 취약 ... 정부 뒤늦게 대책마련
CIO Korea : 하트블리드 등장 한달 ... 여전히 30만대 서버 취약
보안뉴스 : 무적 하트블리드 ? 예방과 추적은 언제나 가능하다
위키트리 : 하트블리드
다음 블로그 한일짱 : 생이지지자 상야
라인하트 유씨누스 (CCIEV #18487) _________________________________________________________
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________
