Coordinated vulnerability disclosure
← Політики

NCSC.nl

1. Вступ

Суспільство дедалі більше цифровізується. Нині майже всі процеси у певний момент передбачають використання комп'ютерів — від мобільних телефонів до спеціалізованого програмного забезпечення. Хоча цей розвиток створює багато нових можливостей, вразливості в ІТ-системах можуть мати великий вплив. Отже, знання про ці вразливості слід використовувати ефективно.

Низка організацій розпочала публікувати політики щодо повідомлення про вразливості на початку 2013 року. Після консультацій з цими сторонами Національний центр кібербезпеки (National Cyber Security Centre, NCSC) підсумував розвиток подій у формі «Настанов щодо досягнення практики Responsible Disclosure» («Leidraad om te komen tot een praktijk van Responsible Disclosure»; «Настанови»). Компанії через цю політику вказують, що відкриті до отримання зовнішніх звітів про вразливості, описують свої передумови та дають обіцянки. Цей процес створив ясність і дещо безпечне середовище для тих, хто повідомляє, щоб досліджувати й повідомляти про вразливості, безпосередньо не скоюючи кримінального правопорушення. На зустрічі ЄС високого рівня з кібербезпеки 2016 року 29 організацій підтвердили важливість політики поводження з вразливостями, підписавши Маніфест скоординованого розкриття вразливостей (Coordinated Vulnerability Disclosure Manifesto)1, ініційований CIO Platform Netherlands і Rabobank у співпраці з NCSC.

Скоординоване розкриття вразливостей (Coordinated Vulnerability Disclosure, CVD) виявилося дуже важливим для державних і приватних сторін. Вони значною мірою залежать від безперебійного функціонування інформаційних систем у повсякденній практиці. Повідомлення про вразливості в їхніх системах допомогли покращити безпеку та безперервність систем в останні роки, з одного боку, усуваючи вразливості, а з іншого — сприяючи загальній обізнаності нідерландських компаній з питань ІТ-безпеки.

В останні роки стало зрозуміло, що ті, хто повідомляє, готові працювати в межах умов політики CVD, розробленої організаціями. Повідомлення надходять безпосередньо або опосередковано до організацій від тих, хто повідомляє. Практика відповідального розкриття показала, що добросовісні ті, хто повідомляє, та вразливі організації змогли співпрацювати й таким чином зробити наступний крок у підвищенні безпеки мереж та інформаційних систем.

Для цієї редакції ми знову поговорили з широкою та різноманітною групою тих, хто повідомляє, приватних і державних сторін, а також із Прокуратурою та Національною поліцією. Ці розмови підтвердили поточну практику та призвели до доповнень і покращень. Найважливішим новим моментом уваги є комунікація між тим, хто повідомляє про вразливість, та організацією, а також з іншими сторонами після усунення вразливості.

У наступних розділах розглядаються визначення CVD, будівельні блоки для політики CVD та процес комунікації.

Примітка: у попередніх Настановах використовувався термін «responsible disclosure», який був поширеним терміном для цієї практики на той час. Відтоді стало зрозуміло, що цей термін робить надто великий наголос на відповідальності того, хто повідомляє, тоді як основний принцип полягає в тому, що той, хто повідомляє, та потенційно вразлива організація мають бути рівноправними партнерами в діалозі. Це ставлення краще передано в поточному поширеному терміні «Coordinated Vulnerability Disclosure» (CVD), який також є назвою, що використовується в стандартах ISO 29147 та 30111 щодо цього процесу.

2. Скоординована вразливість

Протягом останніх 30 років використовувалися різні методи для підвищення обізнаності про вразливості в ІТ-системах. Приклади включають:

  • «Full Disclosure», повне оприлюднення вразливості;

  • «Non-disclosure», продаж або власне використання вразливості;

  • «Coordinated Vulnerability Disclosure» (CVD), скоординоване розкриття вразливості.

Остання практика прямо надається перевага.

ІТ-спільнота продемонструвала велику готовність ділитися знаннями та досвідом. Пошук співпраці з цією спільнотою може, отже, допомогти покращити загальну безпеку систем.

Мета скоординованого розкриття вразливостей

Мета CVD — сприяти безпеці ІТ-систем, ділячись знаннями про вразливості. У CVD знання передаються одній або кільком потенційно вразливим організаціям, щоб досягти спільного розв'язання знайденої вразливості у співпраці з тим, хто повідомляє. Важливо, щоб уражені організації мали достатньо часу на усунення будь-яких вразливостей або захист систем, щоб якомога більше обмежити чи запобігти втратам або шкоді. Наріжним каменем процесу є розкриття знань про вразливості після усунення.

