2015.01.14

글로벌 칼럼 | 오픈소스의 '여러 개의 눈'은 실패했지만 소프트웨어 보안은 향상됐다

Eric Knorr | InfoWorld
개방성 자체가 더 안전한 코드를 생성하는 것은 아니지만, 주요 소프트웨어 개발자들이 오픈소스에 의존하게 되면서 해당 코드들은 더욱 엄격한 조사를 받을 수 있다.

2015년, 짐 젬린의 업무 우선 순위 가운데 하나는 보안이다. 리눅스 재단(Linux Foundation)의 전무인 젬린은 리눅스 재단 이외에도 클라우드 파운드리(Cloud Foundry), 오픈 데이라이트(Open Daylight), 타이젠(Tizen), 젠(Xen) 등에도 관여하고 있다. 또한 지난해 발견된 OpenSSL의 하트블리드(HeartBleed) 취약점에 대응하기 위해 구성된 CII(Core Infrastructure Initiative)에도 참여하고 있다.

지난 주, 필자는 젬린과 1시간 동안 해당 계획에 대한 대화를 나누었다.
IT 전문가라면 누구나 하트블리드에 대해 알고 있다. 해당 취약점은 2014년 3월에 구글 시큐리티(Google Security)의 닐 메타가 발견할 때까지 2년 동안 방치되어 있었다.

패치는 즉각적으로 공개됐다. 하지만 모든 OpenSSL 인스턴스를 추적해 패치를 제공할 때까지 수 개월이 소요됐고 시간이 지나면서 해당 취약점과 관련된 해킹 사건의 증거가 드러나기 시작했다. 이 가운데에는 450만 명이 영향을 받은 것으로 보고된 커뮤니티 헬스 서비스(Community Health Services, CHS)도 포함되어 있었다.

젬린이 인정했듯이, 커뮤니티가 감시하는 개방 코드는 폐쇄적인 소스보다 본질적으로 안전하다는 개념인 "여러 개의 눈(many eyes)"는 실패했다.

젬린은 "하트블리드에서 가장 큰 문제점은 해당 OpenSSL 프로젝트를, 암호화에 대한 전문 지식이 있고 수십 만 줄의 코드를 포함하는 프로젝트를 주도한 독립 컨설턴트인 스티븐 헨슨과 스티브 마커스, '2명의 스티브'가 유지했다는 것"이라고 말했다.

전문 지식은커녕 열정도 없이 해당 코드를 조사한 사람이 얼마나 많았던 것일까?
6개월 후, 관리자들은 1989년 이후로 오픈소스 배시(Bash) 프로젝트에 명백하게 숨겨져 있던 끔찍한 셸쇼크(Shellshock) 버그와 직면하게 되었다.

이 짧은 기간 동안 발생한 2건의 사건으로 인해 2014년은 오픈소스 보안에 치명적인 해가 되었다. 하지만 이와 동시에 2014년은 오픈소스가 소프트웨어를 위한 혁신의 엔진으로 더욱 명확하게 등장했다.

소프트웨어 보안의 필요성이 더욱 커질 수 있을까?
젬린의 말을 빌려 하트블리드에 대해 간략히 살펴보자. 젬린은 이 문제를 깨닫자마자 신속하게 CII를 구성했는데, 이에 AWS(Amazon Web Services), 어도비(Adobe), 블룸버그(Bloomberg), 시스코(Cisco), 델(Dell), 페이스북(Facebook), 후지쯔(Fujitsu), 구글(Google), 히타치(Hitachi), HP, 화웨이(Huawei), IBM, 인텔(Intel), 마이크로소프트(Microsoft), 넷앱(NetApp), NEC, 퀄컴(Qualcomm), 랙스페이스(Rackspace), 세일즈포스(Salesforce), VM웨어(VMware) 등이 등록해 최소 3년동안 10만 달러를 기부하기로 약속했다.

젬린은 이렇게 확보한 재정으로 '2명의 스티브'를 고용해 OpenSSL을 개발하도록 했다. 해당 계획의 일환으로 OCAP(Open Crypto Audit Project)는 OpenSSL 코드 베이스에 대한 지속적인 보안 감사를 실시하고 있다.

다시 말해, 기존에 평균 2,000달러의 기부금을 받던 OpenSSL 프로젝트를 기업들이 도입하게 된 것이다. 참여자가 충분하지는 않더라도 더 많은 사람들이 관심을 갖고 코드의 보안 확보에 관심을 기울이게 되었다. 해당 그룹은 하트블리드 참사를 계기로 OpenSSL을 중심으로 뭉치게 된 것이다.

하지만 지난 수년 동안, 파란을 불러 일으킨 오픈소스 프로젝트인 도커(Docker) 또는 큐버네츠(Kubernetes) 등은 초기부터 업계 큰 손들의 지원을 얻었으며, 오픈스택(OpenStack) 또는 오픈데이라이트(OpenDaylight) 등은 실질적으로 컨소시엄으로 시작됐다.

예를 들어, 오픈스택은 자체 VMT(Vulnerability Management Team)과 SG(Security Group)을 보유하고 있다.

