.jpg)
취약점을 제보하려면 여러 가지 기술적 노하우와 숙련도가 필요하다. 그런데 그건 제보하는 입장에서만의 이야기가 아니다. 취약점 제보를 받는 사람의 접수도 찰져야 한다. 접수 받는 자의 접수 노하우를 전문가로부터 들어 보았다.
[보안뉴스 문가용 기자] 오픈소스 프로젝트 관리자들은 수많은 취약점 보고서를 받는다. 보고서의 내용과 질, 수준과 상세성은 판이하며, 그 제출 방식도 다양하다. 즉 ‘표준 절차’라는 게 없다시피 한 상황이며, 이 때문에 오픈소스 프로젝트 관리자들의 업무량과 난이도는 가히 살인적이라 할 정도다. 오픈소스 프로젝트 커뮤니티에 참여하는 사람들에게서 도움을 받을 수 있지만, 이 사람들도 전부 ‘자원자’들이라 한계가 있다.
취약점 연구 생태계는 대단히 많은 사람들로 구성되어 있다. 모두가 다른 마음, 다른 동기, 다른 기술, 다른 실력, 다른 방법론을 가지고 취약점을 파고든다. 순수한 호기심과 공익적인 목적을 추구하는 사람도 있고, 철저하게 상업적인 테두리 안에서만 움직이는 사람들도 존재한다. 그리고 이 두 가지와 다른 ‘플러스 알파’를 적절히 섞어둔 사람들도 무수히 많다.
그러므로 보안인들로 구성된 온라인 공동체에서 지속적으로 소통을 하고 관계를 유지한다는 건 꽤나 어려운 일이다. 필자는 깃허브(GitHub)라는 IT 전문가들의 대형 커뮤니티에서 근무하고 있는데, 이메일로 한 줄짜리 수수께끼 문제처럼 보내는 사람부터 박사 학위 논문 뺨치는 수준의 상세하고 기술적인 보고서를 접수시키는 사람까지 여러 가지 의미에서 상상을 초월하는 경험을 매일처럼 하게 된다. 그러면서 ‘취약점 보고’라는 것을 기분 좋은 경험으로 바꿔주는 절차를 어느 정도 익히게 됐는데, 그걸 나눠보고자 한다.
1. 취약점 보고 접수 관련
취약점 보고와 관련하여 서로가 기분이 좋으려면 일단 받는 사람부터 잘해야 한다. 접수를 받을 사람이 최대한 명확하게 접수 방법을 알려야 한다는 것이다. 어느 채널로, 어느 정도 내용을 갖춘 보고서를 언제부터 언제까지 접수 받는다는 것을 알려야 마찰이 최대한 줄어든다. 마찰은 ‘왜 내 보고서는 무시하느냐’라는 항의에서부터 보고서 누락 및 분실까지 다양한 형태로 나타날 수 있다.
또한 취약점 보고서를 접수 받기로 한 입장에서 관련 정책을 수립해 표명하는 것도 큰 도움이 된다. 이건 접수 담당자 혼자서 할 수 없는 일이다. 제출에 관한 규칙만이 아니라 정당한 취약점에 대해서 어떻게 조치를 취하고, 어떤 식으로 제보자에게 보상할 것인지도 정책 내용에 포함되어야 한다.
2. 제출된 보고서를 ‘잘’ 접수한 후에는
그 다음 접수자들이 해야 할 건 ‘잘 받았다’는 회신을 주는 것이다. 접수 받자마자 감사 답장을 줘야 하는 건 아니지만, 최대한 빨리 접수 사실을 알려주는 것이 예의다. 공개 접수를 통해 받은 것이나, 개인적으로 은밀하게 받은 것이나 마찬가지다. 그리고 최대한 빠르게 해당 보고서 내용을 검토하고 조사해야 한다. 그러할 여력이 되지 않을 경우가 많을 텐데, 그렇기 때문에 최초 답장의 ‘타이밍’이 중요하다.
깃허브의 경우 취약점 정보를 접수한 관리자가 90일 안에 조치를 취하도록 하고 있다. 90일이 넘도록 아무런 일이 일어나지 않는다면, 취약점에 대한 세부 기술 내용을 공개해도 무방하다. 하지만 제보자와 접수자가 소통이 잘 된 경우라면 90일이 넘어도 세부 내용을 발표하지 않고 기다려주는 사례가 종종 나타난다. 첫 단추가 정말 중요하다는 건 여기서도 여실히 드러난다.
3. 취약점 보고서 검토와 확인
취약점 보고서의 내용이 전부 타당한 건 아니다. 그러므로 접수한 후 확인과 검토가 필요하다. 이 과정에서 보고서 작성 및 제출자와 이야기를 나누는 것을 추천한다. 왜냐하면 접수자는 수많은 취약점에 대한 내용을 검사해야 하지만, 제출자는 자신이 발견한 취약점 한두 개만 깊이 연구했을 가능성이 높기 때문이다. 그러므로 그 취약점에 대한 활용법과 공격 시나리오를 더 많이 알고 있고, 그 중 몇 가지는 접수자가 상상하지도 못한 것일 수 있다.
관리자 입장에서 이게 의외로 쉽지 않다. 취약점 제보가 마치 ‘코드 품질에 대한 비판’처럼 느껴지기 때문이다. 또한 한 번에 많은 취약점 보고서를 검토해야 할 때가 있다는 것도 큰 어려움이 된다. 그렇기에 더더욱 제보자와 이야기를 나누는 것이 좋다. 그 사람에게 ‘비판적 의도’가 전혀 없음을 알 수 있고(아닐 때도 있지만), 제보자의 연구 내용을 산지직송으로 들음으로써 시간도 절약할 수 있다.
4. 취약점의 처리
취약점 보고서 내용이 확인되었고, 그 위험성에 대한 파악과 합의가 끝났다면 이제 실제 조치를 취해야 한다. 이 부분에서 제출자와 접수자가 다른 의견을 가지게 될 수 있다. 하지만 좋은 관계를 유지하겠다고 해서 제보자의 의견을 적극 반영하는 건 좋지 않다. 관리자가 보기에 올바른 방향으로 취약점 보완을 실시해야 한다.
그렇다고 제보자의 의견을 무시하라는 건 아니다. 충분한 논의를 통해 서로를 이해하고, 그럼으로써 최종 픽스에 모든 의견이 종합적으로 들어가면 그보다 더 좋을 수 없다. 또한 픽스를 개발하고 제보자의 검토를 요청하는 것도 좋은 방법이다. 생각지도 못한 보완책이 나올 수도 있다.
5. 취약점 보고서 발표
‘발표’는 취약점 보고서 처리에 있어 가장 중요할 수 있는데, 가장 간과되는 최종 스텝이다. 취약점을 제보받고 처리한다는 것의 진정한 의미를 잊기 때문에 발생하는 일이다. 누군가 당신이 관리하는 코드에서 취약점을 연구해 당신에게 알리고, 그걸 협력해 고친다는 건, 전부 앞으로 그 코드를 사용하게 될 사람들의 안전을 위해서다. 그러니 취약점을 해결해 악용의 소지를 없앴다면, 그 취약점에 대해 보다 많은 사람들에게 알려서 안전을 꾀할 수 있게 해 주어야 한다.
이 과정을 간과했을 때 어떤 일이 생길 수 있을까? 해당 코드에서 취약점 이슈가 발생했다는 걸 누구도 모르기 때문에 경계심 없이 썼다가 그 코드의 직접 사용자는 물론, 그 코드를 임포트 및 임베드된 상태로 사용하는 생태계 내 모든 사람들이 취약점에 노출될 수 있다. 코드 디펜던시가 전부 최신 버전으로만 구성된다는 건 게으른 관리자의 꿈일 뿐이다.
보안 취약점들은 마치 광물과 같아서 존재하는 것이 100% 발견되는 건 아니다. 우리는 세상에 얼마나 많은 취약점이 있는지, 그 중에서 얼마나 발견하여 고쳤는지 전혀 알 수 없다. 아마 아무에게도 발견되지 않은 취약점이 더 많이 존재할 것이다. 그렇다는 건 앞으로 누군가는 계속해서 취약점을 찾아 헤맬 것이고, 누군가는 이 정보를 접수해야 할 것이며, 누군가는 이를 픽스해야 할 것이다. 그러므로 관리자들은 취약점 제보 시스템을 지금부터라도 잘 구축해야 한다. 이는 미래에 대한 투자이기도 하다.
글 : 바스 알버츠(Bas Alberts), GitHub
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 오픈소스 프로젝트 관리자들은 수많은 취약점 보고서를 받는다. 보고서의 내용과 질, 수준과 상세성은 판이하며, 그 제출 방식도 다양하다. 즉 ‘표준 절차’라는 게 없다시피 한 상황이며, 이 때문에 오픈소스 프로젝트 관리자들의 업무량과 난이도는 가히 살인적이라 할 정도다. 오픈소스 프로젝트 커뮤니티에 참여하는 사람들에게서 도움을 받을 수 있지만, 이 사람들도 전부 ‘자원자’들이라 한계가 있다.
[이미지 = utoimage]
취약점 연구 생태계는 대단히 많은 사람들로 구성되어 있다. 모두가 다른 마음, 다른 동기, 다른 기술, 다른 실력, 다른 방법론을 가지고 취약점을 파고든다. 순수한 호기심과 공익적인 목적을 추구하는 사람도 있고, 철저하게 상업적인 테두리 안에서만 움직이는 사람들도 존재한다. 그리고 이 두 가지와 다른 ‘플러스 알파’를 적절히 섞어둔 사람들도 무수히 많다.
그러므로 보안인들로 구성된 온라인 공동체에서 지속적으로 소통을 하고 관계를 유지한다는 건 꽤나 어려운 일이다. 필자는 깃허브(GitHub)라는 IT 전문가들의 대형 커뮤니티에서 근무하고 있는데, 이메일로 한 줄짜리 수수께끼 문제처럼 보내는 사람부터 박사 학위 논문 뺨치는 수준의 상세하고 기술적인 보고서를 접수시키는 사람까지 여러 가지 의미에서 상상을 초월하는 경험을 매일처럼 하게 된다. 그러면서 ‘취약점 보고’라는 것을 기분 좋은 경험으로 바꿔주는 절차를 어느 정도 익히게 됐는데, 그걸 나눠보고자 한다.
1. 취약점 보고 접수 관련
취약점 보고와 관련하여 서로가 기분이 좋으려면 일단 받는 사람부터 잘해야 한다. 접수를 받을 사람이 최대한 명확하게 접수 방법을 알려야 한다는 것이다. 어느 채널로, 어느 정도 내용을 갖춘 보고서를 언제부터 언제까지 접수 받는다는 것을 알려야 마찰이 최대한 줄어든다. 마찰은 ‘왜 내 보고서는 무시하느냐’라는 항의에서부터 보고서 누락 및 분실까지 다양한 형태로 나타날 수 있다.
또한 취약점 보고서를 접수 받기로 한 입장에서 관련 정책을 수립해 표명하는 것도 큰 도움이 된다. 이건 접수 담당자 혼자서 할 수 없는 일이다. 제출에 관한 규칙만이 아니라 정당한 취약점에 대해서 어떻게 조치를 취하고, 어떤 식으로 제보자에게 보상할 것인지도 정책 내용에 포함되어야 한다.
2. 제출된 보고서를 ‘잘’ 접수한 후에는
그 다음 접수자들이 해야 할 건 ‘잘 받았다’는 회신을 주는 것이다. 접수 받자마자 감사 답장을 줘야 하는 건 아니지만, 최대한 빨리 접수 사실을 알려주는 것이 예의다. 공개 접수를 통해 받은 것이나, 개인적으로 은밀하게 받은 것이나 마찬가지다. 그리고 최대한 빠르게 해당 보고서 내용을 검토하고 조사해야 한다. 그러할 여력이 되지 않을 경우가 많을 텐데, 그렇기 때문에 최초 답장의 ‘타이밍’이 중요하다.
깃허브의 경우 취약점 정보를 접수한 관리자가 90일 안에 조치를 취하도록 하고 있다. 90일이 넘도록 아무런 일이 일어나지 않는다면, 취약점에 대한 세부 기술 내용을 공개해도 무방하다. 하지만 제보자와 접수자가 소통이 잘 된 경우라면 90일이 넘어도 세부 내용을 발표하지 않고 기다려주는 사례가 종종 나타난다. 첫 단추가 정말 중요하다는 건 여기서도 여실히 드러난다.
3. 취약점 보고서 검토와 확인
취약점 보고서의 내용이 전부 타당한 건 아니다. 그러므로 접수한 후 확인과 검토가 필요하다. 이 과정에서 보고서 작성 및 제출자와 이야기를 나누는 것을 추천한다. 왜냐하면 접수자는 수많은 취약점에 대한 내용을 검사해야 하지만, 제출자는 자신이 발견한 취약점 한두 개만 깊이 연구했을 가능성이 높기 때문이다. 그러므로 그 취약점에 대한 활용법과 공격 시나리오를 더 많이 알고 있고, 그 중 몇 가지는 접수자가 상상하지도 못한 것일 수 있다.
관리자 입장에서 이게 의외로 쉽지 않다. 취약점 제보가 마치 ‘코드 품질에 대한 비판’처럼 느껴지기 때문이다. 또한 한 번에 많은 취약점 보고서를 검토해야 할 때가 있다는 것도 큰 어려움이 된다. 그렇기에 더더욱 제보자와 이야기를 나누는 것이 좋다. 그 사람에게 ‘비판적 의도’가 전혀 없음을 알 수 있고(아닐 때도 있지만), 제보자의 연구 내용을 산지직송으로 들음으로써 시간도 절약할 수 있다.
4. 취약점의 처리
취약점 보고서 내용이 확인되었고, 그 위험성에 대한 파악과 합의가 끝났다면 이제 실제 조치를 취해야 한다. 이 부분에서 제출자와 접수자가 다른 의견을 가지게 될 수 있다. 하지만 좋은 관계를 유지하겠다고 해서 제보자의 의견을 적극 반영하는 건 좋지 않다. 관리자가 보기에 올바른 방향으로 취약점 보완을 실시해야 한다.
그렇다고 제보자의 의견을 무시하라는 건 아니다. 충분한 논의를 통해 서로를 이해하고, 그럼으로써 최종 픽스에 모든 의견이 종합적으로 들어가면 그보다 더 좋을 수 없다. 또한 픽스를 개발하고 제보자의 검토를 요청하는 것도 좋은 방법이다. 생각지도 못한 보완책이 나올 수도 있다.
5. 취약점 보고서 발표
‘발표’는 취약점 보고서 처리에 있어 가장 중요할 수 있는데, 가장 간과되는 최종 스텝이다. 취약점을 제보받고 처리한다는 것의 진정한 의미를 잊기 때문에 발생하는 일이다. 누군가 당신이 관리하는 코드에서 취약점을 연구해 당신에게 알리고, 그걸 협력해 고친다는 건, 전부 앞으로 그 코드를 사용하게 될 사람들의 안전을 위해서다. 그러니 취약점을 해결해 악용의 소지를 없앴다면, 그 취약점에 대해 보다 많은 사람들에게 알려서 안전을 꾀할 수 있게 해 주어야 한다.
이 과정을 간과했을 때 어떤 일이 생길 수 있을까? 해당 코드에서 취약점 이슈가 발생했다는 걸 누구도 모르기 때문에 경계심 없이 썼다가 그 코드의 직접 사용자는 물론, 그 코드를 임포트 및 임베드된 상태로 사용하는 생태계 내 모든 사람들이 취약점에 노출될 수 있다. 코드 디펜던시가 전부 최신 버전으로만 구성된다는 건 게으른 관리자의 꿈일 뿐이다.
보안 취약점들은 마치 광물과 같아서 존재하는 것이 100% 발견되는 건 아니다. 우리는 세상에 얼마나 많은 취약점이 있는지, 그 중에서 얼마나 발견하여 고쳤는지 전혀 알 수 없다. 아마 아무에게도 발견되지 않은 취약점이 더 많이 존재할 것이다. 그렇다는 건 앞으로 누군가는 계속해서 취약점을 찾아 헤맬 것이고, 누군가는 이 정보를 접수해야 할 것이며, 누군가는 이를 픽스해야 할 것이다. 그러므로 관리자들은 취약점 제보 시스템을 지금부터라도 잘 구축해야 한다. 이는 미래에 대한 투자이기도 하다.
글 : 바스 알버츠(Bas Alberts), GitHub
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