У CVD важливо, щоб усі сторони дотримувалися домовленостей щодо того, як повідомляти про вразливість і як з нею поводитися. Допомагає, якщо організація публікує передумови заздалегідь, наприклад, які системи входять до сфери та який вид досліджень може проводитися. Важливим принципом для цих передумов є те, що організація, як правило, не повідомлятиме про того, хто повідомляє, і не вживатиме інших юридичних заходів, якщо дослідження та повідомлення здійснюються в межах встановлених умов. Ці Настанови надають організаціям керівництво зі складання власної політики, що втілює принципи CVD.

Як випливає з назви, головне в CVD — це те, що організація й той, хто повідомляє, координуються між собою. У цьому відношенні має бути якомога менше ланок між особою, яка повідомляє про вразливість, та особою в організації, відповідальною за розв'язання проблеми.

Може бути важливо інформувати кілька сторін одночасно, якщо вразливість впливає на багато систем. У такому разі NCSC або інші сторони у спільноті безпеки можуть підтримувати процес CVD із координаційної ролі.

3. Сфери відповідальності

Мета впровадження політики CVD полягає в тому, щоб ті, хто повідомляє, й організація працювали разом для зменшення вразливостей в ІТ-системах. Впровадження цієї політики слід розглядати як доповнення до наявних заходів з інформаційної безпеки. Різні учасники мають кожен свою роль і відповідальність. Вони пояснюються докладніше нижче.

Організація, яка володіє/керує системою

Організація, яка володіє/керує або постачає систему, насамперед відповідальна за безпеку цієї системи. Іншими словами, організація також відповідальна за подальші дії за звітом про вразливість.

Організація може вибрати складання власної політики CVD за цими Настановами та повідомлення цієї політики потенційним тим, хто повідомляє. Публікуючи політику CVD, організації демонструють готовність отримувати інформацію про вразливості.

Сторона, що встановлює політику CVD, може зобов'язатися дотримуватися принципу, що вона не подаватиме заяву до поліції, якщо правила, що застосовуються до політики, дотримуються.

Після того як той, хто повідомляє, повідомив про вразливість, відповідальність лежить на організації. Важливо усвідомлювати, що той, хто повідомляє, часто є кимось поза організацією. Ця сторона не має прямого огляду внутрішніх процесів, які можуть бути запущені після повідомлення про вразливість. Внаслідок цього ті, хто повідомляє, цінуватимуть інформування про розвиток розв'язання вразливості. Ця постійна комунікація також важлива для створення правильних очікувань щодо подальших дій і своєчасності розв'язання.

Сторона, що повідомляє про вразливість

Так чи інакше той, хто повідомляє, зміг виявити вразливість і хоче сприяти безпеці ІТ-систем, домагаючись усунення цієї вразливості й, можливо, її оприлюднення на пізнішому етапі. Той, хто повідомляє, міг виявити щось шляхом пасивного спостереження або шляхом активного тестування ІТ-системи. Звісно, ця сторона відповідальна за свої дії та спосіб, яким вона виявила вразливість. Це власна відповідальність того, хто повідомляє, — знати умови, встановлені організацією у своїй політиці CVD. Більшість урядів і компаній опублікували свої політики CVD на своїх вебсайтах.

Пошук вразливостей, проте, може передбачати порушення закону. У контексті CVD організація та той, хто повідомляє, можуть домовитися, що вони не подаватимуть заяви про будь-які кримінальні діяння. У цьому відношенні політика CVD, опублікована організацією, є керівним принципом. Сторони також можуть домовитися, що цивільних позовів не подаватимуть.

Якщо є підозра, що закон було порушено тим, хто повідомляє, політика CVD може насамперед допомогти запобігти повідомленню про того, хто повідомляє, владі. Ця процедура цілком залежить від передумов політики, виконання яких організація вимагає від того, хто повідомляє, та від того, чи було досягнуто цього виконання, потенційно з відповідною обіцянкою не подавати кримінальну заяву, поки сторона діє в межах умов політики. Якщо подано заяву до поліції, наявність політики CVD та її дотримання є релевантною обставиною в Нідерландах, яку прокурор враховуватиме при ухваленні рішення про те, чи розпочинати кримінальне розслідування та/або переслідувати. Як правило, поліція та Прокуратура (OM) не розпочинатимуть кримінального розслідування, якщо той, хто повідомляє, чітко дотримувався правил політики CVD відповідної організації. Однак Прокуратура та поліція можуть далі розслідувати справу, якщо є ознаки того, що той, хто повідомляє, свідомо чи несвідомо зайшов надто далеко у своїх діях та/або не дотримувався політики CVD. На основі цього розслідування Прокуратура може вирішити, чи переслідувати.