그렇다고 해서 이런 프로젝트들이 완벽하게 안전한 코드를 생성하고 있을까? 물론, 그렇지 않다. 개발자들이 보안을 신경쓰도록 하는 일은 언제나 어려운 일이었으며, 그 이유는 단순히 흥미의 부재가 아니라 긴박한 보안과 사용성의 문제가 항상 조화를 이루지 못했기 때문이었다.

하지만 최근 이슈가 되고 있는 오픈소스 프로젝트의 '기업화(corporatization)'로 인해 OpenSSL처럼 자원이 부족하지만 필수적인 프로젝트가 시들해지면서 향후 보안 문제로 등장할 것이라고 생각한다.

예를 들어, 여러분이 도커에 대한 코어OS(CoreOS)의 로켓(Rocket) 도전에 대해 어떻게 생각하든 코어OS가 보안 측면에서 도커를 모방하는 일은 고무적이라 생각한다. 도커는 지난해 6월이 되어서야 1.0 버전을 공개했지만, 코어OS는 이런 논쟁이 확산될 수도 있음을 알고 있었을 것이다.

이런 행보가 선순환으로 이어지기를 기대해 본다. 마이크로소프트를 포함해 업계의 모든 대기업들은 오픈소스의 고속 혁신의 힘과 장점에 주목하고 있다.

실제로 현재 대형 소프트웨어 업체들은 보안이 그리 뛰어나지도 않다. 하지만 점차 업계 전체적으로 기본적인 수준의 오픈소스 기술 개발을 발전시키고 지원하기 위해 협력함으로써 개별 개발업체들이 차별화를 주도할 수 있도록 할 수 있다면 훨씬 신속하게 움직일 수 있다는 사실을 인지하고 있다.

이런 협업을 통해 1개의 개발업체가 달성할 수 있는 것보다 더욱 안전한 소프트웨어가 탄생할 수 있다.

지난 수년 동안 필자가 접한 정보를 생각해 볼 때, 오픈소스 또는 상용 소프트웨어 가운데 보안이 뛰어난 쪽을 꼽으라면 쉽게 어느 한쪽의 손을 들어줄 수가 없다.

여러 기업들이 오픈소스 프로젝트에 기여해 소프트웨어 보안을 전반적으로 향상시킬 수 있었으면 좋겠다. 그리고 마지막으로 기업 연합이 채택한 오픈소스 프로젝트는 2명의 스티브가 달성한 것보다 더 나은 보안 결과를 도출해야 할 것이다. editor@itworld.co.kr


2015.01.14

글로벌 칼럼 | 오픈소스의 '여러 개의 눈'은 실패했지만 소프트웨어 보안은 향상됐다

Eric Knorr | InfoWorld
개방성 자체가 더 안전한 코드를 생성하는 것은 아니지만, 주요 소프트웨어 개발자들이 오픈소스에 의존하게 되면서 해당 코드들은 더욱 엄격한 조사를 받을 수 있다.

2015년, 짐 젬린의 업무 우선 순위 가운데 하나는 보안이다. 리눅스 재단(Linux Foundation)의 전무인 젬린은 리눅스 재단 이외에도 클라우드 파운드리(Cloud Foundry), 오픈 데이라이트(Open Daylight), 타이젠(Tizen), 젠(Xen) 등에도 관여하고 있다. 또한 지난해 발견된 OpenSSL의 하트블리드(HeartBleed) 취약점에 대응하기 위해 구성된 CII(Core Infrastructure Initiative)에도 참여하고 있다.

지난 주, 필자는 젬린과 1시간 동안 해당 계획에 대한 대화를 나누었다.
IT 전문가라면 누구나 하트블리드에 대해 알고 있다. 해당 취약점은 2014년 3월에 구글 시큐리티(Google Security)의 닐 메타가 발견할 때까지 2년 동안 방치되어 있었다.

패치는 즉각적으로 공개됐다. 하지만 모든 OpenSSL 인스턴스를 추적해 패치를 제공할 때까지 수 개월이 소요됐고 시간이 지나면서 해당 취약점과 관련된 해킹 사건의 증거가 드러나기 시작했다. 이 가운데에는 450만 명이 영향을 받은 것으로 보고된 커뮤니티 헬스 서비스(Community Health Services, CHS)도 포함되어 있었다.

젬린이 인정했듯이, 커뮤니티가 감시하는 개방 코드는 폐쇄적인 소스보다 본질적으로 안전하다는 개념인 "여러 개의 눈(many eyes)"는 실패했다.

젬린은 "하트블리드에서 가장 큰 문제점은 해당 OpenSSL 프로젝트를, 암호화에 대한 전문 지식이 있고 수십 만 줄의 코드를 포함하는 프로젝트를 주도한 독립 컨설턴트인 스티븐 헨슨과 스티브 마커스, '2명의 스티브'가 유지했다는 것"이라고 말했다.

전문 지식은커녕 열정도 없이 해당 코드를 조사한 사람이 얼마나 많았던 것일까?
6개월 후, 관리자들은 1989년 이후로 오픈소스 배시(Bash) 프로젝트에 명백하게 숨겨져 있던 끔찍한 셸쇼크(Shellshock) 버그와 직면하게 되었다.

