취약점 공개함으로써 장기적이고 전체적인 보안 강화 가능
다만 패치 마련 기한에 대한 표준 및 합의 마련되어야
[보안뉴스 문가용 기자] 어느 날 부터인가, 갑자기 붐이 돼 버린 DC와 마블의 영웅들은 참 오랫동안도 전쟁을 치루고 있다. 하지만 분명 이 영웅들에도 수명이 있어, 이제는 아무에게도 기억되지 못하는 이름들도 존재한다. 애니멀맨(Animal Man), 돌핀(Dolphin), 립 헌터(Rip Hunter), 데인 도레인스(Dane Dorrance), 더 레이(The Ray) 등은 40~60년대까지만 해도 꽤나 인기를 구가했던 영웅들이다. 마찬가지로 아톰마스터(Atom-Master), 인찬트레스(Enchantress), 얼티백(Ultivac) 등 잊힌 악당들도 존재한다.
블랙햇들의 높으신 업적과 성과들이 헤드라인을 화려하게 장식하는 통에, 보안 전문가들의 이름은 아무도 기억해주지 않게 된다. 이들의 싸움은 마치 DC나 마블의 만화책 페이지에만 있는 것처럼 소리 소문 없이 존재하고, 게다가 겉보기에는 연전연패하는 것처럼 보인다. 승자만 기억하는 세상에서 이들의 이름이 망각되는 건 우연이 아니다.
하지만 정말 그럴까? 우리 보안 담당자들은 연전연패의 주인공들일까? 사이버 범죄자들이 보안 구멍을 찾는 것처럼, 보안 전문가들도 다양한 취약점들을 찾아 생산자에게 알리거나 취약점 관리 기관에 알린다. 이들은 여러 매체에 사용자 교육 및 계몽을 목적으로 꾸준히 글을 기고하고, 임원진들을 향한 목소리도 담대하게 높인다. 자기들끼리는 여러 공격 패턴 및 멀웨어 소식을 공유하기도 하고, 새로운 정책을 국가에 제안하기도 한다. 이런 행위들이 과연 패배자의 것일까?
사이버 범죄자 및 해커들이 자신의 이익을 위해 취약점을 캐내고 혼자만이 간직하고 있다면 보안 전문가들은 모두의 이익을 위해 세상에 공표한다. 물론 이 ‘공표’의 과정에 대한 가장 적절한 절차가 무엇인지, 아직 논의가 진행되고 있다. 현재 가장 보편화된 취약점 공표 절차는 1) 취약점을 발견하고 2) 그 취약점이 가진 잠재적인 위험성을 판단하고 3) 취약점의 위치를 정확히 하기 위해 스크린샷을 찍거나 코드를 일부 발췌한 후 4) 보고서를 작성해 5) 해당 소프트웨어 및 기기의 생산자에게 먼저 알린다.
이때 보고서에는 기술적인 세부 내용과 증거 자료, 공개 일시가 보통 명시되어 있다. 공개 일시를 명시한다는 건, 이 시간을 넘어서까지 해당 취약점에 대한 조치가 없을 경우 대중에게 알린다는 뜻이다. 하지만 보안 전문가들은 이걸 협박하듯이 사용하고 있지 않다. 이 보고서는 신사적으로 생산자들에게 제일 먼저 전달되며, 그 전달 방법도 가장 비밀스럽고 안전한 것을 택한다.
그리고 기다린다. 패치가 나오거나 공개 일시가 다 될 때까지 충분히 생산자 및 제조사가 조치를 취할 수 있을 때까지 기다려준다. 그런 후 해당 취약점에 대한 완벽한 보고서를 대중들에게 공개한다. 여기에는 취약점에 대한 모든 내용이 들어 있어, 어떤 식으로 익스플로잇 할 수 있는지, 어떻게 대처해야 하는지까지도 언급된다.
이런 식으로 취약점을 공개하자는 데에 있어 아무도 반대하고 있지 않다. 다만 문제가 되는 건 공개 일시다. 패치 개발까지 얼마나 시간을 주어야 하는지에 대해 좀처럼 합의되지 않고 있다. 구글은 보통 60일의 시간을 준다. 하지만 이미 해커들이 발견해 사용하고 있는 취약점에 대해서는 7일만의 시간을 허락한다. 취약점 공개 및 버그바운티 플랫폼으로 유명한 해커원(HackerOne)은 30일을 디폴트로 삼고 있고, 이는 여러 상황 상 최대 180일까지 유연하게 늘어날 수 있다. 보안 전문가 대부분 생산자/제조사가 패치 개발에 노력한다는 전제 하에 기한을 늘려주거나 반대의 경우 줄이기도 한다.
취약점의 모든 내용을 세부적으로 공개하는 것 자체에 대해서도 이의가 없지 않다. 굳이 익스플로잇 방법까지 공개해야 하냐는 의견들이 있는데, 대부분은 이러한 공개 방식이 산업 전체에 장기적인 이득을 가져다준다고 보고 있다. 왜냐하면 1) 2000년대 초반, 이런 식의 취약점 공개 방식이 모양새를 갖춰가기 전에는 기업들이 취약점을 감추기에 급급했고 2) 취약점을 패치하는 게 후순위로 밀려나는 동안 해커들은 그 취약점을 신나게 물고 뜯고 씹고 맛보았기 때문이다.
패치가 있든 없든 취약점에 대한 내용이 완전히 공개되면 개인들이 최소 해당 제품이나 웹사이트, 소프트웨어를 사용 중지함으로써 안전을 꾀할 수 있게 된다. 혹은 안전하게 사용하는 방법을 개발해 공유할 수도 있게 된다. 사용자들의 이런 움직임은 기업의 패치를 가속화시킨다. 보안 전문가 브루스 슈나이어(Bruce Schneier)가 말하듯, 취약점 공개야 말로 보안 전문가들의 승전보다.
그럼에도 아직 명확한 공개 일시 표준이 마련되지 않고 있다는 점은 걸림돌이 된다. 보안 전문가로서의 위엄을 지키는 ‘신사적인 취약점 공개 절차’가 어느 정도 마련되었다고 한다면, 이제 공개 일시에 대한 합의를 함으로써 완성시켜야 할 때다. 보안 전문가가 반드시 영웅이 되거나, 이름을 남겨야 할 필요가 있는 건 아니지만, 굳이 패배자로서 오명을 뒤집어 쓸 필요 또한 없다. 이는 취약점 공개에 대한 명확한 표준이 마련되면 해결될 문제다.
글 : 마크 랄리버트(Marc Laliberte)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
다만 패치 마련 기한에 대한 표준 및 합의 마련되어야
블랙햇들의 높으신 업적과 성과들이 헤드라인을 화려하게 장식하는 통에, 보안 전문가들의 이름은 아무도 기억해주지 않게 된다. 이들의 싸움은 마치 DC나 마블의 만화책 페이지에만 있는 것처럼 소리 소문 없이 존재하고, 게다가 겉보기에는 연전연패하는 것처럼 보인다. 승자만 기억하는 세상에서 이들의 이름이 망각되는 건 우연이 아니다.
하지만 정말 그럴까? 우리 보안 담당자들은 연전연패의 주인공들일까? 사이버 범죄자들이 보안 구멍을 찾는 것처럼, 보안 전문가들도 다양한 취약점들을 찾아 생산자에게 알리거나 취약점 관리 기관에 알린다. 이들은 여러 매체에 사용자 교육 및 계몽을 목적으로 꾸준히 글을 기고하고, 임원진들을 향한 목소리도 담대하게 높인다. 자기들끼리는 여러 공격 패턴 및 멀웨어 소식을 공유하기도 하고, 새로운 정책을 국가에 제안하기도 한다. 이런 행위들이 과연 패배자의 것일까?
사이버 범죄자 및 해커들이 자신의 이익을 위해 취약점을 캐내고 혼자만이 간직하고 있다면 보안 전문가들은 모두의 이익을 위해 세상에 공표한다. 물론 이 ‘공표’의 과정에 대한 가장 적절한 절차가 무엇인지, 아직 논의가 진행되고 있다. 현재 가장 보편화된 취약점 공표 절차는 1) 취약점을 발견하고 2) 그 취약점이 가진 잠재적인 위험성을 판단하고 3) 취약점의 위치를 정확히 하기 위해 스크린샷을 찍거나 코드를 일부 발췌한 후 4) 보고서를 작성해 5) 해당 소프트웨어 및 기기의 생산자에게 먼저 알린다.
이때 보고서에는 기술적인 세부 내용과 증거 자료, 공개 일시가 보통 명시되어 있다. 공개 일시를 명시한다는 건, 이 시간을 넘어서까지 해당 취약점에 대한 조치가 없을 경우 대중에게 알린다는 뜻이다. 하지만 보안 전문가들은 이걸 협박하듯이 사용하고 있지 않다. 이 보고서는 신사적으로 생산자들에게 제일 먼저 전달되며, 그 전달 방법도 가장 비밀스럽고 안전한 것을 택한다.
그리고 기다린다. 패치가 나오거나 공개 일시가 다 될 때까지 충분히 생산자 및 제조사가 조치를 취할 수 있을 때까지 기다려준다. 그런 후 해당 취약점에 대한 완벽한 보고서를 대중들에게 공개한다. 여기에는 취약점에 대한 모든 내용이 들어 있어, 어떤 식으로 익스플로잇 할 수 있는지, 어떻게 대처해야 하는지까지도 언급된다.
이런 식으로 취약점을 공개하자는 데에 있어 아무도 반대하고 있지 않다. 다만 문제가 되는 건 공개 일시다. 패치 개발까지 얼마나 시간을 주어야 하는지에 대해 좀처럼 합의되지 않고 있다. 구글은 보통 60일의 시간을 준다. 하지만 이미 해커들이 발견해 사용하고 있는 취약점에 대해서는 7일만의 시간을 허락한다. 취약점 공개 및 버그바운티 플랫폼으로 유명한 해커원(HackerOne)은 30일을 디폴트로 삼고 있고, 이는 여러 상황 상 최대 180일까지 유연하게 늘어날 수 있다. 보안 전문가 대부분 생산자/제조사가 패치 개발에 노력한다는 전제 하에 기한을 늘려주거나 반대의 경우 줄이기도 한다.
취약점의 모든 내용을 세부적으로 공개하는 것 자체에 대해서도 이의가 없지 않다. 굳이 익스플로잇 방법까지 공개해야 하냐는 의견들이 있는데, 대부분은 이러한 공개 방식이 산업 전체에 장기적인 이득을 가져다준다고 보고 있다. 왜냐하면 1) 2000년대 초반, 이런 식의 취약점 공개 방식이 모양새를 갖춰가기 전에는 기업들이 취약점을 감추기에 급급했고 2) 취약점을 패치하는 게 후순위로 밀려나는 동안 해커들은 그 취약점을 신나게 물고 뜯고 씹고 맛보았기 때문이다.
패치가 있든 없든 취약점에 대한 내용이 완전히 공개되면 개인들이 최소 해당 제품이나 웹사이트, 소프트웨어를 사용 중지함으로써 안전을 꾀할 수 있게 된다. 혹은 안전하게 사용하는 방법을 개발해 공유할 수도 있게 된다. 사용자들의 이런 움직임은 기업의 패치를 가속화시킨다. 보안 전문가 브루스 슈나이어(Bruce Schneier)가 말하듯, 취약점 공개야 말로 보안 전문가들의 승전보다.
그럼에도 아직 명확한 공개 일시 표준이 마련되지 않고 있다는 점은 걸림돌이 된다. 보안 전문가로서의 위엄을 지키는 ‘신사적인 취약점 공개 절차’가 어느 정도 마련되었다고 한다면, 이제 공개 일시에 대한 합의를 함으로써 완성시켜야 할 때다. 보안 전문가가 반드시 영웅이 되거나, 이름을 남겨야 할 필요가 있는 건 아니지만, 굳이 패배자로서 오명을 뒤집어 쓸 필요 또한 없다. 이는 취약점 공개에 대한 명확한 표준이 마련되면 해결될 문제다.
글 : 마크 랄리버트(Marc Laliberte)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
.jpg)