Прокуратура опублікувала політичний лист, у якому розглядає докладніше аспекти, важливі для ухвалення рішення про розслідування та/або переслідування. Наприклад, чи служили дії того, хто повідомляє, важливому суспільному інтересу, чи діяла сторона непропорційно і чи могла сторона, можливо, діяти іншим, менш радикальним способом. Відповідний політичний лист докладніше розкриває ці аспекти.2 Відповідна судова практика з 20133 показує, що ці аспекти також враховуються в суді, якщо в організації немає політики CVD.

4. Будівельні блоки процесу скоординованого розкриття вразливостей

Нижче наведено будівельні блоки для формування процесу CVD для організації, того, хто повідомляє, та NCSC.

Організація

Сприяння CVD починається з організації, яка володіє ІТ-системами або постачає ІТ-продукт/систему. Адже ця організація насамперед відповідальна за інформаційну безпеку цих ІТ-систем. Щоб ефективно співпрацювати з різними сторонами для розв'язання вразливостей, організація може вирішити скласти й опублікувати політику CVD. Складання власної політики CVD дає організації змогу продемонструвати, як вона поводиться зі звітами про вразливості. Таким чином організація також може сформувати спосіб, у який вона хоче отримувати сповіщення. Такий процес може бути організований так:

  • Організація встановлює й публікує політику CVD.

  • У цій політиці організація надає чіткі правила для досліджень, які ті, хто повідомляє, можуть проводити, наприклад, які техніки дозволені та які системи входять до сфери або поза нею.

  • Організація полегшує тому, хто повідомляє, подання звіту. Одним із варіантів є використання стандартизованого методу повідомлення; наприклад, спеціальної адреси електронної пошти або онлайн-форми. Крім того, організація може вирішити, чи приймати анонімні звіти.

  • Організація резервує внутрішню спроможність і налагоджує процес, щоб адекватно реагувати на звіти. Рекомендується налагодити процес, за допомогою якого будь-які знайдені вразливості можуть бути адекватно усунені. У цьому відношенні походження звіту не має значення. Вразливість також могла бути виявлена внутрішнім працівником або, наприклад, під час тесту.

  • Практичний досвід показує, що після першої публікації політики CVD зросте інтерес до повідомлення про вразливості організації. Організація має враховувати це при плануванні (додаткової) спроможності.

  • Коли організація отримує звіт про вразливість, вона забезпечує, щоб звіт якнайшвидше потрапив до відділу, який найкраще підходить для його оцінки та опрацювання.

  • Організація надсилає підтвердження отримання звіту тому, хто повідомляє, бажано цифрово підписане, щоб підкреслити пріоритет.

  • Згодом організація вступить у консультацію з тим, хто повідомляє, щоб визначити період, протягом якого відбудеться будь-яка публікація. Цей період значною мірою залежатиме від характеру вразливості та типу системи.

  • Як орієнтир, для вразливостей програмного забезпечення часто використовується період приблизно в 60 днів. Усунення вразливостей в апаратному забезпеченні досягти важче; можна використати орієнтир у 6 місяців.

  • Може бути бажано подовжити або скоротити цей період за взаємною згодою залежно від того, скільки або як мало ІТ-систем залежать від системи, для якої повідомлено про вразливість, або чи вразливість легше чи важче усунути.

  • Вразливість може виявитися важкою або неможливою для усунення, або можуть бути значні витрати на її усунення. У таких випадках організація може погодитися вважати вразливість прийнятим ризиком і не усувати її, можливо, за консультацією з тим, хто повідомляє.

  • Організація інформуватиме того, хто повідомляє, про розвиток процесу.

  • Крім того, організація може запропонувати, щоб той, хто повідомляє, отримав публічне визнання за публікацію вразливості. Також можна обрати спільне розкриття назовні.

  • Бажано винагороджувати того, хто повідомляє, за повідомлення про вразливості в системах, якщо сторона дотримувалася правил політики CVD. Розмір винагороди може залежати від якості звіту. Винагородження того, хто повідомляє, може створити кращі стосунки між цією стороною та організацією, а також підвищити готовність людей подавати нові звіти відповідно до політики CVD.

  • За консультацією з тим, хто повідомляє, організація може погодитися проінформувати ширшу ІТ-спільноту про вразливість, якщо вірогідно, що вразливість присутня й в інших місцях.

  • У своїй політиці CVD організація може зобов'язатися дотримуватися принципу, що вона не подаватиме заяву до поліції, якщо той, хто повідомляє, дотримувався правил, викладених у політиці.

