적절한 보안 취약점 공개 프로세스

요새 보안 취약점 공개에 대한 논란이 계속 불거져 나오고 있습니다.
현재 상황에서 아쉬운 점은
1. 10년 전에 고민했던 문제들이 여전히 해결되지 않은 상태임.
2. 국내의 몇몇 보안 전문가들이 취약점 공개를 하면서 얻게된 노하우가 전혀 공유되지 못하고 있음.
위의 두 가지 점입니다.

제가 많은 것을 알지는 못하지만, 비교적 많은 보안 취약점을 국내외에 발표하면서, 여러분보다 더 많이 얻어터진 입장에서 제가 얻게된 교훈을 간략히 정리해보도록 하겠습니다.

1) 보안 취약점 공개란 무엇인가?
보안 취약점 공개는 다음의 두 가지 성격을 가진 것입니다.

1. 버그 리포트
  여러분이 사용하시는 마이크로소프트 윈도우즈, 오피스, 혹은 아래아한글 등의 소프트웨어에 사용이 불편한 버그를 경험할 때가 있을 것입니다. 특정 상황에서 원하는 동작이 안된다거나, OS 가 죽는다거나... 이런 문제들을 버그라고 이야기하는데, 보안 취약점 공개는 버그를 벤더에 통보하는 버그 리포트의 일종입니다.

2. 결함 공개
  결함 공개가 가장 발달한 분야는 자동차 분야일 것입니다. 여러분이 운전하는 자동차가 급발진 문제, 브레이크 결함 등 인체의 안전과 관련된 치명적 결함이 있다면, 여러분은 아마도 주변의 동일 차종 운전자에게 이 위험을 알리고, 자동차 제조사에도 알려서 결함에 대한 원인 분석과 리콜을 요구할 것입니다. 보안 취약점 공개는 많은 이들의 안전이 개입되어 있다는 점에서 자동차의 결함 공개와 비슷한 성격을 갖습니다.

아직 국내는 보안 취약점 공개의 역사가 짧고, 약 10 여 명 정도만이 공식적인 Coordinated Disclosure 프로세스를 밟아봤기 때문에, 보안 취약점 공개에 대한 잘못된 시각이 팽배합니다. 극단적인 생각 중에는 '보안 취약점 공개는 매우 대단한 일이다. 그런 일을 하는 나는 정말 뛰어난 사람이다.', 혹은 '보안 취약점 공개는 업체로부터 나의 Credit 을 인정받아 보안 분야의 명성을 관리하기 위한 수단이다.' 라는 생각이 있고, 반대편의 극단에는 '보안 취약점 공개는 국내의 열악한 소프트웨어 업계에 피해를 주는 백해무익한 일이며, 우리 사업을 방해하기 위해 의도적으로 하는 것이다.', '보안 취약점 공개는 관련 제품 사용자들에게 피해를 주는 행위이므로 자제되어야 한다.' 라는 생각이 있습니다.

그러나, 보안 취약점 공개는 '우리가 안전하게 컴퓨터를 사용하는데 있어 장애가 되는 소프트웨어/하드웨어 상의 버그를 벤더에 통보하여 해당 버그를 제거하도록 돕고, 동일 제품 및 서비스를 사용하는 다른 사용자들이 피해를 입지 않도록 예방하는 일련의 절차와 행위'를 통칭하는 것일 뿐입니다. 즉, 쉽게 버그 리포트라고 생각하시는 것이 좋습니다.

2) 바람직한 보안 취약점 공개 절차는?
보안 취약점 공개가 버그 리포트이긴 하지만, 많은 사용자들의 안전이 관련되어 있다는 점에서 보안 취약점 공개의 절차는 신중하게 진행되어야 합니다. 여러분이 자체적인 조사(예를 들면, Blackbox/Graybox/Whitebox test 등)를 거쳐, 혹은 우연한 기회에 특정 제품의 보안 취약점을 발견했다면 일반적으로 다음과 같은 절차를 거치는 것이 현명합니다.

1. 취약점에 대한 상세 분석
 이 취약점의 원인이 무엇인지, 재현 가능한 것인지 등을 상세히 분석할 필요가 있습니다. 몇몇 취약점은 초기에는 취약점으로 보이지만, 제품 자체의 결함이 아닌 deploy 과정에서 SE 의 실수로 발생할 수 있습니다. 또한 자신의 컴퓨터에서만 일시적으로 발생한 현상이라면, 여러분 컴퓨터의 설정 혹은 다른 소프트웨어의 영향으로 발생한 것일 수 있습니다.
 향후 벤더의 담당 개발자가 연락해왔을 때, 버그에 대해 설명할 수 있도록 되도록 상세한 사항을 분석해두는 것이 좋습니다.

