Coordinated vulnerability disclosure

협조적 취약점 공개(CVD)

보안 취약점을 보고하고, 접수하고, 조율하는 방법과 정책 예시.

협조적 취약점 공개(Coordinated vulnerability disclosure, CVD)는 컴퓨터 보안 용어입니다. 사람들이 보안 문제에 대한 보고서를 어떻게 공유할 수 있는지를 설명합니다. 예로는 버그 보고서, 침입 위험, 해킹 경고, 데이터 유출, 웹사이트 침해 등이 있습니다.

번역: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

목차:

정책:

소개

이 문서는 사람들이 함께 협력하는 데 도움이 될 수 있도록 협조적 취약점 공개를 설명합니다.

문서의 목표:

  1. 보안 문제를 발견하고 이를 보고하려는 사람들을 돕습니다.

  2. 기업 담당자가 책임 있는 공개의 필요성, 목표, 관행, 특수한 경우를 이해하도록 돕습니다.

  3. 저장소 폴더에 협조적 취약점 공개 정책 예시를 포함합니다.

풀 리퀘스트, GitHub 이슈, 또는 security@joelparkerhenderson.com 으로 보내는 이메일을 환영합니다.

협조적 취약점 공개란 무엇인가요?

협조적 취약점 공개는 누군가가 보안 문제(예: 소프트웨어 버그)를 발견하고 이를 제작자(예: 해당 소프트웨어를 만든 회사)에게 보고하려 할 때의 세 단계를 설명합니다.

단계:

  1. 발견자가 선의로 문제를 제작자에게 비공개로 보고합니다.

  2. 제작자는 선의로 사용자를 보호하고 문제를 해결하려고 노력합니다.

  3. 정해진 시간이 지난 뒤 보안 문제가 공개됩니다.

1단계: 문제 보고하기

1단계는 발견자를 위한 것입니다. 선의로 문제를 비공개로 보고하세요.

  • 좋은 예: 발견자가 관련 정보를 제작자에게 보냅니다. 예를 들어 제작자의 보안 이메일 주소(보통 "security@example.com")로 이메일을 보내거나, 제작자 웹사이트의 웹 페이지 양식(보통 "https://www.example.com/security")을 이용합니다.

  • 나쁜 예: 공개 블로그에 보고서를 게시하거나, 언론에 알리거나, 협박하거나, 보안 문제를 해커에게 팔려고 시도하는 것 등.

  • 팁: 발견자는 익명을 선택할 수 있습니다. 제작자도 익명을 선택할 수 있습니다.

원한다면 계속 그 문제에 관심을 가지세요.

  • 좋은 예: 소통 창구를 열어 두거나, 후속 정보를 제공하거나, 상황을 지켜봅니다.

  • 나쁜 예: 문제를 잊어버리는 것.

  • 팁: 발견자는 도울지 말지, 소통을 이어갈지 말지를 선택할 수 있으며, 상황이 바뀌면 합의를 바꾸기로 선택할 수도 있습니다.

원한다면 다른 사람들에게 문제를 공개하세요.

  • 좋은 예: 정해진 시간을 기다린 뒤 공개합니다. 예를 들어 보안 뉴스 사이트에 관련 정보를 게시하거나, 관련 있는 제3자 보안 연구자에게 연락하거나, 공개 소셜 사이트에 문제를 알립니다.

  • 나쁜 예: 다른 사람들에게 문제를 공개하지 않는 것. 단, 공개가 자신이나 다른 사람들에게 상응하는 수준을 넘는 위험을 초래한다고 느끼는 경우는 예외입니다.

  • 팁: 더 큰 위험이나 실제 환경에서의 활발한 익스플로잇(active exploit in the wild)을 발견하는 등 상황이 바뀌면, 발견자는 더 일찍 다른 사람들에게 문제를 공개할 수 있습니다.

2단계: 연락처 확보하기