이 짧은 기간 동안 발생한 2건의 사건으로 인해 2014년은 오픈소스 보안에 치명적인 해가 되었다. 하지만 이와 동시에 2014년은 오픈소스가 소프트웨어를 위한 혁신의 엔진으로 더욱 명확하게 등장했다.

소프트웨어 보안의 필요성이 더욱 커질 수 있을까?
젬린의 말을 빌려 하트블리드에 대해 간략히 살펴보자. 젬린은 이 문제를 깨닫자마자 신속하게 CII를 구성했는데, 이에 AWS(Amazon Web Services), 어도비(Adobe), 블룸버그(Bloomberg), 시스코(Cisco), 델(Dell), 페이스북(Facebook), 후지쯔(Fujitsu), 구글(Google), 히타치(Hitachi), HP, 화웨이(Huawei), IBM, 인텔(Intel), 마이크로소프트(Microsoft), 넷앱(NetApp), NEC, 퀄컴(Qualcomm), 랙스페이스(Rackspace), 세일즈포스(Salesforce), VM웨어(VMware) 등이 등록해 최소 3년동안 10만 달러를 기부하기로 약속했다.

젬린은 이렇게 확보한 재정으로 '2명의 스티브'를 고용해 OpenSSL을 개발하도록 했다. 해당 계획의 일환으로 OCAP(Open Crypto Audit Project)는 OpenSSL 코드 베이스에 대한 지속적인 보안 감사를 실시하고 있다.

다시 말해, 기존에 평균 2,000달러의 기부금을 받던 OpenSSL 프로젝트를 기업들이 도입하게 된 것이다. 참여자가 충분하지는 않더라도 더 많은 사람들이 관심을 갖고 코드의 보안 확보에 관심을 기울이게 되었다. 해당 그룹은 하트블리드 참사를 계기로 OpenSSL을 중심으로 뭉치게 된 것이다.

하지만 지난 수년 동안, 파란을 불러 일으킨 오픈소스 프로젝트인 도커(Docker) 또는 큐버네츠(Kubernetes) 등은 초기부터 업계 큰 손들의 지원을 얻었으며, 오픈스택(OpenStack) 또는 오픈데이라이트(OpenDaylight) 등은 실질적으로 컨소시엄으로 시작됐다.

예를 들어, 오픈스택은 자체 VMT(Vulnerability Management Team)과 SG(Security Group)을 보유하고 있다.

그렇다고 해서 이런 프로젝트들이 완벽하게 안전한 코드를 생성하고 있을까? 물론, 그렇지 않다. 개발자들이 보안을 신경쓰도록 하는 일은 언제나 어려운 일이었으며, 그 이유는 단순히 흥미의 부재가 아니라 긴박한 보안과 사용성의 문제가 항상 조화를 이루지 못했기 때문이었다.

하지만 최근 이슈가 되고 있는 오픈소스 프로젝트의 '기업화(corporatization)'로 인해 OpenSSL처럼 자원이 부족하지만 필수적인 프로젝트가 시들해지면서 향후 보안 문제로 등장할 것이라고 생각한다.

예를 들어, 여러분이 도커에 대한 코어OS(CoreOS)의 로켓(Rocket) 도전에 대해 어떻게 생각하든 코어OS가 보안 측면에서 도커를 모방하는 일은 고무적이라 생각한다. 도커는 지난해 6월이 되어서야 1.0 버전을 공개했지만, 코어OS는 이런 논쟁이 확산될 수도 있음을 알고 있었을 것이다.

이런 행보가 선순환으로 이어지기를 기대해 본다. 마이크로소프트를 포함해 업계의 모든 대기업들은 오픈소스의 고속 혁신의 힘과 장점에 주목하고 있다.

실제로 현재 대형 소프트웨어 업체들은 보안이 그리 뛰어나지도 않다. 하지만 점차 업계 전체적으로 기본적인 수준의 오픈소스 기술 개발을 발전시키고 지원하기 위해 협력함으로써 개별 개발업체들이 차별화를 주도할 수 있도록 할 수 있다면 훨씬 신속하게 움직일 수 있다는 사실을 인지하고 있다.

이런 협업을 통해 1개의 개발업체가 달성할 수 있는 것보다 더욱 안전한 소프트웨어가 탄생할 수 있다.

지난 수년 동안 필자가 접한 정보를 생각해 볼 때, 오픈소스 또는 상용 소프트웨어 가운데 보안이 뛰어난 쪽을 꼽으라면 쉽게 어느 한쪽의 손을 들어줄 수가 없다.

여러 기업들이 오픈소스 프로젝트에 기여해 소프트웨어 보안을 전반적으로 향상시킬 수 있었으면 좋겠다. 그리고 마지막으로 기업 연합이 채택한 오픈소스 프로젝트는 2명의 스티브가 달성한 것보다 더 나은 보안 결과를 도출해야 할 것이다. editor@itworld.co.kr


X