Coordinated vulnerability disclosure
← 정책

NCSC.nl

1. 소개

사회는 점점 더 디지털화되고 있습니다. 오늘날 거의 모든 과정이 휴대폰에서 전문 소프트웨어에 이르기까지 어느 시점엔가 컴퓨터의 사용을 수반합니다. 이러한 발전은 많은 새로운 기회를 만들지만, IT 시스템의 취약점은 큰 영향을 미칠 수 있습니다. 따라서 이러한 취약점에 관한 지식은 효과적으로 다루어져야 합니다.

2013년 초에 일부 조직이 취약점을 보고하는 방법에 관한 정책을 게시하기 시작했습니다. 이들 조직과의 협의 후, 국가사이버보안센터(NCSC)는 이러한 동향을 '책임 있는 공개 관행에 이르기 위한 지침'(네덜란드어: 'Leidraad om te komen tot een praktijk van Responsible Disclosure'; 이하 '지침')의 형태로 정리했습니다. 기업은 이 정책을 통해 외부 취약점 보고를 받을 용의가 있음을 밝히고, 전제 조건을 설명하며, 약속을 합니다. 이 과정은 보고자가 곧바로 범죄 행위를 저지르지 않고 취약점을 조사하고 보고할 수 있는 명확성과 어느 정도 안전한 환경을 만들었습니다. 2016년 EU 사이버 보안 고위급 회의에서 29개 조직은 CIO Platform Netherlands와 Rabobank가 NCSC와 협력하여 주도한 협조적 취약점 공개 선언문(Coordinated Vulnerability Disclosure Manifesto)1에 서명함으로써, 취약점을 다루는 정책의 중요성을 재확인했습니다.

협조적 취약점 공개(CVD)는 공공 및 민간 당사자 모두에게 매우 중요한 것으로 입증되었습니다. 이들은 일상 업무에서 정보 시스템이 방해받지 않고 기능하는 데 크게 의존합니다. 이들 시스템의 취약점에 대한 보고는 한편으로 취약점을 바로잡고 다른 한편으로 네덜란드 기업의 IT 보안에 대한 전반적 인식에 기여함으로써, 최근 몇 년간 시스템의 보안과 연속성을 개선하는 데 도움이 되었습니다.

최근 몇 년 동안 보고자들이 조직이 마련한 CVD 정책의 조건 안에서 활동할 의사가 있다는 것이 분명해졌습니다. 보고는 보고자가 조직에 직접 또는 간접적으로 합니다. 책임 있는 공개 관행은 선의의 보고자와 취약한 조직이 협력할 수 있었고, 그리하여 네트워크 및 정보 시스템의 보안을 높이는 다음 단계로 나아갔음을 보여 주었습니다.

이번 개정을 위해서도 저희는 폭넓고 다양한 보고자, 민간 및 공공 당사자는 물론 검찰청과 국가경찰과 다시 대화를 나누었습니다. 이 대화들은 현재의 관행을 확인해 주었고, 추가와 개선으로 이어졌습니다. 가장 중요한 새로운 주목점은 취약점 보고자와 조직 사이의, 그리고 취약점이 해결된 후 다른 당사자들과의 소통입니다.

다음 장들에서는 CVD의 정의, CVD 정책의 구성 요소, 그리고 소통 과정을 다룹니다.

참고: 이전 지침은 당시 이 관행의 일반적인 용어였던 '책임 있는 공개(responsible disclosure)'라는 용어를 사용했습니다. 그동안 이 용어가 보고자의 책임을 지나치게 강조한다는 점이 분명해졌습니다. 기본 원칙은 보고자와 잠재적으로 취약한 조직이 대화에서 대등한 파트너여야 한다는 것입니다. 이러한 정서는 현재 흔히 쓰이는 용어인 '협조적 취약점 공개(Coordinated Vulnerability Disclosure, CVD)'가 더 잘 담아내며, 이는 이 과정에 관한 ISO 29147 및 30111 표준에서 사용하는 명칭이기도 합니다.

2. 협조적 취약점

지난 30년 동안 IT 시스템의 취약점에 대한 인식을 높이기 위해 다양한 방법이 사용되었습니다. 예는 다음과 같습니다:

  • '전체 공개(Full Disclosure)': 취약점을 완전히 공개하는 것.

  • '비공개(Non-disclosure)': 취약점을 팔거나 스스로 사용하는 것.

  • '협조적 취약점 공개(Coordinated Vulnerability Disclosure, CVD)': 취약점을 협조하여 공개하는 것.

후자의 관행이 명시적으로 선호됩니다.

IT 커뮤니티는 지식과 경험을 공유하려는 큰 의지를 보여 왔습니다. 따라서 이 커뮤니티와 협력을 구하는 것은 시스템 전반의 보안을 개선하는 데 도움이 될 수 있습니다.

협조적 취약점 공개의 목적

CVD의 목적은 취약점에 관한 지식을 공유함으로써 IT 시스템의 보안에 기여하는 것입니다. CVD에서는 지식이 하나 이상의 잠재적으로 취약한 조직과 공유되어, 보고자와의 협력으로 발견된 취약점에 대한 공동의 해결책에 이릅니다. 영향을 받는 조직이 손실이나 피해를 가능한 한 제한하거나 막기 위해 취약점을 바로잡거나 시스템을 보호할 충분한 시간을 갖는 것이 중요합니다. 이 과정의 초석은 해결 후 취약점에 관한 지식을 공개하는 것입니다.