2단계는 제작자를 위한 것입니다. 연락처가 실제로 작동하도록 확보하세요.

  • 좋은 예: 제작자가 보안 연락용 이메일 주소(관례상 "security@example.com")를 게시하고, 가능하면 안전한 이메일 암호화 키도 게시합니다.

  • 좋은 예: 제작자가 보안 연락용 웹 페이지(관례상 "https://www.example.com/security")를 게시하고, 가능하면 웹사이트 푸터, 사이트맵, 검색 등을 통해 쉽게 찾을 수 있게 합니다.

  • 나쁜 예: 제작자가 이메일 주소도 웹 페이지도 제공하지 않거나, 쉽게 찾을 수 있게 하지 않는 것.

담당 직원의 역량을 확보하세요.

  • 좋은 예: 제작자가 지원 직원에게 보안 문의를 받았을 때의 대응 방법을 교육합니다. 예를 들어 연락처 정보로 답하는 방법이나, 문의를 알맞은 내부 팀으로 전달하는 방법입니다.

  • 좋은 예: 제작자가 직원의 역량이 제대로 작동하는지 주기적으로 확인합니다.

  • 나쁜 예: 제작자가 교육하지도 확인하지도 않는 것.

일정 안에 발견자에게 응답하세요.

  • 발견자가 일정을 지정하지 않았다면 영업일 1일을 사용하세요. 이것이 업계 표준이며 현재 업계의 모범 사례이기 때문입니다.

  • 발견자가 질문하면 답하세요. 발견자가 테스트 허락을 요청하는 경우에는 특히 중요합니다. 모든 답변이 명확하고 직접적이도록 하세요.

권한 있는 보안 연락 담당자나 권한 있는 보안 절차를 통해 발견자에게 응답하세요.

  • 좋은 예: "security@example.com" 같은 보안 전용 이메일 주소에서 보낸 응답.

  • 나쁜 예의 한 가지: "help@example.com" 같은 범용 이메일 주소에서 보낸 응답, 또는 권한 있는 보안 전문가가 아닌 사람이 보낸 응답.

문제가 보안 보고서로 인식되었음을 발견자에게 알리세요.

  • 좋은 예: 보안에 특화된 표현. 예를 들어 "저희 보안 팀이 귀하의 책임 있는 공개 보고서를 접수했습니다", "저희 보안 절차의 다음 단계는 다음과 같습니다", "귀하의 정보는 이제 ID 번호 XYZ로 저희 보안 추적기에 등록되었습니다" 등.

  • 나쁜 예: 범용적인 표현. 예를 들어 "이용해 주셔서 감사합니다", "저희는 보안을 진지하게 생각합니다", 또는 책임 떠넘기기 표현, 예를 들어 "귀하의 이메일을 다른 부서로 보냈습니다" 등.

3단계: 선의로 협력하기

3단계는 발견자와 제작자가 함께 하는 것입니다. 선의로 협력하세요.

협조적 취약점 공개는 선의에 기반한 절차임을 이해하세요.

  • 첫 번째 목표는 사용자가 보안 위험으로부터 스스로를 보호하도록 선의로 돕는 것입니다.

  • 두 번째 목표는 보안 문제를 선의로 해결하는 것입니다.

  • 발견자나 제작자는 선의로 다른 보안 관계자를 참여시키기로 선택할 수 있습니다. 예를 들어 문제 해결을 돕도록 관련 있는 다른 보안 연구자에게 연락하는 것입니다.

협조적 취약점 공개는 어떠한 의무도 만들지 않음을 이해하세요.

  • 발견자나 제작자는 언제든지, 어떤 이유로든, 사전 경고가 있든 없든 빠질 수 있습니다. 관련된 모든 사람에게 최신 상황을 알리는 것은 예의 바른 일이지만, 그것이 항상 가능하거나, 현실적이거나, 바람직한 것은 아닙니다.

  • 협조적 취약점 공개는 어떠한 법적 합의도 만들지 않습니다. 발견자와 제작자 사이에 이미 법적 합의가 있다면, 관련된 모든 사람이 적절한 변호사와 상담할 것을 권합니다. 이 문서를 법률 자문으로 사용하지 마세요.

협조적 취약점 공개는 좋은 소통을 사용하고 협박을 배제하는 것을 목표로 함을 이해하세요.

  • 협조적 취약점 공개는 관련된 모든 사람이 첫 번째 목표가 사용자가 보안 위험으로부터 스스로를 보호하도록 돕는 것이고 두 번째 목표가 보안 문제를 해결하는 것임을 이해할 때 가장 좋습니다.

  • 협조적 취약점 공개는 보복, 위협, 정지, 취소, 갈취, 후속 조치의 부담 전가, 피해자 탓하기 등 모든 종류의 협박을 거부합니다.