Той, хто повідомляє

Той, хто повідомляє, є ключем до успішного процесу CVD. Так чи інакше ця сторона змогла виявити вразливість і хоче сприяти безпеці ІТ-систем, домагаючись усунення цієї вразливості організацією та її оприлюднення. Роблячи це, ті, хто повідомляє, визнають, що вони можуть зробити важливий внесок у суспільство, розкриваючи вразливості скоординовано. Для досягнення успішного процесу CVD для того, хто повідомляє, важливі такі будівельні блоки:

  • Той, хто повідомляє, відповідальний за свої дії та має дотримуватися принципів співмірності й субсидіарності при дослідженні та повідомленні про вразливості. Іншими словами, той, хто повідомляє, не повинен робити більше, ніж необхідно для демонстрації вразливості, і завжди має повідомляти про вразливість насамперед власнику системи/інформації.

  • Той, хто повідомляє, має повідомити про проблему якнайшвидше, щоб запобігти виявленню вразливості зловмисними сторонами та використанню нею.

  • Той, хто повідомляє, має подати звіт організації конфіденційним чином, щоб запобігти доступу інших до цієї інформації.

  • Той, хто повідомляє, не може ставити подання звіту чи подальше надання інформації в залежність від винагороди. Ініціатива надання винагороди у разі звіту лежить на організації-одержувачі, яка може викласти передумови у своїй опублікованій політиці.

  • Той, хто повідомляє, та організація укладають чіткі домовленості щодо розкриття вразливості. Якщо залучено більше однієї організації, основний принцип полягає в тому, що вразливості можна публікувати, лише якщо всі організації на це погоджуються. Укладання цих домовленостей на ранньому етапі рекомендується.

  • Той, хто повідомляє, та залучена організація можуть укласти домовленості щодо інформування ширшої ІТ-спільноти. Наприклад, ця ситуація може стосуватися вразливості (відомої чи ні), про яку відомо, що вона присутня більш ніж в одному місці. Національний центр кібербезпеки (NCSC) може бути залучений до цього процесу для підтримки цільових груп центрального уряду й критичної інфраструктури або для інформування кількох сторін у разі вразливості, що впливає на багато систем.

NCSC

Процес CVD — це насамперед справа організацій і тих, хто повідомляє. Проте NCSC заохочуватиме використання процесу CVD. За консультацією з тим, хто повідомляє, та організацією, NCSC також може бути залучений до обміну інформацією про вразливість зі своєю цільовою аудиторією, щоб обмежити подальші ризики безпеки, що виникають від вразливості.

Якщо повідомлення про вразливість не відбувається так, як очікує той, хто повідомляє, або якщо він волів би не повідомляти про вразливість безпосередньо організації, він може звернутися до NCSC.4 У цьому випадку NCSC може діяти як посередник за потреби.

Власник ІТ-системи завжди відповідальний за безпеку системи. NCSC не може примусити власника системи усунути вразливість і не може гарантувати, що власник не вживатиме юридичних заходів проти того, хто повідомляє. Внаслідок цього той, хто повідомляє, має враховувати вищезгадані будівельні блоки для організацій і тих, хто повідомляє, при пошуку та повідомленні про вразливість. Той, хто повідомляє, може очікувати, що NCSC зробить усе можливе, щоб вразливість було усунено, і поводитиметься зі звітом конфіденційно. NCSC не передає жодних персональних даних, якщо тільки законом не зобов'язане це робити.

Якщо можливо, NCSC використовуватиме отриману інформацію про вразливості за консультацією з організаціями та тими, хто повідомляє, для подальшого обміну знаннями з ІТ-спільнотою. Наприклад, воно може зробити це, опублікувавши частину інформації, написавши чи оновивши інформаційний лист (fact sheet) або білу книгу (white paper), або проінформувавши конкретні організації.

  • Залежно від відповідної організації та характеру встановленої вразливості NCSC докладе зусиль, щоб довести вразливість до відома відповідної організації. Однак власник відповідної ІТ-системи залишається відповідальним за систему.

  • Де можливо й необхідно, NCSC надасть відповідній організації пораду щодо усунення вразливості.

  • NCSC поводитиметься зі звітами конфіденційно й не передаватиме персональні дані тих, хто повідомляє, чи організації-одержувача без згоди, якщо це не випливає із законного обов'язку.

  • Де можливо, NCSC інформуватиме того, хто повідомляє, про розвиток контакту з організацією та усунення вразливості.

  • У випадках, коли звіт подається до NCSC, NCSC намагатиметься звести того, хто повідомляє, чи потенційного того, хто повідомляє, й організацію в контакт між собою.