CVD에서는 모든 당사자가 취약점을 어떻게 보고하고 어떻게 처리할지에 관한 합의를 준수하는 것이 필수적입니다. 조직이 미리 전제 조건을 게시하는 것, 예를 들어 어떤 시스템이 범위에 포함되고 어떤 종류의 조사를 수행할 수 있는지를 밝히는 것이 도움이 됩니다. 이러한 전제 조건의 중요한 원칙은 조사와 보고가 정해진 조건 안에서 이루어지는 한, 조직이 원칙적으로 보고자를 신고하거나 다른 법적 조치를 취하지 않는다는 것입니다. 이 지침은 조직이 CVD의 원칙을 구현하는 자체 정책을 수립하는 데 지침을 제공합니다.

이름이 나타내듯이, CVD의 핵심은 조직과 보고자가 서로 조율하는 것입니다. 이 점에서 취약점을 보고하는 사람과 문제 해결을 책임지는 조직 내 담당자 사이의 연결 고리는 가능한 한 적어야 합니다.

취약점이 많은 시스템에 영향을 미치는 경우 여러 당사자에게 동시에 알리는 것이 중요할 수 있습니다. 그런 경우 NCSC나 보안 커뮤니티 내의 다른 당사자들이 조율하는 역할로 CVD 과정을 지원할 수 있습니다.

3. 책임 영역

CVD 정책을 추구하는 목적은 보고자와 조직이 협력하여 IT 시스템의 취약점을 줄이는 것입니다. 이 정책의 시행은 정보 보안에 관한 기존 조치를 보완하는 것으로 보아야 합니다. 여러 행위자는 각각 고유한 역할과 책임이 있습니다. 이는 아래에서 더 자세히 설명합니다.

시스템을 소유·관리하는 조직

시스템을 소유·관리하거나 공급하는 조직은 해당 시스템의 보안에 대해 일차적인 책임이 있습니다. 다시 말해 그 조직은 취약점 보고에 대한 후속 조치에도 책임이 있습니다.

조직은 이 지침을 사용하여 자체 CVD 정책을 수립하고 이 정책을 잠재적 보고자에게 알리기로 선택할 수 있습니다. CVD 정책을 게시함으로써 조직은 취약점에 관한 정보를 받을 의사가 있음을 보여 줍니다.

CVD 정책을 수립하는 당사자는 정책에 적용되는 규칙이 지켜지는 한 경찰에 고소하지 않겠다는 원칙을 약속할 수 있습니다.

보고자가 취약점을 보고하면 책임은 조직에 있습니다. 보고자가 흔히 조직 외부의 사람이라는 점을 인식하는 것이 중요합니다. 이 당사자는 취약점이 보고된 후 시작될 수 있는 내부 절차를 직접 볼 수 없습니다. 따라서 보고자는 취약점 해결의 진행 상황에 대해 알림을 받는 것을 고맙게 여길 것입니다. 이러한 지속적인 소통은 후속 조치와 해결의 적시성에 대해 올바른 기대를 만드는 데에도 중요합니다.

취약점을 보고하는 당사자

보고자는 어떤 식으로든 취약점을 확인할 수 있었고, 이 취약점이 바로잡히고 나중에 공개될 수 있도록 함으로써 IT 시스템의 보안에 기여하고자 합니다. 보고자는 수동적 관찰이나 IT 시스템에 대한 적극적 테스트를 통해 무언가를 발견했을 수 있습니다. 물론 이 당사자는 자신의 행동과 취약점을 발견한 방식에 책임이 있습니다. 조직이 CVD 정책에서 정한 조건을 숙지하는 것은 보고자 자신의 책임입니다. 대부분의 정부와 기업은 웹사이트에 CVD 정책을 게시했습니다.

그럼에도 취약점을 찾는 일은 법을 어기는 일을 수반할 수 있습니다. CVD의 맥락에서 조직과 보고자는 어떠한 범죄 행위에 대해서도 고발하지 않기로 합의할 수 있습니다. 이 점에서 조직이 게시한 CVD 정책이 지침 원칙이 됩니다. 당사자들은 민사 조치도 취하지 않기로 합의할 수 있습니다.

보고자가 법을 어겼다는 의심이 있는 경우, CVD 정책은 우선 보고자가 당국에 신고되는 것을 막는 데 도움이 될 수 있습니다. 이 절차는 조직이 보고자에게 준수를 요구하는 정책의 전제 조건과 이러한 준수가 이루어졌는지에 전적으로 달려 있으며, 경우에 따라 당사자가 정책의 조건 안에서 활동하는 한 형사 고소를 하지 않겠다는 상응하는 약속이 수반됩니다. 경찰에 신고가 접수되는 경우, CVD 정책의 존재와 그 준수는 네덜란드에서 관련 사정이며, 검사는 형사 수사를 개시할지 및/또는 기소할지를 결정할 때 이를 고려합니다. 원칙적으로 보고자가 해당 조직의 CVD 정책 규칙을 분명히 준수한 경우 경찰과 검찰청(OM)은 형사 수사를 개시하지 않습니다. 그러나 보고자가 의식적으로든 무의식적으로든 행동이 지나쳤거나 및/또는 CVD 정책을 준수하지 않았음을 시사하는 징후가 있는 경우, 검찰청과 경찰은 사건을 더 조사할 수 있습니다. 이 조사를 근거로 검찰청은 기소 여부를 결정할 수 있습니다.

