| 취약점 8000개 시대, 패치에 대한 새로운 개념 필요 | 2014.12.24 | |
2014년 발견된 취약점 8000개 “변해야 하는 8000개의 이유” 패치는 본질상 그 자체로 한계가 있을 수밖에 없어 [보안뉴스 문가용] 국가 취약점 데이터베이스(National Vulnerability Database, NVD)는 11월 말 2014년 한 해에만 발견된 취약점을 7300개 이상 보고했다. 이는 역대 최고의 수치였다. 게다가 2014년이 한 달이나 더 남은 시점에서 말이다. 12월이 끝나는 날까지로 집계하면 취약점의 개수는 8000이 훨씬 넘을 것으로 보인다.
8천개의 취약점은 곧 소프트웨어의 질이 높아져야 할 8천 가지 이유와 다름없다. 그리고 여기서 말하는 ‘질’이란 당연히 보안을 말한다. 소프트웨어의 전체 개발 과정이 시큐어 코딩은 물론 여러 가지 보안 개념을 갖추고 있어야 한다. 물론 출시 후에 어차피 패치나 업데이트가 이루어질 것이니 보안성은 갈수록 높아질 수밖에 없는 것 아니냐고 되물을 지도 모른다. 하지만 패치는 패치일 뿐이며, 그 자체로도 제로데이 취약점, 사용자의 이해 수준 및 실천력 등 태생적인 약점을 가지고 있다. 장비 및 사용 환경에 따라 패치가 아예 불가능하거나 그에 가깝게 어려운 때도 있다. 그러니 패치로 보안을 강화하겠다는 건 처음부터 잘못 끼워진 단추다. 패치가 불완전하다면 무엇으로 대체해야 하는가? 그렇기 때문에 ‘보안’에 대한 보다 능동적이고 공격적인 태도가 필요하다. 이미 업계는 ‘선빵을 날린 자가 싸움을 지배한다’는 말처럼 업데이트 배포로 뒤늦게 실수를 메우려는 시도를 줄여가고 있다. 이는 소프트웨어 개발 과정 자체의 진화를 뜻하기도 한다. 소프트웨어의 개발 과정은 왜 변화하는 것일까? 그것은 소프트웨어에서 제일 중요한 특성이 사물인터넷 시대에 맞춰 어디나 적용이 가능한 ‘호환성’으로 변해가고 있기 때문이다. 범용성 혹은 호환성을 갖추려면 소프트웨어 자체는 보다 복잡해지고 크기도 커지는 게 필연적이며, 그에 따라 취약점이 더 많이 발생하고 있다. IT 시스템이나 심지어 제작자 스스로도 소프트웨어를 온전히 이해하고 파악한다는 게 불가능해지고 있는 것이다. 그렇기 때문에 패치와 업데이트 역시 ‘일회용 반창고’ 이상의 의미가 될 수 없다. 능동적인 소프트웨어 혹은 시스템 보안의 한 방법으로 소프트웨어 보증이 떠오르고 있다. 소프트웨어 보증이란 소프트웨어 내에 취약점이 존재하지 않는다는 제작자의 자신감의 정도를 표현하는 수단이다. 소프트웨어 보증을 하려면 시큐어 코딩 및 시큐어 개발이 자연스럽게 수반될 수밖에 없고 패치 및 패치 관리 솔루션에도 존재하는 구멍들에 보다 현실적으로 대처할 수 있게 된다. 시큐어 코딩은 최소한의 필수사항이 되어버리며 이는 공격의 경로를 상당히 많이 줄일 수 있다. 취약점 제대로 파악하기 이제는 CVE(common vulnerability exposures), 즉 일반적인 취약점을 찾아서 해결하는 것보다 공통 취약점 목록인 CWE(common weaknesses enumerations)에 집중해야 할 것이다. 즉 이미 발생한 사건을 해결하는 방식에서 조금씩이라도 앞으로 발생할 수 있는 가능성에 더 초점을 맞춰야 한다는 것이다. 이런 정서가 바탕이 되면 패치 보다 시큐어 코딩 및 개발에 더 무게를 실어줄 수밖에 없다. 이런 방식으로 바꿔나가면 장기적으로 봤을 때 취약점의 수를 줄일 수 있을 뿐 아니라 소프트웨어 개발 단계에 드는 비용(업데이트 포함)도 줄일 수 있다. 의학도 그렇지만 예방이 사후조치보다 무조건 싸다. 혹시나 오해를 할까봐 첨언하자면 필자는 패치 자체가 쓸모없다고 얘기하고 있는 게 아니다. 다만 개발 단계에서 완성도를 꾀하는 것이 제품 출시 후 패치하는 것보다 여러모로 낫다는 걸 강조하고 있을 뿐이다. 그리고 이를 진지하게 받아들이려면 소프트웨어 개발의 방식부터 바꿀 수밖에 없고, 소프트웨어 보증 전략을 선두에 내세워야 한다. 이런 식으로 소프트웨어 제작 환경을 바꿔가려면 개발 단계 자체의 혁신도 필요하지만 연구와 조사에 있어서도 투자가 필요하다. 소프트웨어 분석 툴과 기술이 더 정교하고 고급스러워져서 제작자들이 자신감을 가지고, 혹은 안심하고 소프트웨어를 만들 수 있어야 한다. 이런 심리적인 요소가 개발 기간을 단축하는 데 일조한다. 글 : 케빈 그린(Kevin Greene) @DARKReading [국제부 문가용 기자(globoan@boannews.com)] <저작권자: 보안뉴스(http://www.boannews.com/) 무단전재-재배포금지> |
||
|
|