Якщо той, хто повідомляє, знайшов вразливість у програмному продукті або вразливість, що впливає на багато різних систем, наприклад, той, хто повідомляє, може попросити NCSC скоординувати усунення та розкриття вразливості.

Разом із тим, хто повідомляє, партнерами, розробниками та/або розробниками програмного забезпечення й іншими командами безпеки NCSC допоможе проаналізувати, усунути або забезпечити усунення, скоординувати й розкрити вразливість контрольованим чином. Увесь цей процес відбувається у тісній консультації з тим, хто повідомляє, хто знайшов вразливість.

Політика CVD намагається знайти баланс між важливістю розкриття вразливостей якнайшвидше, щоб можна було вжити заходів, та важливістю того, щоб і розробники, і постачальники мали достатньо часу на усунення вразливості. Для цього процесу NCSC використовує стандартний термін у 60 днів між звітом і публічним розкриттям. Однак можуть бути обставини, за яких може бути вирішено подовжити або скоротити цей період.

NCSC передаватиме інформацію про вразливість третім сторонам лише після консультації з тим, хто повідомляє. У цьому контексті важливо, щоб NCSC співпрацювало і, отже, ділилося інформацією про вразливість із зацікавленими сторонами, щоб розкрити вразливість скоординовано. Роблячи це, NCSC забезпечить, щоб потрібні сторони могли працювати над усуненням вразливості, допоможе обмежити будь-які втрати чи шкоду та допоможе привернути увагу до знайденої вразливості.

5. Комунікація та процес розкриття

П'ять років практики показали, що чітка комунікація є наріжним каменем успішного процесу CVD. Є моменти, на які слід звернути увагу до, під час і після процесу CVD.

Комунікація щодо процесу розкриття

Публікація політики CVD — перший крок у комунікації про процес. Публікуючи політику публічно, тих, хто повідомляє, запрошують повідомляти організацію про будь-які знайдені вразливості.

З одного боку, організація може встановити умови для досліджень, що проводяться для виявлення вразливостей, та способу, яким шукається контакт. З іншого боку, організація може зобов'язатися дотримуватися принципу, що вона не подаватиме заяву до поліції, якщо правила політики дотримуються. Цей підхід захищає позицію того, хто повідомляє.

Політику CVD можна змінити або оновити пізніше. Важливо бути чітким щодо змін у цьому відношенні. Ті, хто повідомляє, зацікавлені в тому, щоб знати, що було змінено і коли. Наприклад, зміни можна прояснити вказавши дату публікації на початку політики CVD, описавши підсумок змін під політикою CVD або ведучи архів зі старими версіями політики CVD.

Політика CVD може надавати настанови щодо того, як спілкуватися під час процесу, наприклад, вказуючи на регулярні оновлення електронною поштою чи вебпорталом. Крім того, політика CVD може описувати, як того, хто повідомляє, можна визнати, згадавши його в оновленні, прийнявши до зали слави (hall of fame) або будь-якою іншою формою винагороди.

Комунікація під час процесу розкриття

Той, хто повідомляє, розпочинає процес CVD, надіславши повідомлення організації. У цьому повідомленні той, хто повідомляє, дає чіткий опис виявленої вразливості. Важливими елементами є IP-адреса або URL ураженої системи та кроки, необхідні для відтворення вразливості.

Для організації важливо чітко спілкуватися з тим, хто повідомляє, щоб очікування щодо процесу були зрозумілими.

Вона може зробити це вже, надіславши підтвердження отримання (автоматичне чи інше), що містить вказівку на термін, протягом якого буде надіслано першу або наступну змістовну відповідь.

Також можна залишити цей період відкритим і дати попередню вказівку на термін після оцінки змісту звіту. Рекомендується бути чітким якомога швидше щодо періоду, протягом якого може бути досягнуто розв'язання. Таким чином, той, хто повідомляє, знає, коли можна очікувати результату.

У деяких випадках може бути, що дата публікації вже зрозуміла тому, хто повідомляє; наприклад, через презентацію на конференції або тому що той, хто повідомляє, встановив власний термін. У цьому випадку все ж важливо, щоб той, хто повідомляє, чітко повідомив цей графік, вказав його якомога раніше та був чітким щодо можливості/неможливості перенесення цієї дати.

Той, хто повідомляє, часто є кимось поза організацією, хто не має уявлення про внутрішні процеси, які можуть бути запущені звітом. Організації можуть інформувати того, хто повідомляє, про розвиток процесу через регулярні оновлення. Такий підхід дає зрозуміти тому, хто повідомляє, що над розв'язанням працюють. За потреби організація може запросити роз'яснення або протестувати розв'язання під час процесу.