검찰청은 수사 및/또는 기소 결정에 이르는 데 중요한 측면을 더 구체적으로 다루는 정책 서한을 게시했습니다. 예를 들어 보고자의 행동이 중요한 공익에 기여했는지, 당사자가 불균형하게 행동했는지, 당사자가 어쩌면 다른, 덜 과격한 방식으로 행동할 수 있었는지 등입니다. 해당 정책 서한은 이러한 측면을 더 자세히 설명합니다.2 2013년 이후의 관련 판례3는 조직에 CVD 정책이 없는 경우에도 이러한 측면이 법원에서 고려됨을 보여 줍니다.

4. 협조적 취약점 공개 과정의 구성 요소

조직, 보고자, NCSC를 위한 CVD 과정을 구성하는 구성 요소는 아래와 같습니다.

조직

CVD의 촉진은 IT 시스템을 소유하거나 IT 제품/시스템을 공급하는 조직에서 시작됩니다. 결국 이 조직이 이 IT 시스템의 정보 보안에 대해 일차적인 책임이 있기 때문입니다. 취약점을 해결하기 위해 여러 당사자와 효과적으로 협력하려면 조직은 CVD 정책을 수립하고 게시하기로 결정할 수 있습니다. 자체 CVD 정책을 수립하면 조직은 취약점 보고를 어떻게 다루는지 보여 줄 수 있습니다. 이렇게 하여 조직은 어떤 방식으로 알림을 받고자 하는지도 구체화할 수 있습니다. 이러한 과정은 다음과 같이 구성할 수 있습니다:

  • 조직은 CVD 정책을 수립하고 게시한다.

  • 이 정책에서 조직은 보고자가 수행할 수 있는 조사에 대해 명확한 규칙을 제시한다. 예를 들어 어떤 기법이 허용되는지, 어떤 시스템이 범위 안이고 범위 밖인지 등이다.

  • 조직은 보고자가 쉽게 보고할 수 있게 한다. 한 가지 방법은 표준화된 보고 방법, 예를 들어 특정 이메일 주소나 온라인 양식을 사용하는 것이다. 또한 조직은 익명 보고를 받을지 여부를 결정할 수 있다.

  • 조직은 보고에 적절히 대응하기 위해 내부 역량을 확보하고 절차를 마련한다. 발견된 모든 취약점을 적절히 바로잡을 수 있는 절차를 마련하는 것이 바람직하다. 이 점에서 보고의 출처는 중요하지 않다. 취약점은 예를 들어 내부 직원이나 테스트 중에 확인되었을 수도 있다.

  • 실무 경험에 따르면 CVD 정책을 처음 게시한 후에는 조직에 취약점을 보고하려는 관심이 더 커진다. 조직은 (추가) 역량을 계획할 때 이를 고려해야 한다.

  • 조직이 취약점 보고를 받으면, 보고를 평가하고 처리하기에 가장 적합한 부서에 가능한 한 빨리 보고가 전달되도록 한다.

  • 조직은 보고자에게 접수 확인을 보낸다. 우선순위를 강조하기 위해 가급적 전자 서명을 한다.

  • 이어서 조직은 보고자와 협의하여 공개가 이루어질 기간을 정한다. 이 기간은 취약점의 성격과 시스템의 종류에 크게 좌우된다.

  • 지침으로서 소프트웨어 취약점에는 흔히 약 60일의 기간이 사용된다. 하드웨어의 취약점을 바로잡는 것은 달성하기가 더 어렵다. 6개월의 지침을 사용할 수 있다.

  • 취약점이 보고된 시스템에 의존하는 IT 시스템이 많은지 적은지, 또는 취약점을 해결하기가 더 쉬운지 어려운지에 따라 상호 합의로 이 기간을 연장하거나 단축하는 것이 바람직할 수 있다.

  • 취약점이 해결하기 어렵거나 불가능한 것으로 드러나거나 해결에 높은 비용이 들 수 있다. 그런 경우 조직은 경우에 따라 보고자와 협의하여 그 취약점을 수용된 위험으로 간주하고 바로잡지 않기로 동의할 수 있다.

  • 조직은 보고자에게 과정의 진행 상황을 계속 알린다.

  • 또한 조직은 취약점을 공개한 것에 대해 보고자를 공개적으로 인정할 것을 제안할 수 있다. 외부에 공동으로 공개하는 방법을 선택할 수도 있다.

  • 보고자가 CVD 정책의 규칙을 준수한 경우 시스템의 취약점을 보고한 데 대해 보고자에게 보상하는 것이 바람직하다. 보상 금액은 보고서의 품질에 따라 달라질 수 있다. 보고자에게 보상하면 그 당사자와 조직 사이에 더 나은 관계를 만들 수 있고 CVD 정책에 따라 새로운 보고를 하려는 사람들의 의지도 높일 수 있다.

  • 보고자와 협의하여, 취약점이 다른 곳에도 존재할 가능성이 있다면 조직은 더 넓은 IT 커뮤니티에 취약점에 대해 알리는 데 동의할 수 있다.

  • CVD 정책에서 조직은 보고자가 정책에 제시된 규칙을 준수한 경우 경찰에 고소하지 않겠다는 원칙을 스스로 약속할 수 있다.