협조적 취약점 공개는 사람마다 다른 의미일 수 있음을 이해하세요.

  • 발견자와 제작자는 협조적 취약점 공개에 대해 서로 다르게 이해할 수 있습니다. 이러한 이해가 서로 일치하지 않을 수도 있습니다. 선의란 관련된 모든 사람이 이 점을 이해하는 것을 포함합니다.

  • 일부 제작자는 협조적 취약점 공개 정책을 게시합니다. 이는 도움이 되는 지침이 될 수 있습니다. 발견자가 다른 종류의 협조적 취약점 공개를 사용하기로 하거나, 책임 있는 공개에 대해 다르게 이해하더라도 전혀 문제없습니다.

보통 발견자는 게시자에게 호의를 베풀고 있는 것임을 이해하세요.

  • 보통 발견자는 취약점을 게시하기 위해 누구의 허락도 받을 필요가 없습니다.

  • 보통 발견자의 정보는 게시자에게 도움이 됩니다.

성공 여부 확인

문제가 해결된 후 제작자는 성공 여부를 확인해야 합니다.

  • 모든 사람과 절차가 공개를 성공적으로 처리했는가? 그렇다면 좋습니다. 그렇지 않다면 근본 원인 분석(RCA), 사후 검토(post-mortem) 보고서, 이시카와 다이어그램(특성요인도), 시스템 이론 기반 인과 분석(CAST) 같은 사후 조사를 고려하세요.

  • 해결되지 않은 문제가 분류되고 추적되고 있는가?

  • 제작자와 발견자는 모두 다음 단계에서 무엇을 해야 하는지 이해하고 있는가? 후속 협조적 취약점 공개가 있을 수 있는 경우 이를 제대로 해 두는 것이 특히 중요합니다.

지침

협조적 취약점 공개에 대한 지침은 윤리 전문가, 법률 옹호자, 일반 대중의 합리적 기대 등 여러 분야에서 나올 수 있습니다.

지침을 찾고 있다면 아래에 설명하는 세 가지 영역에 관심이 있을 수 있습니다.

  • 선한 사마리아인

  • 구조 의무

  • 주의 의무

선한 사마리아인

Wikipedia: 선한 사마리아인 법

선한 사마리아인 법은 부상을 입었거나, 아프거나, 위험에 처했거나, 그 밖에 행동할 수 없는 상태에 있는(또는 그렇다고 믿어지는) 사람에게 합리적인 도움을 준 사람에게 법적 보호를 제공합니다. 이 보호는 소송을 당하거나 기소될까 두려워 방관자가 도움을 주저하는 것을 줄이려는 데 목적이 있습니다.

구조 의무

Wikipedia: 구조 의무

구조 의무는 위험에 처한 다른 당사자를 구조하지 않은 것에 대해 한 당사자가 책임을 질 수 있는 상황을 설명하는 개념입니다. 구조 의무에는 도덕적인 영역이나 법적인 영역이 있을 수 있습니다.

주의 의무

Wikipedia: 주의 의무

주의 의무는 다른 사람에게 해를 끼칠 것이 예견 가능한 어떤 행위를 할 때 합리적인 주의의 기준을 지켜야 하는 의무입니다. 주의 의무에는 도덕적인 영역이나 법적인 영역이 있을 수 있습니다. 고려할 점으로는 해악이나 상해의 예견 가능성, 잠재적 해악이나 상해의 가능한 크기, 피고가 한 활동의 중요성이나 사회적 가치, 피고에게 그 행위가 갖는 유용성, 대안적 행위의 실행 가능성, 대안적 행위에 따르는 비용과 부담, 대안적 행위의 상대적 유용성, 대안적 행위의 상대적 안전성이 있습니다.

특수한 경우

저희 보안 팀은 다양한 특수한 경우를 보아 왔습니다.

무엇이 괜찮고 무엇이 괜찮지 않은지에 대해 폭넓은 의견이 있다는 점을 사람들이 이해할 수 있도록 여기에 설명합니다. 관련된 모든 사람이 이러한 문제에 대해 선의로 소통할 것을 권합니다.