Якщо організація не може дотриматися початкового терміну розв'язання, це можна обговорити з тим, хто повідомляє, щоб його перенести. Регулярна комунікація може зробити цю ситуацію зрозумілою тому, хто повідомляє, на ранішому етапі.

Основний намір CVD — пом'якшити вразливість, але «повне розкриття» (full disclosure) вразливості завжди є варіантом для того, хто повідомляє, якщо він вважає, що процес триватиме надто довго. Цей захід — це прислів'я «велика палиця» (big stick), доступна тому, хто повідомляє. Природно, цієї ситуації слід якомога більше уникати.

Комунікація після процесу розкриття

Існує багато можливих причин, чому той, хто повідомляє, може шукати вразливості і потім повідомляти про них організаціям через процес CVD. Для великої кількості тих, хто повідомляє, важливим стимулом є (публічне) визнання.

Ті, хто повідомляє, отримують публічне визнання через подяку в оновленні або запис до зали слави (hall of fame). Однак потреба в публічному визнанні не стосується всіх тих, хто повідомляє; деякі насправді не хочуть бути відомими публіці. У разі комунікації з боку організації тому рекомендується отримати згоду того, хто повідомляє, на згадування його імені.

Крім того, ті, хто повідомляє, також можуть вирішити спілкуватися щодо звіту після завершення процесу CVD. Наприклад, той, хто повідомляє, може описати процес виявлення або попередити інших про вразливість. Той, хто повідомляє, може вирішити надіслати публікацію організації для інформаційних цілей. Оскільки процес CVD, як правило, завершено після усунення вразливості, той, хто повідомляє, надалі вільний спілкуватися про неї, якщо в політиці чи під час процесу не укладено додаткових домовленостей.

Перелік

Комунікація щодо процесу розкриття

  • Публікація політики CVD на вебсайті

  • Чіткість щодо обмежень (різні підходи див. у розділі 6)

  • Обмеження методів розслідування

  • Настанови щодо комунікації

  • Настанови щодо можливих винагород: зала слави (Hall of fame), фінансова винагорода, футболка тощо

  • Чіткість щодо будь-яких оновлень політики CVD, включно з датою змін

Комунікація під час процесу розкриття

  • Той, хто повідомляє, зв'язується з організацією щодо виявленої вразливості.

  • Організація керує очікуваннями, такими як час відповіді на першу технічну відповідь

  • Організація та той, хто повідомляє, надають одне одному чіткість щодо очікуваного періоду розв'язання

  • Організація часто надає (процесне) оновлення

  • За потреби той, хто повідомляє, та організація обговорюють звернення до інших відповідних організацій

Комунікація після процесу розкриття

  • Обговорити (публічне) визнання та винагороду того, хто повідомляє

  • Домовитися, як інформація про вразливість буде опублікована, наприклад, етап дослідження або інформування інших організацій

6. Приклади політики скоординованого розкриття вразливостей

Існує багато різних форм текстів політик щодо скоординованого розкриття вразливостей. Оскільки опублікована політика CVD слугує дороговказом для потенційних тих, хто повідомляє, переконайтеся, що форма цієї політики узгоджується з політикою та стратегією організації.

Такі елементи важливі в політиці CVD:

  • метод зв'язку для безпечної комунікації;

  • передумови для тих, хто повідомляє;

  • чіткі очікування щодо опрацювання звіту;

  • метод винагородження за звіт;

  • номер версії та дата останньої редакції.

Нижче наведено три приклади: багато організацій у Нідерландах використали базовий приклад ResponsibleDisclosure.nl. Інші організації включають додаткові передумови, див. політику Fox IT. Ще інші організації застосовують вільніший формат, щоб відповідати своїй цільовій аудиторії, див. політику Bits of Freedom.

Приклад: ResponsibleDisclosure.nl

Цей текст написала Floor Terra, і його опубліковано за ліцензією Creative Commons Attribution 3.0 Unported.

В Acme Corporation ми вважаємо безпеку наших систем першочерговим пріоритетом. Але скільки б зусиль ми не докладали до безпеки систем, вразливості все одно можуть існувати.

Якщо ви виявите вразливість, ми хочемо знати про неї, щоб вжити заходів для її усунення якнайшвидше.

Ми хочемо попросити вас допомогти нам краще захищати наших клієнтів і наші системи.