보고자

보고자는 성공적인 CVD 과정의 열쇠입니다. 이 당사자는 어떤 식으로든 취약점을 확인할 수 있었고, 이 취약점이 조직에 의해 바로잡히고 공개되도록 함으로써 IT 시스템의 보안에 기여하고자 합니다. 그렇게 함으로써 보고자는 취약점을 협조적인 방식으로 드러내어 사회에 중요한 기여를 할 수 있음을 인정합니다. 성공적인 CVD 과정을 이루려면 보고자에게 다음 구성 요소가 중요합니다:

  • 보고자는 자신의 행동에 책임을 지며, 취약점을 조사하고 보고할 때 비례성의 원칙과 보충성의 원칙을 모두 지켜야 한다. 다시 말해 보고자는 취약점을 입증하는 데 필요한 것 이상을 해서는 안 되며, 항상 먼저 시스템/정보 소유자에게 취약점을 보고해야 한다.

  • 악의적인 당사자가 취약점을 발견하여 악용하는 것을 막기 위해 보고자는 문제를 가능한 한 빨리 보고해야 한다.

  • 다른 사람들이 이 정보에 접근하는 것을 막기 위해 보고자는 조직에 대한 보고를 기밀 방식으로 해야 한다.

  • 보고자는 보고서 제출이나 추가 정보 제공을 보상에 달려 있게 해서는 안 된다. 보고가 있을 때 보상을 줄지의 주도권은 수신 조직에 있으며, 조직은 게시된 정책에서 전제 조건을 제시할 수 있다.

  • 보고자와 조직은 취약점 공개에 대해 명확히 합의한다. 둘 이상의 조직이 관련된 경우, 모든 조직이 그 사실에 동의하는 경우에만 취약점을 게시할 수 있다는 것이 기본 원칙이다. 이러한 합의를 초기 단계에 해 두는 것이 바람직하다.

  • 보고자와 관련 조직은 더 넓은 IT 커뮤니티에 알리는 것에 대해 합의할 수 있다. 예를 들어 이 상황은 둘 이상의 장소에 존재하는 것으로 알려진 취약점(이미 알려졌는지 여부와 관계없이)에 적용될 수 있다. 국가사이버보안센터(NCSC)는 중앙 정부와 핵심 기반 시설의 대상 그룹을 지원하거나 많은 시스템에 영향을 미치는 취약점의 경우 여러 당사자에게 알리기 위해 이 과정에 참여할 수 있다.

NCSC

CVD 과정은 일차적으로 조직과 보고자의 문제입니다. 그럼에도 NCSC는 CVD 과정의 활용을 장려합니다. 보고자 및 조직과 협의하여 NCSC는 취약점에서 비롯되는 추가 보안 위험을 제한하기 위해 자신의 대상 커뮤니티(constituency)와 취약점에 관한 정보를 공유하는 데에도 참여할 수 있습니다.

취약점 보고가 보고자의 기대대로 진행되지 않거나 취약점을 조직에 직접 보고하고 싶지 않은 경우, 보고자는 NCSC에 연락할 수 있습니다.4 이 경우 NCSC는 필요에 따라 중개자 역할을 할 수 있습니다.

IT 시스템의 소유자는 언제나 시스템의 보안에 책임이 있습니다. NCSC는 시스템 소유자가 취약점을 바로잡도록 강제할 수 없으며, 소유자가 보고자에 대해 법적 조치를 취하지 않을 것이라고 보장할 수도 없습니다. 그 결과 보고자는 취약점을 찾고 보고할 때 조직과 보고자를 위한 앞서 언급한 구성 요소를 고려해야 합니다. 보고자는 NCSC가 취약점이 바로잡히도록 최선을 다하고 보고를 기밀로 취급할 것으로 기대할 수 있습니다. NCSC는 법적으로 의무가 있는 경우가 아니면 어떤 개인 데이터도 공유하지 않습니다.

가능하다면 NCSC는 조직 및 보고자와 협의하여 취약점에 대해 얻은 정보를 IT 커뮤니티와의 지식 공유에 활용합니다. 예를 들어 정보의 일부를 게시하거나, 팩트시트나 백서를 작성하거나 업데이트하거나, 특정 조직에 알리는 방식으로 할 수 있습니다.

  • 해당 조직과 확인된 취약점의 성격에 따라 NCSC는 취약점을 해당 조직이 알 수 있도록 노력한다. 다만 해당 IT 시스템의 소유자가 시스템에 대한 책임을 계속 진다.

  • 가능하고 필요한 경우 NCSC는 해당 조직에 취약점을 바로잡는 방법에 대한 조언을 제공한다.

  • NCSC는 보고를 기밀로 취급하며, 법정 의무에서 비롯되는 경우가 아니라면 동의 없이 보고자나 수신 조직의 개인 데이터를 공유하지 않는다.

  • 가능한 한 NCSC는 조직과의 연락 및 취약점 해결의 진행 상황을 보고자에게 계속 알린다.

  • NCSC에 보고가 이루어진 경우, NCSC는 보고자 또는 잠재적 보고자와 조직이 서로 연결되도록 노력한다.