2. 벤더에 통보
 해당 취약점을 해결할 수 있는 것은 벤더의 담당 개발자 뿐입니다. 혹, 여러분이 자체적인 패치를 제작할 수도 있을 것입니다. 그러나 최종적으로 이 패치를 넣을지 말지 결정하는 것도 벤더의 개발자라는 것을 명심해야 합니다. 벤더의 웹 사이트를 통해 연락처를 파악하고, 담당자에게 연락하여 버그를 알리세요.
 국내 회사의 경우 상황이 열악합니다. 때로는 영업 담당 이사의 핸드폰으로 전화를 해야 문제가 해결될 때가 있습니다. 아직 역사가 짧고, 보안 취약점 공개에 대해 사회적으로 합의된 절차가 없기 때문입니다. 여러분은 상당히 험난한 절차를 거쳐야 벤더에 연락을 취할 수 있을 것이고, 간신히 연락이 되었다 하더라도, '왜 우리 회사에 이러세요? 당신 경쟁사 사주 받고 이러는거 아니야?' 혹은 '개xx, 너 죽고 싶냐?' 라는 반응이 오거나, 조용히 무시되는 경우도 많을 것입니다. 메일을 통해 통보하면 국내 회사의 경우 99.9% 의 신뢰도로 절대 답장을 보내지 않습니다. 인내심을 발휘하여 1주 간격으로 2~3 회 이상 연락을 시도하세요. 공개는 그 다음에 해도 늦지 않습니다.
 해외 회사의 경우 상황이 낫습니다. 어느 정도 규모 이상의 회사는 당신을 어떻게 대접해야 할지에 대해 정확한 프로세스가 잡혀있습니다. Security@해당 회사 메일 주소, 혹은 웹 사이트를 통해 파악한 보안 담당자, 제품 QA 담당자에게 연락을 취하세요. 보통 1~2주일 이내로 매우 정중한 답장이 옵니다. 이때 보통은 Bug Tracking 시스템의 Ticket 이 발급되는데, 연락을 주고 받는 와중에 이슈를 추적하기 위해 사용되니 메일을 주고 받을 때 주의하세요. 그들이 당신을 왕처럼 떠받든다고 하더라도, 너무 우쭐하지 마세요. 이건 그냥 '버그 리포트'일 뿐이며, 사용자인 당신과 제품 QA 담당자, 개발자가 의사 소통을 통해 함께 버그를 제거해나가는 과정일 뿐입니다.
 이후 해당 벤더는 제품의 버그 패치 작업 진척 현황, 패치 릴리즈 예정일 등 상세 정보를 당신에게 메일로 알려줄 것입니다 (업체에 따라 스팸 메일처럼 지겹게 올 것입니다). 혹 버그에 대해 제대로 이해하지 못했다면, 담당 개발자가 당신에게 상세 정보를 요청할 수도 있습니다.
 주의할 점은 패치 일정이 당신의 예상과 달리 매우 길어질 수 있다는 점입니다. 벤더와의 정보 교환이 원활하다면, 3 개월~6개월에 걸친 패치 일정도 나쁘지 않습니다. 그러나 당신에게 정보를 전혀 주려고 하지 않으면서, '패치 일정이 늦어지니 우리가 별도로 통보할 때까지 기다려주세요.' 라는 태도는 업체가 당신의 버그 리포트를 조용히 땅속에 묻으려는 것일 수도 있습니다. 경험이 많아지면, 벤더가 어떤 태도를 취하는 것인지 파악하는 감이 생깁니다.
 당신이 원한다면, 해당 벤더가 고객들에게 제품 버그 정보를 공개할 때 당신에 대한 Credit 을 넣어달라고 솔직히 요구하세요. 그리고 당신이 Coordinated Disclosure 를 원한다는 것을 분명히 밝히세요. 벤더에 따라 최종 패치일 이전에 당신에게 패치의 품질에 대한 확인을 요청하는 경우도 있습니다. 대부분의 경우 벤더의 1차 패치는 문제를 적절히 해결하지 못합니다. 2차, 3차 패치가 나와야 비로소 문제가 해결되는 경우가 많으니 인내심을 갖고 대응하시기 바랍니다.
 패치가 적절히 이루어졌으면, 당신과 미리 약속한 날짜에 벤더가 자사 웹사이트나 메일을 통해 고객에게 Security Advisory 를 내보낼 것입니다. 당신도 이 시기에 맞추어, 해외 보안 관련 메일링 리스트 등에 정보를 공개하면 됩니다.