Будь ласка, зробіть таке:

  • Надішліть свої знахідки електронною поштою на cert@example.com. Зашифруйте свої знахідки нашим PGP-ключем, щоб ця критична інформація не потрапила в чужі руки,

  • Не користуйтеся вразливістю чи проблемою, яку ви виявили, наприклад, завантажуючи більше даних, ніж потрібно для демонстрації вразливості, або видаляючи чи змінюючи чужі дані,

  • Не розкривайте проблему іншим, доки її не буде розв'язано,

  • Не використовуйте атаки на фізичну безпеку, соціальну інженерію, розподілену відмову в обслуговуванні, спам чи застосунки третіх сторін, і

  • Надайте достатньо інформації для відтворення проблеми, щоб ми могли розв'язати її якнайшвидше. Зазвичай достатньо IP-адреси або URL ураженої системи та опису вразливості, але складні вразливості можуть потребувати додаткових пояснень.

Що ми обіцяємо:

  • Ми відповімо на ваш звіт протягом 3 робочих днів із нашою оцінкою звіту й очікуваною датою розв'язання,

  • Якщо ви дотримувалися наведених вище інструкцій, ми не вживатимемо жодних юридичних заходів проти вас щодо звіту,

  • Ми обробляватимемо ваш звіт зі строгою конфіденційністю й не передаватимемо ваші персональні дані третім сторонам без вашого дозволу,

  • Ми інформуватимемо вас про прогрес у розв'язанні проблеми,

  • У публічній інформації про повідомлену проблему ми вкажемо ваше ім'я як того, хто виявив проблему (якщо ви не побажаєте іншого), і

  • На знак вдячності за вашу допомогу ми пропонуємо винагороду за кожен звіт про проблему безпеки, яка ще не була нам відома. Розмір винагороди визначатиметься на основі серйозності витоку та якості звіту. Мінімальною винагородою буде подарунковий сертифікат на 50 €.

Ми прагнемо розв'язувати всі проблеми якнайшвидше й хочемо відігравати активну роль у фінальній публікації про проблему після її розв'язання.

Приклад: Fox-IT

У Fox-IT ми вважаємо безпеку наших систем, нашої мережі та наших продуктів надзвичайно важливою. Попри велику обережність, яку ми виявляємо щодо безпеки, слабкі місця все ще можуть залишатися. Якщо ви знайшли таку слабкість, ми хотіли б дізнатися про це якнайшвидше, щоб ми могли вжити відповідних заходів якомога швидше.

Слабкі місця можна виявити двома способами: ви можете випадково натрапити на щось під час звичайного використання цифрового середовища, або ви можете цілеспрямовано робити все можливе, щоб їх знайти.

Наша політика відповідального розкриття не є запрошенням до активного сканування нашої бізнес-мережі для виявлення слабких місць. Ми самі моніторимо нашу бізнес-мережу. Це означає, що існує висока ймовірність, що сканування буде виявлено, і що розслідування проведе наш Центр операцій безпеки (Security Operation Center, SOC), що може призвести до непотрібних витрат. Однак вас запрошують активно шукати вразливості в наших продуктах в офлайн-середовищі, не призначеному для промислової експлуатації, і повідомляти нам про свої знахідки. Наша відповідальність перед клієнтами означає, що ми не маємо наміру заохочувати спроби злому їхньої інфраструктури; проте ми хотіли б почути від вас якнайшвидше, якщо вразливості буде знайдено, щоб ми могли належним чином їх усунути.

Ми хотіли б співпрацювати з вами, щоб краще захищати наших клієнтів і наші системи.

Ми просимо вас:

  • Надсилати свої знахідки електронною поштою якнайшвидше на security-alert@fox-it.com.

  • Не зловживати вразливістю; наприклад, завантажуючи, редагуючи чи видаляючи дані. Ми завжди серйозно сприйматимемо ваш звіт і досліджуватимемо будь-які підозри щодо вразливості, навіть без доказів.

  • Не ділитися проблемою з іншими, доки її не буде розв'язано.

  • Не використовувати атаки на фізичну безпеку, соціальну інженерію чи хакерські інструменти, такі як сканери вразливостей.

  • Надавати достатньо інформації для відтворення проблеми, щоб ми могли розв'язати її якнайшвидше. Зазвичай достатньо IP-адреси або URL ураженої системи та опису вразливості, хоча для складніших вразливостей може знадобитися більше інформації.