보고자가 예를 들어 소프트웨어 제품의 취약점이나 매우 다양한 시스템에 영향을 미치는 취약점을 발견한 경우, 보고자는 NCSC에 취약점의 해결과 공개를 조율해 달라고 요청할 수 있습니다.

보고자, 파트너, 개발자 및/또는 소프트웨어 개발자, 그리고 다른 보안 팀과 함께 NCSC는 취약점을 분석하고, 바로잡거나 바로잡히게 하고, 조율하고, 통제된 방식으로 공개하는 것을 도울 것입니다. 이 모든 과정은 취약점을 발견한 보고자와 긴밀히 협의하여 이루어집니다.

CVD 정책은 조치를 취할 수 있도록 취약점을 가능한 한 빨리 공개하는 것의 중요성과, 개발자와 공급자가 취약점을 바로잡을 충분한 시간을 갖는 것의 중요성 사이에서 균형을 맞추려 합니다. 이 과정에서 NCSC는 보고와 공개 사이에 60일이라는 표준 기간을 사용합니다. 그러나 이 기간을 연장하거나 단축하기로 결정할 수 있는 상황이 있을 수 있습니다.

NCSC는 보고자와 협의한 후에만 취약점에 관한 정보를 제3자와 공유합니다. 이 맥락에서 NCSC가 협력하고, 따라서 취약점을 협조하여 공개하기 위해 이해관계자와 취약점에 관한 정보를 공유하는 것이 필수적입니다. 이때 NCSC는 알맞은 당사자들이 취약점을 바로잡는 작업을 할 수 있도록 하고, 손실이나 피해를 제한하는 데 도움을 주며, 발견된 취약점에 주의를 환기하는 데 도움을 줄 것입니다.

5. 소통과 공개 과정

5년간의 실무는 명확한 소통이 성공적인 CVD 과정의 초석임을 보여 주었습니다. CVD 과정의 시작, 진행 중, 그리고 이후에 주의할 점이 있습니다.

공개 과정에 관한 소통

CVD 정책의 게시는 과정에 관한 소통의 첫걸음입니다. 정책을 공개적으로 게시함으로써 보고자는 발견한 취약점을 조직에 알리도록 초대받습니다.

한편으로 조직은 취약점을 찾기 위해 수행되는 조사의 조건과 연락하는 방법에 대한 조건을 정할 수 있습니다. 다른 한편으로 조직은 정책의 규칙이 지켜지는 한 경찰에 고소하지 않겠다는 원칙을 스스로 약속할 수 있습니다. 이 접근법은 보고자의 입장을 보호합니다.

CVD 정책은 나중에 변경되거나 업데이트될 수 있습니다. 이 점에서 변경 사항을 명확히 하는 것이 중요합니다. 보고자는 무엇이 언제 변경되었는지 아는 데 이해관계가 있습니다. 예를 들어 CVD 정책의 맨 앞에 게시 날짜를 넣거나, CVD 정책 아래에 변경 사항 요약을 기술하거나, CVD 정책의 이전 버전 아카이브를 보관함으로써 변경 사항을 명확히 할 수 있습니다.

CVD 정책은 과정 중 소통 방법에 대한 지침을 제공할 수 있습니다. 예를 들어 이메일이나 웹 포털을 통한 정기 업데이트를 명시하는 것입니다. 또한 CVD 정책은 업데이트에서의 언급, 명예의 전당(hall of fame) 등재 또는 그 밖의 형태의 보상을 통해 보고자를 어떻게 인정할 수 있는지 기술할 수 있습니다.

공개 과정 중의 소통

보고자는 조직에 메시지를 보냄으로써 CVD 과정을 시작합니다. 이 메시지에서 보고자는 발견한 취약점을 명확하게 설명합니다. 중요한 요소는 영향을 받는 시스템의 IP 주소 또는 URL과 취약점을 재현하는 데 필요한 단계입니다.

조직이 보고자에게 명확하게 소통하여 과정에 대한 기대가 분명해지도록 하는 것이 중요합니다.

조직은 최초의 또는 이후의 실질적인 응답이 전송될 기간의 표시를 담은 접수 확인(자동이든 아니든)을 보냄으로써 이미 그렇게 할 수 있습니다.

이 기간을 열어 두고, 보고서의 내용을 평가한 후에 기간의 최초 표시를 제공하는 것도 가능합니다. 해결책을 얻을 수 있는 기간에 대해 가능한 한 빨리 명확히 하는 것이 바람직합니다. 이렇게 하면 보고자는 결과를 언제 기대할 수 있는지 알게 됩니다.

경우에 따라서는, 예를 들어 학회 발표가 있거나 보고자가 자체 기한을 정해 두었기 때문에 공개 날짜가 이미 보고자에게 분명할 수 있습니다. 이 경우에도 보고자가 이 일정을 명확하게 알리고, 가능한 한 일찍 밝히며, 이 날짜를 연기할 수 있는지/없는지에 대해 분명히 하는 것이 중요합니다.