3. CERT 등에 신뢰할만한 기관과 협조
 벤더에 통보한 후에는 CERT 에 통보하는 것도 고려해볼만합니다. 아무래도 당신 개인이 시간을 투자하여 벤더와 패치 과정을 추진하는 것보다는 CERT 등 믿을 수 있는 기관이 개입하는 것이 당신에게 부담이 덜할 것입니다. CERT 는 벤더와 당신 사이의 버그 패치 과정을 적절히 중계해줄 것이며, 벤더가 해당 취약점을 조용히 묻을 수 없는 중요한 계기가 됩니다. 보통 이 과정에서 CVE 번호도 할당받게 됩니다.
 아쉽게도 KrCERT 등 국내 기관은 버그 릴리즈 과정에서 보안 연구자와 벤더를 중재하는 프로세스에 대해 경험이 부족합니다. 이들은 연구자들의 버그 리포트 동기를 의심하거나, 혹은 벤더를 지나치게 압박하여 보안 연구자나 벤더 모두를 불편하게 한 사례가 있습니다. 그들 중 보안 연구자에게 우호적인 시각을 가진 사람들은 보안 취약점 리포트를 지나치게 특별한 과정으로 생각하는 경향이 있습니다. 반면 보안 연구자에게 비우호적인 시각을 가진 사람들은 해커를 이상한 종족이라고 생각하는 경향이 있습니다. 양쪽 태도 모두가 결과적으로는 보안 취약점 제거 작업에 좋지 않은 영향을 줍니다. 제 개인적인 시각으로는 보안 취약점 공개가 단순한 버그 리포트의 과정이라는 것에 대해 아직 우리 사회의 이해와 합의가 부족한게 아닌가 싶습니다. 향후 상황이 더욱 나아지면 국내 기관과 협조하는 것이 아무래도 국내 보안 여건의 향상을 위해 바람직하지 않을까 생각합니다.

4. 일반에 취약점 정보 공개
 Coordinated Disclosure 과정을 거쳤다면 일반에 취약점 정보를 공개하는데 문제가 없습니다. 이 정보를 굳이 일반에 공개하는 목적은 동일 제품 사용자들의 공공의 이익을 위한 것입니다. 일부 벤더는 자사 제품의 결함을 고객에게 알리는 것을 꺼리기 때문에, 보안 결함에 대한 정보를 입수한 고객이 직접적으로 요청하는 경우에만 패치를 설치해주는 경우가 많습니다. 즉, 고객이 정보를 입수할 수 없는 경우 이 고객은 보안 취약점에 그대로 노출되게 됩니다. 따라서, 해외 보안 메일링 리스트와 같이 보안 정보가 원활하게 소통되는 곳에 정보를 올리는 것이 좋습니다. 일반적으로 일정 규모 이상의 업체들은 보안 메일링 리스트에 올라오는 보안 취약점 정보를 모니터링하기 때문에, 많은 고객들이 혜택을 입을 수 있습니다.
 일반에 취약점 정보를 공개하는 것은 벤더가 당신의  버그 리포트를 아예 묵살하거나, 협박으로만 일관하는 경우 벤더가 패치를 릴리즈하도록 압박하는 방법으로도 사용될 수 있습니다. 이 역시 동일 제품 사용자들의 공공의 이익을 위한 것입니다. 일반적으로 당신이 2~3 회에 걸쳐 벤더에 통보한 후에도 벤더가 응답이 없는 경우, 최종 통보일로부터 1개월 후에는 보안 메일링 리스트에 보안 취약점 정보를 공개하는 것이 적절하다고 받아들여지고 있습니다. 그러나 이는 보안 메일링 리스트를 통해 전세계의 해커들 사이에서 논의하면서 일반적으로 타당하다고 받아들여지게 된 수치일 뿐이니 참고 용도로만 사용하는 것이 좋습니다.

이상입니다.

사실 자잘하게 더 하고 싶은 이야기들은 많습니다. 예를 들어 해외의 ZDI (Zero Day Initiative)에 버그를 돈받고 파는 건 어떠한지... 국내의 보안 생태계에서 보안 취약점 공개를 중재하기 위해 기관들이 갖추어야할 업무 프로세스라던지, 혹은 일반적으로 사용되는 소프트웨어가 아닌, 특정 사이트의 취약점을 공개하는 것은 어떠한지... 이러한 주제들은 생각해볼 여지가 많은 주제입니다.

예를 들어, 국내에서는 아직 해커들 사이에서도 보안 취약점 공개에 대한 부정적인 시각이 존재하는 상황이며 (상당수의 해커들이 회사의 보안 담당자로 근무하기 때문에 보안 취약점 공개로 인한 업무량 증가가 달갑지 않겠죠?), 일반 소프트웨어야 모르겠지만 특정 사이트의 취약점을 공개하는 것은 공공의 이익에 오히려 반하는 것이 아니냐 라는 견해가 지배적입니다. 왜냐하면 웹 사이트는 서비스적인 성격을 갖고 있고, 상대적으로 많은 수의 사용자가 해킹의 피해를 입기 때문이죠. 그러나, 이런 견해가 적절한 절차를 거친 일반 소프트웨어의 보안 취약점 공개가 공공의 이익에 합치한다는 주장과 양립할 수 있는 것인지에 대해서는 논란의 여지가 많습니다.

이런 재미있는 주제는 앞으로 기회가 닿으면 또 이야기하기로 하고 오늘은 여기까지~
저와 다른 견해를 가지신 분의 반론은 환영합니다만, 논점없는 비난은 삼가주세요.
'내 생각과 다르다' 와 '내 생각과 틀리다' 를 적절히 구분하실 수 있는 분들의 견해라면 언제든 환영입니다.

이글루스 가든 - professional secur...