Що ми обіцяємо:

  • Ми відповімо на ваш звіт протягом трьох робочих днів із нашою оцінкою звіту й очікуваною датою розв'язання.

  • Ми обробляватимемо ваш звіт конфіденційно й не ділитимемося вашою особистою інформацією з третіми сторонами без вашого дозволу. Винятком є поліція та судові органи у разі переслідування або якщо інформацію вимагають.

  • Ми інформуватимемо вас про прогрес у розв'язанні проблеми.

  • У комунікації про повідомлену проблему ми, якщо ви цього побажаєте, вкажемо ваше ім'я як сторони, що виявила проблему.

  • На жаль, неможливо заздалегідь гарантувати, що проти вас не буде вжито жодних юридичних заходів. Ми сподіваємося мати можливість розглядати кожну ситуацію індивідуально. Ми вважаємо себе морально зобов'язаними повідомити про вас, якщо ми підозрюємо, що слабкістю чи даними зловживають, або що ви поділилися знанням про слабкість з іншими. Ви можете бути впевнені, що випадкове виявлення в нашому онлайн-середовищі не призведе до переслідування.

  • Як подяку за вашу допомогу ми пропонуємо винагороду за кожен звіт про проблему безпеки, яка нам невідома. Ми визначаємо розмір винагороди на основі серйозності порушення та якості звіту.

Ми прагнемо розв'язувати всі проблеми якнайшвидше, інформувати всі залучені сторони й хотіли б брати участь у будь-якій публікації про проблему після її розв'язання.

Приклад: Bits of Freedom

Наша залежність від цифрової інфраструктури постійно зростає. Це стосується суспільства в цілому, але й нас самих. Тому, на нашу думку, уряди й організації (включно з нашою) мають рішуче зобов'язатися захищати нашу цифрову інфраструктуру. Ми усвідомлюємо, що попри наші найкращі наміри та найбільшу обережність у наших системах можуть існувати вразливості. Якщо ви випадково знайдете одну з цих слабкостей, ми будемо раді почути від вас, щоб ми могли розв'язати проблему.

Чого ми очікуємо від вас

  • Коли ви досліджуєте одну з наших систем, пам'ятайте про співмірність атаки. Немає потреби демонструвати, що коли ви піддаєте наш вебсайт найбільшій DDoS-атаці в історії інтернету, сайт може стати недоступним. Ми це знаємо. Ми також розуміємо, що якщо ви в'їдете бульдозером в наш офіс, ви, ймовірно, зможете вихопити один з наших ноутбуків.

  • Цей принцип співмірності також доречний при демонстрації самої вразливості. Ви не повинні переглядати чи змінювати більше даних, ніж це суворо необхідно для підтвердження обґрунтованості вашої знахідки. Наприклад, якщо ви можете змінити нашу домашню сторінку, просто додайте до неї одне безспірне слово замість того, щоб захоплювати всю сторінку. Якщо ви можете отримати доступ до бази даних, достатньо показати нам перелік таблиць, що в ній є, або, можливо, перший запис в одній з цих таблиць.

  • Про вразливість в одній з наших систем слід повідомити якнайшвидше, надіславши листа на security@bof.nl. Бажано зашифрувати ваше повідомлення за допомогою OpenPGP. Будь ласка, надайте достатньо інформації, щоб ми могли відтворити й дослідити проблему.

  • Публічний ключ OpenPGP для security@bof.nl

  • Ви не ділитиметеся своїми знаннями про вразливість з іншими сторонами, доки ми не усунули проблему й ми ще перебуваємо в розумному часовому проміжку з моменту, коли ви повідомили про проблему.

  • Ви видалите всю конфіденційну інформацію, отриману під час вашого дослідження, щойно ми усунемо вразливість.

Чого ви можете очікувати від нас

  • Ми відповімо на ваш звіт протягом трьох днів докладно. Ми додамо оцінку часу, який нам знадобиться для усунення проблеми. Звісно, ми регулярно інформуватимемо вас про наш прогрес.

  • Ми усунемо вразливість якнайшвидше. Тут також важлива співмірність: час, необхідний для виправлення вразливості, залежить від кількох факторів, серед яких серйозність і складність поточної проблеми.

  • Коли ви дотримуєтеся викладених тут настанов, ми не вживатимемо юридичних заходів проти вас щодо вашого звіту.

  • Для нас важливо віддати вам належне за те, що ви зробили, — якщо ви цього хочете. Ми згадаємо ваше ім'я в публікації про вразливість лише якщо ви на це погодитеся.

  • На знак подяки за допомогу в кращому захисті наших систем ми хочемо винагородити кожен звіт про вразливість, яка була нам невідома на той момент. Винагорода залежатиме від серйозності вразливості та якості звіту.

  • Якщо ви знайдете вразливість у стороннього програмного забезпечення, яке ми використовуємо, і ця вразливість охоплена програмою bug bounty, ми не намагатимемося претендувати на цю винагороду; це маєте зробити ви.