보고자는 흔히 조직 외부의 사람이며, 보고로 인해 시작될 수 있는 내부 절차를 알 수 없습니다. 조직은 정기 업데이트를 통해 보고자에게 과정의 진행 상황을 계속 알릴 수 있습니다. 이러한 접근은 해결책이 마련되고 있음을 보고자에게 분명히 해 줍니다. 필요한 경우 조직은 과정 중에 설명을 요청하거나 해결책을 테스트해 달라고 요청할 수 있습니다.

조직이 최초의 해결 기한을 맞출 수 없는 경우, 보고자와 논의하여 연기할 수 있습니다. 정기적인 소통은 이러한 상황을 보고자에게 더 이른 단계에서 분명히 할 수 있습니다.

CVD의 주된 의도는 취약점을 완화하는 것이지만, 과정이 너무 오래 걸릴 것이라고 보고자가 느낀다면 취약점의 '전체 공개'는 언제나 보고자에게 열려 있는 선택지입니다. 이 수단은 보고자가 쓸 수 있는 이른바 '큰 몽둥이'입니다. 당연히 이러한 상황은 최대한 막아야 합니다.

공개 과정 이후의 소통

보고자가 취약점을 찾아 CVD 과정을 통해 조직에 보고하는 데에는 여러 가지 가능한 이유가 있습니다. 많은 보고자에게 중요한 동기는 (공개적) 인정입니다.

보고자는 업데이트에서의 감사 표시나 명예의 전당 등재를 통해 공개적으로 인정받습니다. 그러나 공개적 인정의 필요가 모든 보고자에게 해당하는 것은 아닙니다. 실제로 일부는 대중에게 알려지기를 원하지 않습니다. 따라서 조직이 소통하는 경우 보고자의 이름을 거론하는 데 대해 보고자의 동의를 얻는 것이 바람직합니다.

또한 보고자는 CVD 과정이 완료된 후 보고에 대해 소통하기로 결정할 수도 있습니다. 예를 들어 보고자는 발견 과정을 설명하거나 다른 사람들에게 취약점에 대해 경고할 수 있습니다. 보고자는 정보 제공 목적으로 해당 게시물을 조직에 제출하기로 결정할 수도 있습니다. CVD 과정은 원칙적으로 취약점이 제거되면 완료되므로, 정책이나 과정 중에 추가 합의가 이루어지지 않은 한 보고자는 그 후 이에 관해 자유롭게 소통할 수 있습니다.

목록

공개 과정에 관한 소통

  • 웹사이트에 CVD 정책 게시

  • 제한 사항을 명확히 할 것(다양한 접근법은 6장 참조)

  • 조사 방법의 제한

  • 소통에 관한 지침

  • 가능한 보상에 관한 지침: 명예의 전당, 금전적 보상, 티셔츠 등

  • CVD 정책의 업데이트를 변경 날짜를 포함하여 명확히 할 것

공개 과정 중의 소통

  • 보고자가 발견한 취약점에 대해 조직에 연락한다.

  • 조직이 최초의 기술적 응답까지의 응답 시간 같은 기대를 관리한다.

  • 조직과 보고자가 예상 해결 기간에 대해 서로에게 명확히 한다.

  • 조직이 (과정) 업데이트를 자주 제공한다.

  • 필요한 경우 보고자와 조직이 다른 관련 조직에 연락하는 것에 대해 논의한다.

공개 과정 이후의 소통

  • 보고자에 대한 (공개적) 인정과 보상을 논의한다.

  • 취약점에 관한 정보가 어떻게 게시될지, 예를 들어 조사 단계나 다른 조직에 알리는 방식을 정한다.

6. 협조적 취약점 공개 정책의 예시

협조적 취약점 공개에 관한 정책 문안에는 여러 가지 형태가 있습니다. 게시된 CVD 정책은 잠재적 보고자에게 이정표 역할을 하므로, 이 정책의 형식이 조직의 정책 및 전략과 일치하도록 하세요.

CVD 정책에서는 다음 요소가 중요합니다:

  • 안전한 소통을 위한 연락 방법

  • 보고자를 위한 전제 조건

  • 보고 처리에 대한 명확한 기대

  • 보고에 대한 보상 방법

  • 버전 번호와 최신 개정 날짜

아래에 세 가지 예시가 있습니다. 네덜란드의 많은 조직이 ResponsibleDisclosure.nl의 기본 예시를 참고했습니다. 다른 조직은 추가 전제 조건을 포함합니다. Fox IT의 정책을 참조하세요. 또 다른 조직은 대상 독자에 맞추기 위해 더 자유로운 형식을 적용합니다. Bits of Freedom의 정책을 참조하세요.

Acme Corporation은 저희 시스템의 보안을 최우선 과제로 생각합니다. 그러나 시스템 보안에 아무리 많은 노력을 기울여도 취약점이 존재할 수 있습니다.

취약점을 발견하셨다면, 가능한 한 빨리 해결할 조치를 취할 수 있도록 알려 주세요.

저희 고객과 시스템을 더 잘 보호할 수 있도록 도와 주시기를 부탁드립니다.