다른 사용자의 정보에 접근하기

예: URL에 자신의 사용자 ID가 들어 있고 버그가 드러나며, URL을 수정해 자신의 사용자 ID를 다른 사용자 ID로 바꿀 수 있다고 생각되는 경우.

  • 발견자가 이렇게 해도 괜찮은가요? 예를 들어 다른 사용자도 영향을 받는지 알아내는 것만을 목표로 하는 경우에도 그런가요?

  • 이미 해커에게 정보가 보이고 있을 수도 있는 몇몇 사용자를 보호하는 것보다, 모든 사용자에 대한 위험의 폭을 빨리 파악하는 것이 더 중요한가요?

  • 발견자가 원하는 만큼 많은 사용자에게 이렇게 해도 괜찮은가요?

  • 발견자가 영향을 받았음을 알리려고 사용자에게 연락을 시도해도 괜찮은가요? 완화 방법을 제안해도 괜찮은가요?

서비스 거부

예: 비밀번호 잠금이 작동하는 것처럼, 버그로 인해 우연히 자신의 계정이 정지되는 것을 발견하는 경우.

  • 이것은 서비스 거부 공격으로 간주되나요?

원치 않는 이메일

예: 회사 안에서 관련이 있다고 생각되는 사람들, 즉 LinkedIn, Facebook 등을 조사하거나 "webmaster@example.com", "security@example.com" 같은 명명 관례를 이용해 알아낸 사람들에게 보안 문제를 보고하려고 시도하는 경우.

  • 이것은 괜찮은가요?

  • 이것은 원치 않는 이메일(unsolicited email)로 간주되나요?

  • 이것은 승인되지 않은 이메일(unauthorized email)로 간주되나요?

제외된 집단

예: 미성년자이거나, 제재 대상 목록에 올라 있거나, 제재 대상 목록에 있는 국가에 있는 등 제외된 집단에 속해 있는 경우.

  • 보고를 해도 괜찮은가요?

  • 익명으로 보고해도 괜찮은가요?

  • 제외된 집단을 피하기 위해, 그리고 공개가 알맞은 사람들에게 닿도록 돕겠다는 목표로, 신원을 식별할 수 있는 정보를 고의로 바꿔도 괜찮은가요?

제3자

예: 어떤 회사의 소프트웨어에, 다른 소프트웨어나 다른 웹사이트와의 연동처럼 제3자가 관련된 버그가 있음을 발견하는 경우.

  • 발견한 모든 정보를 양쪽 모두에게 보고해도 괜찮은가요?

  • 각 회사에 보내는 정보를 제한할 목적으로, 한 회사에 대한 보고와 제3자 회사에 대한 다른 보고라는 두 번의 별도 책임 있는 공개를 해야 하나요?

  • 발견자가 두 회사를 서로 연결해 줘도 괜찮은가요?

방해가 되는 소프트웨어

예: 사용자가 보안 위험으로부터 스스로를 보호하거나, 자신이 위험에 처했는지 확인하거나, 보안 위험을 고치는 데 도움이 될 것이라고 믿는 바이러스를 작성할 수 있을 만큼 숙련된 경우.

  • 괜찮은가요?

  • 발견자가 이런 종류의 소프트웨어, 그리고/또는 이런 종류의 소프트웨어를 만드는 방법을 설명하는 가이드나 튜토리얼로 사용자를 안내해도 괜찮은가요?

협조적 취약점 공개와 책임 있는 공개의 비교

협조적 취약점 공개가 선호되는 용어입니다.

  • 가장 중요한 것은 발견자와 제작자 사이의 협조입니다.

책임 있는 공개(responsible disclosure)는 사용이 권장되지 않는 용어입니다.

  • 책임 있다는 것이 무엇인지에 대해 사람들은 서로 다른 견해를 가집니다. 예를 들어 어떤 사람들은 제작자와의 상호작용에 관계없이 발견자가 즉시 대중에게 알리는 것이 책임 있는 행동이며, 협조적 취약점 공개는 대중에게 정보를 숨기므로 무책임하다고 주장합니다.

추적 정보