글로벌 칼럼 | 믿었던 '오픈소스 라이브러리'에 뒷통수 맞는다
OSS
게시글 작성 시각 2015-01-08 17:12:44
2015년 01월 02일 (금)
ⓒ ITWorld, Lucian Constantin | IDG News Service
서드파티 소프트웨어 라이브러리의 결함이 제품의 하자로 이어지는 경우가 많다. 이는 개발자와 시스템 관리자에게는 큰 문제가 될 수도 있다.
애자일 소프트웨어 개발과 제품 출시 주기가 짧아짐에 따라 서드파티 라이브러리와 컴포넌트로 작업하는 개발자가 증가하는 추세다. 개발자가 활용하는 많은 라이브러리는 장기간 추진된 오프소스 프로젝트로부터 만들어진 ‘산물’이기 때문이다. 장기간에 걸쳐 보수된 만큼 개발자들은 당연히 이들 라이브러리의 품질이 우수하고, 버그도 없을 것으로 생각한다. 하지만 이는 잘못된 생각이다.
지난 2014년 하트블리드(Heartbleed), 셸쇼크(Shellshock), 푸들(POODLE) 결함으로 촉발된 대규모 패칭 배포는 서드파티가 제공하는 소스 코드에 중대한 취약점이 있음을 시사한다. 이런 결함은 서버와 데스크톱 컴퓨터, 모바일 기기, 하드웨어 어플라이언스에서 실행되는 소프트웨어를 통해 수백만의 소비자와 기업에 영향을 미쳤다.
이처럼 비교적 규모가 큰 사고로 인해 잘 알려진 취약점 외에도 숨겨진 ‘폭탄’은 많다. OpenSSL, LibTIFF, Libpng, OpenJPEG, FFmpeg, Libav 등 많은 라이브러리에서 앞서 언급한 비슷한 결함이 발견됐다. 오랜 시간에 걸쳐 다수의 제품에 반영된 라이브러리들이다.
최종 버전의 제품에서 버그가 발견된 이유 가운데 하나는 개발자들의 잘못된 통념 때문이다. 개발자들은 많은 이들이 사용하고 있다는 이유로 서드파티 코드가 안전하다고 믿고, 이를 개발에 십분 활용해왔다.
버그와 관련된 통념
취약점 추적 전문 회사인 리스크드 베이스드 시큐리티(Risk Based Security)의 CISO 인 제이크 쿤즈는 "누구나 검토를 할 수 있고, 취약점을 없앨 '눈'이 많아서 오픈소스는 안전하다고 여기는 통념이 존재한다. 그러나 현실은 다르다. 누구나 코드를 확인할 수 있지만, 누구나 이를 실천하는 것은 아니다. 또 이 때문에 누구도 품질을 책임지지 않는 경향이 있다. 다시 말해, 개발자와 기업은 서드파티 라이브러리를 사용하면서 자신의 자원을 투자해 보안을 점검하지 않는다. 다른 사람이 개발한 코드이기 때문이다. 모든 사람이 다른 누군가가 취약점을 발견할 것이며, 완성된 코드는 안전하다고 생각한다"고 지적했다.
재원과 인력 투자가 미흡한 오픈 소스 프로젝트가 많은 것이 현실이다. 심지어는 인터넷 인프라에 중요한 코드와 관련된 프로젝트도 마찬가지이다. 전문적인 코드 감사에 필요한 자원이 투자되지 않는다. 구식 코드를 개선하기 위한 인력 투자도 마찬가지이다.
OpenSSL이 대표적인 사례이다. 이 밖에도 많은 사례가 있다. 지난 4월 하트블리드 버그가 공개된 이후, OpenSSL 프로젝트에 투입된 풀타임 개발자는 단 한 명뿐이었다는 사실도 알려졌다. 또 OpenSSL은 계약에 바탕을 둔 프로젝트로, 전담 개발자 이외의 팀원들은 SSL/TLS 전문가가 필요한 회사들을 위해 남는 시간에 작업했다.
OpenBSD 개발자들은 OpenSSL이 소수만 중시하는 플랫폼의 구식 코드를 적용했으며, 이에 더 깨끗한 LibreSSL를 파생시키기로 했다고 비판을 했다.
리스크 베이스드 시큐리티의 최고 연구 책임자인 카스텐 에이람자에 따르면, 구식 코드, 성숙기에 접어들지 못한 코드, 미흡한 감사 또는 퍼징(애플리케이션에 자동으로 무작위 인풋을 피딩 해 취약점을 찾는 프로세스), 소수의 유지보수 관리자 등이 오픈소스 라이브러리의 결함을 초래하는 요인들이다. 에이람은 "최신 버전의 퍼저(Fuzzer)를 실행시키는 것만으로도 많은 취약점을 발견할 수 있다. 이는 문제의 라이브러리를 이용하는 기업이나 유지보수 관리자 스스로가 처리할 수 있는 작업들이다. 소프트웨어 업체들은 이들 라이브러리를 신속하게 제품에 반영한다. 그러나 감사나 퍼징을 하는 경우는 아주 드물다"고 말했다.
결국은 마케팅!
하트블리드, 셸쇼크, 푸들 취약점은 소프트웨어 개발자와 시스템 관리자들의 관심을 불러일으켰다. 그리고 미디어도 어느 정도 일조한 부분도 있기도 하다. 지금도 이들 취약점에 영향을 받은 제품을 파악하느라 분주한 업체들이 존재한다. 이들은 취약점이 알려지고 몇 달이 지나서야 패치를 배포했다.
에이람에 따르면, 이들 취약점에 관심이 쏠린 주된 이유는 '파급력'이 아닌, 이 취약점을 발견한 사람의 ‘광고’ 때문이다. 사실 이보다 더 널리 보급된 라이브러리에도 이와 비슷한 수준의 취약점이 주기적으로 발견되고는 하지만, 한 곳에만 관심이 집중되는 경우는 드물다. 해당 라이브러리를 적용한 소프트웨어 업체가 패치를 발표하는 것도 역시 흔한 사례는 아니다.
에이람은 "하트블리드 이후 OpenSSL에서도 18개라는 많은 취약점이 발견됐다. 그러나 업체가 신속하게 패치를 배포한 경우는 아주 드물다. 패치를 배포하지 않은 경우도 있다"고 말했다. 또, "우리는 거의 매일 다양한 위험도의 라이브러리 수정 내용을 확인한다. 그러나 해당 라이브러리를 제품에 통합시킨 업체가 수정 버전을 배포하는 경우는 아주 드물다. 다수의 라이브러리를 사용하는 업체들도 다를 바 없다”고 지적했다.
현재 구글의 보안 연구원으로 재직 중인 타비스 올만디가 2006년 발견한 취약점이 이와 관련된 사례가 될 수 있다. LibTIFF에 영향을 미친 취약점 가운데 하나였다, 당시 새로 배포된 버전에서는 해당 취약점이 수정됐다. CVE(Common Vulnerabilities and Exposures) 데이터베이스에 CVE-2006-3459로 기록되어 있는 취약점이다.
에이람은 "2010년 어도비 리더(Adobe Reader)의 취약점 하나가 해결됐었다. 그런데 CVE-2006-3459에 해당하는 취약점 가운데 하나였다. 취약점이 발견되고 4년이 흘렀지만, 어도비 리더에 구식의 취약한 LibTIFF가 적용되어 있었기 때문이다. 심지어는 이 취약점이 악용될 수 있었던 것으로 밝혀지기도 했다"고 말했다.
어도비 시스템(Adobe Systems)은 이후 서드파티 컴포넌트의 취약점이 초래하는 위험을 중시하는 소프트웨어 개발 업체로 거듭났다. 에이람은 "어도비 시스템은 자신들의 제품에 이용한 서드파티 라이브러리와 컴포넌트의 취약점을 추적해 해결하는 프로세스를 크게 개선했다"고 말했다.
구글 또한 이와 같은 업체 가운데 하나다. 구글은 서드파티 코드의 결함을 추적하는 것뿐만 아니라 코드의 취약점을 적극적으로 찾고 있다.
에이람은 "구글의 진밸 콜드윈드와 마테우즈 주르치크는 크롬에 사용된 FFmpeg 및 Libav에서 1,000여개의 문제를 발견했다. 지금은 FreeType 등 다른 라이브러리를 조사하고 있다"고 말했다. 또, "구글은 현재 OpenJPEG를 조사하고 있는데, 이는 크롬에 쓰일 PDFium에 사용될 라이브러리이다. 구글은 OpenJPEG를 크롬 엔진으로 사용하기 시작하면서 웹킷 보안 구현에 상당한 노력을 기울이고 있다"고 덧붙였다.
이는 다른 사람들이 이들 라이브러리를 더욱 완전하게 사용할 수 있도록 도움을 준다. 소프트웨어 개발 업체들도 이런 노력을 기울여야 한다.
퍼징을 이용해 사용한 라이브러리를 테스트하고, 이 과정에 발견한 문제를 수정하기만 해도 큰 차이를 만들 수 있다. 아직 라이브러리 취약점 발견에 있어서는 큰 영향을 초래하지 못하고 있는 핵심 인터넷 소프트웨어용 버그 바운티 프로그램 역시 마찬가지이다. 구글과 해커원(Hacker One) 등이 이를 활용하고 있다.
정확한 BOM(Bill Of Materials)
불행하게도 갈 길이 멀다. 나중에야 컴포넌트의 취약점을 발견해 패칭을 하는 것은 말할 것도 없고, 사용하고 있는 서드파티 컴포넌트 종류와 장소 추적도 제대로 못 하는 소프트웨어 개발자들이 많기 때문이다.
클라우드 기반의 취약점 검사 서비스를 제공하는 보안 회사인 베라코드(Veracode)는 서드파티 및 오픈소스 컴포넌트로 각 애플리케이션에 초래되는 취약점은 평균 24개며, 일부 기업의 경우 사용하는 애플리케이션의 40%에 중대한 취약점이 초래된다는 조사 결과를 발표했다.
베라코드의 조사 담당 부사장인 크리스 앙은 "하트블리드와 셸쇼크를 패칭하면서 교훈을 터득한 기업이 많다”며, “서버는 물론 취약한 하드웨어와 소프트웨어 제품도 패칭하는 것이 도전과제다”고 말했다. 그러나 “'취약한 OpenSSL 버전을 이용하는 제품은 뭘까?'라는 질문에 제대로 대답을 못 하는 기업이 많다”며, 소프트웨어 제품의 구조를 제대로 파악하지 못하기 때문”이라고 지적했다.
크리스 앙은 "모든 소프트웨어 프로젝트를 대상으로 BOM을 정확히 파악하는 것이 패칭에 있어 아주 중요하다. 과거에도 중요했던 부분이다. 그러나 하트블리드 및 셸쇼크가 이 문제를 더욱 크게 부각했다. OpenSSL과 Bash가 많이 사용되고 있기 때문이다"고 고 덧붙였다.
시스템 관리자에게는 더욱 복잡한 상황이 연출된다. 소프트웨어 개발 업체의 수정 버전을 이용해야 하고, 서드파티 컴포넌트의 결함에 대한 대응 속도에 차이가 크기 때문이다.
에이람은 "소프트웨어 산업은 이런 위협을 인식하고 있으며, 대기업을 중심으로 이를 극복하기 위한 노력을 기울이고 있다. 그러나 코드에서 사용한 라이브러리를 파악하고, 이들 라이브러리의 취약점을 추적하기 위해서는 상당한 자원 투자 필요하다"고 말했다.
더 많은 대비
하트블리드와 셸쇼크로 바뀐 점이 하나 있다. 보안 전문가들이 자신이 발견한 결함을 많은 청중에 도달할 수 있게 하는 모델(일종의 광고다)을 갖게 됐다는 점이다. 보안 산업에는 이런 방식에 동의하지 않는 사람들이 많다. 위험을 부풀릴 수 있기 때문이다. 그러나 한편으로는 개발 업체가 행동을 하도록 압력을 넣는 요소이다. 또 더 많은 관심을 끌어 단기간에 라이브러리를 더욱 자세히 조사하게끔 유도하고 있다.
크리스 앙은 "파급력이 큰 취약점을 찾는 전문가들은 널리 보급이 되어 있으며, 다양한 제품에 이용되고 있는 소프트웨어에 관심을 기울이게 될 것이다. 이런 추세가 계속될 것으로 판단하고 있다. 중대한 버그를 발견해 미디어의 관심을 유발하는데 동기 부여를 받는 전문가들이 많기 때문이다"고 설명했다.
비즈니스 관점에서 보자면, 하트블리드 같은 취약점에 대처하기 위해 다른 곳에 할당한 자원을 갑작스레 재배치하는 것은 소프트웨어 업체에 큰 부담이 될 수 있다. 정기적으로 크게 '광고'된 취약점을 직면할 경우, 업체들은 더 적극적인 전략을 도입할 수밖에 없다. 여기에는 서드파티 컴포넌트의 취약점을 추적, 패칭, 더 나아가 찾는 전략이 포함된다.
에이람은 "서드파티 라이브러리와 컴포넌트에 대처하는 문제를 논의하는 소프트웨어 기업들이 증가하고 있다. 이들은 이를 아킬레스건으로 인식하고 있다"고 말했다. 그는 또 "물론 대다수는 이런 도전을 극복할 수 있는 정책과 방법론을 도입해야 하는 상황이다"고 덧붙였다.
기업들은 서드파티 라이브러리가 포함된 제품을 파악하고, 제품에 컴포넌트를 추가하는 사람과 방법에 관한 정책을 수립하고, 라이브러리를 이용하기에 앞서 다양한 취약점 데이터베이스를 조사해 보안 상태를 파악해야 하고, 내부에서 활용할 취약점 추적 솔루션을 개발하고, 많은 라이브러리를 다루는 상용 솔루션을 구매해야 한다.
앙은 "장기적으로 변화가 있을 전망이다. 그러나 개발자들은 아직까지도 하트블리드와 셸쇼크를 하나의 추세가 아닌 별개의 사건으로 간주하고 있다."고 지적했다. 그러나 앙은 “한편에서는 자동화된 솔루션 덕분에 기업들이 더욱 쉽게 알려진 취약점이 있는 컴포넌트(애플리케이션에 포함된)를 파악할 수 있다"며, "앞으로는 예방적인 방법들이 베스트 사례가 될 것"이라고 말했다.
테너블 네트워크 시큐리티(Tenable Network Security)의 EME 지역 기술 디렉터인 가빈 밀라드는 "기업들은 2014년 동안 확인한 '버그의 심각성'이 2015년에도 계속될 것이라는 점을 인식해야 한다. 또 취약점이 존재하는 장소를 신속하게 파악하는 프로세스를 수립하고, 버그를 발견했을 때 위험을 줄일 수 있도록 문제의 우선순위를 정하는 절차, 효율적으로 패칭을 하는 프로세스를 만들어야 한다. 향후 버그 관련 문제가 발생했을 때, 이에 신속하게 대처하는 방법과 체계를 수립해 점검해야 한다"고 강조했다.
애자일 소프트웨어 개발과 제품 출시 주기가 짧아짐에 따라 서드파티 라이브러리와 컴포넌트로 작업하는 개발자가 증가하는 추세다. 개발자가 활용하는 많은 라이브러리는 장기간 추진된 오프소스 프로젝트로부터 만들어진 ‘산물’이기 때문이다. 장기간에 걸쳐 보수된 만큼 개발자들은 당연히 이들 라이브러리의 품질이 우수하고, 버그도 없을 것으로 생각한다. 하지만 이는 잘못된 생각이다.
지난 2014년 하트블리드(Heartbleed), 셸쇼크(Shellshock), 푸들(POODLE) 결함으로 촉발된 대규모 패칭 배포는 서드파티가 제공하는 소스 코드에 중대한 취약점이 있음을 시사한다. 이런 결함은 서버와 데스크톱 컴퓨터, 모바일 기기, 하드웨어 어플라이언스에서 실행되는 소프트웨어를 통해 수백만의 소비자와 기업에 영향을 미쳤다.
이처럼 비교적 규모가 큰 사고로 인해 잘 알려진 취약점 외에도 숨겨진 ‘폭탄’은 많다. OpenSSL, LibTIFF, Libpng, OpenJPEG, FFmpeg, Libav 등 많은 라이브러리에서 앞서 언급한 비슷한 결함이 발견됐다. 오랜 시간에 걸쳐 다수의 제품에 반영된 라이브러리들이다.
최종 버전의 제품에서 버그가 발견된 이유 가운데 하나는 개발자들의 잘못된 통념 때문이다. 개발자들은 많은 이들이 사용하고 있다는 이유로 서드파티 코드가 안전하다고 믿고, 이를 개발에 십분 활용해왔다.
버그와 관련된 통념
취약점 추적 전문 회사인 리스크드 베이스드 시큐리티(Risk Based Security)의 CISO 인 제이크 쿤즈는 "누구나 검토를 할 수 있고, 취약점을 없앨 '눈'이 많아서 오픈소스는 안전하다고 여기는 통념이 존재한다. 그러나 현실은 다르다. 누구나 코드를 확인할 수 있지만, 누구나 이를 실천하는 것은 아니다. 또 이 때문에 누구도 품질을 책임지지 않는 경향이 있다. 다시 말해, 개발자와 기업은 서드파티 라이브러리를 사용하면서 자신의 자원을 투자해 보안을 점검하지 않는다. 다른 사람이 개발한 코드이기 때문이다. 모든 사람이 다른 누군가가 취약점을 발견할 것이며, 완성된 코드는 안전하다고 생각한다"고 지적했다.
재원과 인력 투자가 미흡한 오픈 소스 프로젝트가 많은 것이 현실이다. 심지어는 인터넷 인프라에 중요한 코드와 관련된 프로젝트도 마찬가지이다. 전문적인 코드 감사에 필요한 자원이 투자되지 않는다. 구식 코드를 개선하기 위한 인력 투자도 마찬가지이다.
OpenSSL이 대표적인 사례이다. 이 밖에도 많은 사례가 있다. 지난 4월 하트블리드 버그가 공개된 이후, OpenSSL 프로젝트에 투입된 풀타임 개발자는 단 한 명뿐이었다는 사실도 알려졌다. 또 OpenSSL은 계약에 바탕을 둔 프로젝트로, 전담 개발자 이외의 팀원들은 SSL/TLS 전문가가 필요한 회사들을 위해 남는 시간에 작업했다.
OpenBSD 개발자들은 OpenSSL이 소수만 중시하는 플랫폼의 구식 코드를 적용했으며, 이에 더 깨끗한 LibreSSL를 파생시키기로 했다고 비판을 했다.
리스크 베이스드 시큐리티의 최고 연구 책임자인 카스텐 에이람자에 따르면, 구식 코드, 성숙기에 접어들지 못한 코드, 미흡한 감사 또는 퍼징(애플리케이션에 자동으로 무작위 인풋을 피딩 해 취약점을 찾는 프로세스), 소수의 유지보수 관리자 등이 오픈소스 라이브러리의 결함을 초래하는 요인들이다. 에이람은 "최신 버전의 퍼저(Fuzzer)를 실행시키는 것만으로도 많은 취약점을 발견할 수 있다. 이는 문제의 라이브러리를 이용하는 기업이나 유지보수 관리자 스스로가 처리할 수 있는 작업들이다. 소프트웨어 업체들은 이들 라이브러리를 신속하게 제품에 반영한다. 그러나 감사나 퍼징을 하는 경우는 아주 드물다"고 말했다.
결국은 마케팅!
하트블리드, 셸쇼크, 푸들 취약점은 소프트웨어 개발자와 시스템 관리자들의 관심을 불러일으켰다. 그리고 미디어도 어느 정도 일조한 부분도 있기도 하다. 지금도 이들 취약점에 영향을 받은 제품을 파악하느라 분주한 업체들이 존재한다. 이들은 취약점이 알려지고 몇 달이 지나서야 패치를 배포했다.
에이람에 따르면, 이들 취약점에 관심이 쏠린 주된 이유는 '파급력'이 아닌, 이 취약점을 발견한 사람의 ‘광고’ 때문이다. 사실 이보다 더 널리 보급된 라이브러리에도 이와 비슷한 수준의 취약점이 주기적으로 발견되고는 하지만, 한 곳에만 관심이 집중되는 경우는 드물다. 해당 라이브러리를 적용한 소프트웨어 업체가 패치를 발표하는 것도 역시 흔한 사례는 아니다.
에이람은 "하트블리드 이후 OpenSSL에서도 18개라는 많은 취약점이 발견됐다. 그러나 업체가 신속하게 패치를 배포한 경우는 아주 드물다. 패치를 배포하지 않은 경우도 있다"고 말했다. 또, "우리는 거의 매일 다양한 위험도의 라이브러리 수정 내용을 확인한다. 그러나 해당 라이브러리를 제품에 통합시킨 업체가 수정 버전을 배포하는 경우는 아주 드물다. 다수의 라이브러리를 사용하는 업체들도 다를 바 없다”고 지적했다.
현재 구글의 보안 연구원으로 재직 중인 타비스 올만디가 2006년 발견한 취약점이 이와 관련된 사례가 될 수 있다. LibTIFF에 영향을 미친 취약점 가운데 하나였다, 당시 새로 배포된 버전에서는 해당 취약점이 수정됐다. CVE(Common Vulnerabilities and Exposures) 데이터베이스에 CVE-2006-3459로 기록되어 있는 취약점이다.
에이람은 "2010년 어도비 리더(Adobe Reader)의 취약점 하나가 해결됐었다. 그런데 CVE-2006-3459에 해당하는 취약점 가운데 하나였다. 취약점이 발견되고 4년이 흘렀지만, 어도비 리더에 구식의 취약한 LibTIFF가 적용되어 있었기 때문이다. 심지어는 이 취약점이 악용될 수 있었던 것으로 밝혀지기도 했다"고 말했다.
어도비 시스템(Adobe Systems)은 이후 서드파티 컴포넌트의 취약점이 초래하는 위험을 중시하는 소프트웨어 개발 업체로 거듭났다. 에이람은 "어도비 시스템은 자신들의 제품에 이용한 서드파티 라이브러리와 컴포넌트의 취약점을 추적해 해결하는 프로세스를 크게 개선했다"고 말했다.
구글 또한 이와 같은 업체 가운데 하나다. 구글은 서드파티 코드의 결함을 추적하는 것뿐만 아니라 코드의 취약점을 적극적으로 찾고 있다.
에이람은 "구글의 진밸 콜드윈드와 마테우즈 주르치크는 크롬에 사용된 FFmpeg 및 Libav에서 1,000여개의 문제를 발견했다. 지금은 FreeType 등 다른 라이브러리를 조사하고 있다"고 말했다. 또, "구글은 현재 OpenJPEG를 조사하고 있는데, 이는 크롬에 쓰일 PDFium에 사용될 라이브러리이다. 구글은 OpenJPEG를 크롬 엔진으로 사용하기 시작하면서 웹킷 보안 구현에 상당한 노력을 기울이고 있다"고 덧붙였다.
이는 다른 사람들이 이들 라이브러리를 더욱 완전하게 사용할 수 있도록 도움을 준다. 소프트웨어 개발 업체들도 이런 노력을 기울여야 한다.
퍼징을 이용해 사용한 라이브러리를 테스트하고, 이 과정에 발견한 문제를 수정하기만 해도 큰 차이를 만들 수 있다. 아직 라이브러리 취약점 발견에 있어서는 큰 영향을 초래하지 못하고 있는 핵심 인터넷 소프트웨어용 버그 바운티 프로그램 역시 마찬가지이다. 구글과 해커원(Hacker One) 등이 이를 활용하고 있다.
정확한 BOM(Bill Of Materials)
불행하게도 갈 길이 멀다. 나중에야 컴포넌트의 취약점을 발견해 패칭을 하는 것은 말할 것도 없고, 사용하고 있는 서드파티 컴포넌트 종류와 장소 추적도 제대로 못 하는 소프트웨어 개발자들이 많기 때문이다.
클라우드 기반의 취약점 검사 서비스를 제공하는 보안 회사인 베라코드(Veracode)는 서드파티 및 오픈소스 컴포넌트로 각 애플리케이션에 초래되는 취약점은 평균 24개며, 일부 기업의 경우 사용하는 애플리케이션의 40%에 중대한 취약점이 초래된다는 조사 결과를 발표했다.
베라코드의 조사 담당 부사장인 크리스 앙은 "하트블리드와 셸쇼크를 패칭하면서 교훈을 터득한 기업이 많다”며, “서버는 물론 취약한 하드웨어와 소프트웨어 제품도 패칭하는 것이 도전과제다”고 말했다. 그러나 “'취약한 OpenSSL 버전을 이용하는 제품은 뭘까?'라는 질문에 제대로 대답을 못 하는 기업이 많다”며, 소프트웨어 제품의 구조를 제대로 파악하지 못하기 때문”이라고 지적했다.
크리스 앙은 "모든 소프트웨어 프로젝트를 대상으로 BOM을 정확히 파악하는 것이 패칭에 있어 아주 중요하다. 과거에도 중요했던 부분이다. 그러나 하트블리드 및 셸쇼크가 이 문제를 더욱 크게 부각했다. OpenSSL과 Bash가 많이 사용되고 있기 때문이다"고 고 덧붙였다.
시스템 관리자에게는 더욱 복잡한 상황이 연출된다. 소프트웨어 개발 업체의 수정 버전을 이용해야 하고, 서드파티 컴포넌트의 결함에 대한 대응 속도에 차이가 크기 때문이다.
에이람은 "소프트웨어 산업은 이런 위협을 인식하고 있으며, 대기업을 중심으로 이를 극복하기 위한 노력을 기울이고 있다. 그러나 코드에서 사용한 라이브러리를 파악하고, 이들 라이브러리의 취약점을 추적하기 위해서는 상당한 자원 투자 필요하다"고 말했다.
더 많은 대비
하트블리드와 셸쇼크로 바뀐 점이 하나 있다. 보안 전문가들이 자신이 발견한 결함을 많은 청중에 도달할 수 있게 하는 모델(일종의 광고다)을 갖게 됐다는 점이다. 보안 산업에는 이런 방식에 동의하지 않는 사람들이 많다. 위험을 부풀릴 수 있기 때문이다. 그러나 한편으로는 개발 업체가 행동을 하도록 압력을 넣는 요소이다. 또 더 많은 관심을 끌어 단기간에 라이브러리를 더욱 자세히 조사하게끔 유도하고 있다.
크리스 앙은 "파급력이 큰 취약점을 찾는 전문가들은 널리 보급이 되어 있으며, 다양한 제품에 이용되고 있는 소프트웨어에 관심을 기울이게 될 것이다. 이런 추세가 계속될 것으로 판단하고 있다. 중대한 버그를 발견해 미디어의 관심을 유발하는데 동기 부여를 받는 전문가들이 많기 때문이다"고 설명했다.
비즈니스 관점에서 보자면, 하트블리드 같은 취약점에 대처하기 위해 다른 곳에 할당한 자원을 갑작스레 재배치하는 것은 소프트웨어 업체에 큰 부담이 될 수 있다. 정기적으로 크게 '광고'된 취약점을 직면할 경우, 업체들은 더 적극적인 전략을 도입할 수밖에 없다. 여기에는 서드파티 컴포넌트의 취약점을 추적, 패칭, 더 나아가 찾는 전략이 포함된다.
에이람은 "서드파티 라이브러리와 컴포넌트에 대처하는 문제를 논의하는 소프트웨어 기업들이 증가하고 있다. 이들은 이를 아킬레스건으로 인식하고 있다"고 말했다. 그는 또 "물론 대다수는 이런 도전을 극복할 수 있는 정책과 방법론을 도입해야 하는 상황이다"고 덧붙였다.
기업들은 서드파티 라이브러리가 포함된 제품을 파악하고, 제품에 컴포넌트를 추가하는 사람과 방법에 관한 정책을 수립하고, 라이브러리를 이용하기에 앞서 다양한 취약점 데이터베이스를 조사해 보안 상태를 파악해야 하고, 내부에서 활용할 취약점 추적 솔루션을 개발하고, 많은 라이브러리를 다루는 상용 솔루션을 구매해야 한다.
앙은 "장기적으로 변화가 있을 전망이다. 그러나 개발자들은 아직까지도 하트블리드와 셸쇼크를 하나의 추세가 아닌 별개의 사건으로 간주하고 있다."고 지적했다. 그러나 앙은 “한편에서는 자동화된 솔루션 덕분에 기업들이 더욱 쉽게 알려진 취약점이 있는 컴포넌트(애플리케이션에 포함된)를 파악할 수 있다"며, "앞으로는 예방적인 방법들이 베스트 사례가 될 것"이라고 말했다.
테너블 네트워크 시큐리티(Tenable Network Security)의 EME 지역 기술 디렉터인 가빈 밀라드는 "기업들은 2014년 동안 확인한 '버그의 심각성'이 2015년에도 계속될 것이라는 점을 인식해야 한다. 또 취약점이 존재하는 장소를 신속하게 파악하는 프로세스를 수립하고, 버그를 발견했을 때 위험을 줄일 수 있도록 문제의 우선순위를 정하는 절차, 효율적으로 패칭을 하는 프로세스를 만들어야 한다. 향후 버그 관련 문제가 발생했을 때, 이에 신속하게 대처하는 방법과 체계를 수립해 점검해야 한다"고 강조했다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/91221]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 363692 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 353500 | 2020-10-27 |
3779 | [알아봅시다] 오픈소스 하드웨어 | 3803 | 2015-01-08 |
3778 | "오픈 소스 3D프린터가 3D프린터의 발전을 도모한다” | 3349 | 2015-01-08 |
3777 | 오픈소스 크롬캐스트 프로젝트, ‘플린트’ | 4043 | 2015-01-08 |
3776 | 글로벌 칼럼 | 믿었던 '오픈소스 라이브러리'에 뒷통수 맞는다 | 3622 | 2015-01-08 |
3775 | 국민내비 김기사, 앱 다운 없이 사용한다 | 3478 | 2015-01-06 |
3774 | 오픈소스SW로 정부IT 인프라 혁신 가속화 | 4049 | 2015-01-06 |
3773 | '오픈소스 기업' 페이스북 | 4521 | 2015-01-06 |
3772 | 크롬OS서 리눅스 가상화로 문서작성 | 3011 | 2015-01-06 |
3771 | 루비 개발자를 위한 코드 검색엔진 '옴니레프' | 3689 | 2015-01-06 |
3770 | '오픈소스', 기술 넘어 공동체 문화로 | 3126 | 2015-01-06 |
0개 댓글