다음을 해 주세요:

  • 발견한 내용을 cert@example.com으로 이메일로 보내 주세요. 이 중요한 정보가 잘못된 사람의 손에 들어가지 않도록 저희 PGP 키로 발견한 내용을 암호화해 주세요.

  • 발견한 취약점이나 문제를 악용하지 마세요. 예를 들어 취약점을 입증하는 데 필요한 것보다 많은 데이터를 다운로드하거나 다른 사람의 데이터를 삭제하거나 수정하지 마세요.

  • 문제가 해결될 때까지 다른 사람에게 문제를 알리지 마세요.

  • 물리적 보안 공격, 사회공학, 분산 서비스 거부, 스팸 또는 제3자의 애플리케이션을 사용하지 마세요.

  • 문제를 재현할 수 있는 충분한 정보를 제공해 주세요. 그래야 가능한 한 빨리 해결할 수 있습니다. 보통은 영향을 받는 시스템의 IP 주소나 URL과 취약점에 대한 설명이면 충분하지만, 복잡한 취약점은 추가 설명이 필요할 수 있습니다.

저희의 약속:

  • 보고서에 대한 저희의 평가와 예상 해결일을 담아 영업일 3일 이내에 응답하겠습니다.

  • 위 지침을 따르셨다면 보고와 관련하여 귀하에 대해 어떠한 법적 조치도 취하지 않겠습니다.

  • 보고서는 엄격히 기밀로 처리하며, 귀하의 허락 없이 개인 정보를 제3자에게 전달하지 않겠습니다.

  • 문제 해결의 진행 상황을 계속 알려 드리겠습니다.

  • 보고된 문제에 관한 공개 정보에서, (달리 원하지 않으시는 한) 문제의 발견자로서 귀하의 이름을 밝히겠습니다.

  • 도움에 대한 감사의 표시로, 아직 저희가 알지 못했던 보안 문제를 보고해 주실 때마다 보상을 드립니다. 보상 금액은 유출의 심각도와 보고서의 품질에 따라 결정됩니다. 최소 보상은 50유로 상품권입니다.

저희는 모든 문제를 가능한 한 빨리 해결하기 위해 노력하며, 문제가 해결된 후 최종 게시에서 적극적인 역할을 하고자 합니다.

예시: Fox-IT

Fox-IT는 저희 시스템, 네트워크, 제품의 보안을 가장 중요하게 생각합니다. 보안에 대해 세심한 주의를 기울이지만 약점이 남아 있을 수 있습니다. 그러한 약점을 발견하셨다면, 가능한 한 빨리 적절한 조치를 취할 수 있도록 되도록 빨리 알려 주세요.

약점은 두 가지 방식으로 발견될 수 있습니다. 디지털 환경을 평소처럼 사용하다가 우연히 어떤 것을 마주치거나, 약점을 찾기 위해 명시적으로 최선을 다하는 경우입니다.

저희의 책임 있는 공개 정책은 약점을 찾기 위해 저희 업무 네트워크를 적극적으로 스캔하라는 초대가 아닙니다. 저희는 업무 네트워크를 직접 모니터링합니다. 따라서 스캔이 탐지될 가능성이 높고, 저희 보안 운영 센터(SOC)가 조사를 수행하게 되어 불필요한 비용이 발생할 수 있습니다. 그러나 오프라인의 비운영(non-production) 환경에서 저희 제품의 취약점을 적극적으로 찾고 그 결과를 저희에게 보고해 주시는 것은 환영합니다. 고객에 대한 저희의 책임은 고객의 인프라에 대한 해킹 시도를 장려하려는 것이 저희의 의도가 아님을 의미합니다. 다만 취약점이 발견되면 적절히 해결할 수 있도록 가능한 한 빨리 연락해 주시기를 바랍니다.

저희 고객과 시스템을 더 잘 보호할 수 있도록 귀하와 협력하고 싶습니다.

다음을 부탁드립니다:

  • 발견한 내용을 가능한 한 빨리 security-alert@fox-it.com으로 이메일로 보내 주세요.

  • 취약점을 악용하지 마세요. 예를 들어 데이터를 다운로드하거나 편집하거나 삭제하지 마세요. 저희는 항상 보고를 진지하게 받아들이며, 증거가 없더라도 취약점이 의심되는 모든 경우를 조사합니다.

  • 문제가 해결될 때까지 다른 사람들과 문제를 공유하지 마세요.

  • 물리적 보안에 대한 공격, 사회공학, 취약점 스캐너 같은 해킹 도구를 사용하지 마세요.

  • 문제를 재현할 수 있는 충분한 정보를 제공해 주세요. 그래야 가능한 한 빨리 해결할 수 있습니다. 보통은 영향을 받는 시스템의 IP 주소나 URL과 취약점에 대한 설명이면 충분하지만, 더 복잡한 취약점은 더 많은 정보가 필요할 수 있습니다.

저희의 약속:

  • 보고서에 대한 저희의 평가와 예상 해결일을 담아 영업일 3일 이내에 보고에 응답하겠습니다.

  • 보고서는 기밀로 처리하며, 귀하의 허락 없이 개인 정보를 제3자와 공유하지 않겠습니다. 다만 기소가 이루어지는 경우나 정보가 요구되는 경우의 경찰과 사법 당국은 예외입니다.

  • 문제 해결의 진행 상황을 계속 알려 드리겠습니다.

  • 보고된 문제에 관한 소통에서, 원하신다면 문제를 발견한 당사자로서 귀하의 이름을 밝히겠습니다.

  • 안타깝게도 귀하에 대해 법적 조치가 취해지지 않을 것이라고 미리 보장할 수는 없습니다. 각 상황을 개별적으로 검토할 수 있기를 바랍니다. 약점이나 데이터가 악용되고 있거나 귀하가 약점에 대한 지식을 다른 사람들과 공유했다고 의심되는 경우, 저희는 귀하를 신고할 도덕적 의무가 있다고 생각합니다. 저희 온라인 환경에서의 우연한 발견이 기소로 이어지지 않을 것임은 안심하셔도 됩니다.

  • 도움에 대한 감사로, 저희가 알지 못하는 보안 문제를 보고해 주실 때마다 보상을 드립니다. 보상 금액은 침해의 심각도와 보고서의 품질에 따라 결정합니다.

저희는 모든 문제를 가능한 한 빨리 해결하고, 관련된 모든 당사자에게 계속 알리기 위해 노력하며, 문제가 해결된 후 그에 관한 게시에 함께 참여하고 싶습니다.

예시: Bits of Freedom

디지털 인프라에 대한 저희의 의존도는 계속 높아지고 있습니다. 이는 사회 전체에 해당하지만 저희 자신에게도 해당합니다. 따라서 정부와 조직(저희 조직 포함)이 디지털 인프라를 안전하게 지키는 데 강하게 헌신해야 한다는 것이 저희의 생각입니다. 최선의 의도와 최대한의 주의를 기울이더라도 저희 시스템에 취약점이 존재할 수 있음을 저희는 알고 있습니다. 이러한 약점 중 하나를 발견하셨다면 문제를 해결할 수 있도록 꼭 연락해 주세요.

저희가 귀하에게 기대하는 것

  • 저희 시스템 중 하나를 조사할 때는 공격의 비례성을 염두에 두세요. 저희 웹사이트에 인터넷 역사상 가장 큰 DDoS 공격을 가하면 사이트에 접속할 수 없게 될 수 있다는 것을 입증할 필요는 없습니다. 저희도 알고 있습니다. 또한 불도저를 몰고 저희 사무실에 돌진하면 아마 노트북 한 대쯤은 낚아챌 수 있다는 것도 이해합니다.

  • 이 비례성의 원칙은 취약점 자체를 입증할 때에도 적용됩니다. 발견한 내용이 타당한지 확인하는 데 엄격히 필요한 것보다 많은 데이터를 조사하거나 수정해서는 안 됩니다. 예를 들어 저희 홈페이지를 수정할 수 있다면 페이지 전체를 장악하는 대신 논란의 소지가 없는 단어 하나만 추가하세요. 데이터베이스에 접근할 수 있다면 그 안에 있는 테이블 목록, 또는 그중 한 테이블의 첫 번째 레코드를 보여 주는 것으로 충분합니다.

  • 저희 시스템의 취약점은 security@bof.nl로 이메일을 보내 가능한 한 빨리 보고해야 합니다. 가능하면 OpenPGP로 메시지를 암호화해 주세요. 저희가 문제를 재현하고 조사할 수 있도록 충분한 정보를 제공해 주세요.

  • security@bof.nl의 OpenPGP 공개 키

  • 저희가 문제를 해결하지 않았고 귀하가 문제를 보고한 이후 아직 합리적인 기간 안에 있는 동안에는 취약점에 대한 지식을 다른 당사자와 공유하지 않아야 합니다.

  • 저희가 취약점을 해결하는 대로 조사 중에 얻은 모든 기밀 정보를 삭제해야 합니다.

귀하가 저희에게 기대할 수 있는 것

  • 보고 후 3일 이내에 상세하게 응답하겠습니다. 문제를 해결하는 데 필요한 예상 시간도 포함하겠습니다. 물론 진행 상황을 정기적으로 알려 드리겠습니다.

  • 취약점을 가능한 한 빨리 해결하겠습니다. 여기서도 비례성이 중요합니다. 취약점을 고치는 데 필요한 시간은 문제의 심각도와 복잡도를 비롯한 여러 요인에 따라 달라집니다.

  • 여기에 제시된 지침을 따르신다면 보고와 관련하여 귀하에 대해 법적 조치를 취하지 않겠습니다.

  • 원하신다면 귀하가 한 일에 대해 공로를 인정하는 것이 저희에게 중요합니다. 귀하가 동의하는 경우에만 취약점에 관한 게시물에 귀하의 이름을 언급하겠습니다.

  • 저희 시스템을 더 잘 보호하도록 도와 주신 것에 대한 감사로, 당시 저희가 알지 못했던 취약점의 모든 보고에 보상을 드리고자 합니다. 보상은 취약점의 심각도와 보고서의 품질에 따라 달라집니다.

  • 저희가 사용하는 제3자 소프트웨어에서 취약점을 발견했고 그 취약점이 버그 바운티 프로그램의 대상이라면, 저희는 그 바운티를 청구하려 하지 않을 것입니다. 귀하가 청구하셔야 합니다.