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. Включити до папки репозиторію приклади політик скоординованого розкриття вразливостей.

Ми вітаємо pull request'и, GitHub issues або листи на адресу security@joelparkerhenderson.com.

Що таке скоординоване розкриття вразливостей?

Скоординоване розкриття вразливостей описує три кроки, коли хтось виявляє проблему безпеки (наприклад, помилку в програмному забезпеченні) і хоче повідомити про неї виробнику (наприклад, компанії, яка створює програмне забезпечення).

Кроки:

  1. Той, хто виявив, повідомляє виробнику про проблему приватно й добросовісно.

  2. Виробник добросовісно намагається захистити користувачів і розв'язати проблему.

  3. Після певного часу проблему безпеки оприлюднюють.

Крок 1: Повідомте про проблему

Крок 1 належить тому, хто виявив: повідомте про проблему приватно й добросовісно.

  • Добре: той, хто виявив, надсилає відповідну інформацію виробнику, наприклад, електронною поштою на адресу електронної пошти виробника з питань безпеки (зазвичай «security@example.com») або через форму на вебсторінці вебсайту виробника (зазвичай «https://www.example.com/security»).

  • Погано: публікація звіту в публічному блозі, сповіщення медіа, погрози або спроби продати проблему безпеки хакерам тощо.

  • Порада: той, хто виявив, може вирішити залишитися анонімним; виробник також може вирішити залишитися анонімним.

Якщо хочете, продовжуйте стежити за проблемою.

  • Добре: відкриття каналів зв'язку, надання додаткової інформації або моніторинг ситуації.

  • Погано: забути про проблему.

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

Якщо хочете, розкрийте проблему іншим.

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

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

  • Порада: якщо обставини зміняться, наприклад, буде виявлено вищий ризик або активну експлуатацію в реальних умовах (in the wild), той, хто виявив, може розкрити проблему іншим раніше.

Крок 2: Забезпечте контакти

Крок 2 належить виробнику: переконайтеся, що контакти придатні до використання.

  • Добре: виробник публікує контактну адресу електронної пошти з питань безпеки (за умовністю «security@example.com») і, в ідеалі, безпечний ключ шифрування електронної пошти.

  • Добре: виробник публікує контактну вебсторінку з питань безпеки (за умовністю «https://www.example.com/security») і, в ідеалі, робить сторінку легкою для знаходження, наприклад, через нижній колонтитул вебсайту, мапу сайту та пошук.

  • Погано: виробник не надає адресу електронної пошти чи вебсторінку або не робить їх легкими для знаходження.

Забезпечте спроможність працівників.

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

  • Добре: виробник періодично перевіряє, що спроможність працівників працює.

  • Погано: виробник не навчає або не перевіряє.

Відповідайте тому, хто виявив, у встановлений термін.

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

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

Відповідайте тому, хто виявив, через уповноважений контакт із безпеки та/або уповноважений процес безпеки.

  • Добре: відповідь з адреси електронної пошти, призначеної для безпеки, наприклад «security@example.com».

  • Наприклад, погано: відповідь із адреси електронної пошти загального призначення, як-от «help@example.com», або від того, хто не є уповноваженим фахівцем із безпеки.

Повідомте тому, хто виявив, що проблему визнано звітом із безпеки.

  • Добре: формулювання, специфічні для безпеки, наприклад: «Наша команда безпеки отримала ваш звіт про відповідальне розкриття», або «Наш процес безпеки має такі наступні кроки», або «Ваша інформація тепер у нашому трекері безпеки під номером XYZ» тощо.

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

Крок 3: Діліться добросовісно

Крок 3 належить тому, хто виявив, і виробнику разом: працюйте добросовісно.

Зрозумійте, що скоординоване розкриття вразливостей описує добросовісний процес.

  • Мета № 1 — добросовісність у допомозі користувачам захиститися від ризиків безпеки.

  • Мета № 2 — добросовісність у розв'язанні проблеми безпеки.

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

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

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

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

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

  • Скоординоване розкриття вразливостей найкраще, коли всі залучені розуміють, що мета № 1 — допомогти користувачам захиститися від ризиків безпеки, а мета № 2 — розв'язати проблему безпеки.

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

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

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

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

Зрозумійте, що зазвичай той, хто виявив, робить послугу видавцеві.

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

  • Зазвичай інформація того, хто виявив, допомагає видавцеві.

Перевірте успіх

Після розв'язання проблеми виробник має перевірити успіх.

  • Чи всі люди й процеси успішно впоралися з розкриттям? Якщо так, добре. Якщо ні, розгляньте можливість проведення дослідження постфактум, наприклад, аналізу першопричин (RCA), звітів постфактум (post-mortem), діаграм Ісікави або причинно-наслідкового аналізу на основі теорії систем (CAST).

  • Чи класифіковано (triage) та відстежуються нерозв'язані проблеми?

  • Чи розуміють виробник і той, хто виявив, що робити на наступних кроках? Це особливо важливо зробити правильно на випадок можливих подальших скоординованих розкриттів вразливостей.

Настанови

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

Якщо ви шукаєте настанови, вас можуть зацікавити ці три сфери, усі описані нижче.

  • Добрий самарянин

  • Обов'язок рятувати

  • Обов'язок обачності

Добрий самарянин

Wikipedia: Good Samaritan law

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

Обов'язок рятувати

Wikipedia: Duty to rescue

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

Обов'язок обачності

Wikipedia: Duty of care

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

Особливі випадки

Наші команди безпеки бачили широкий спектр особливих випадків.

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

Доступ до інформації інших користувачів

Приклад: ви виявляєте, що URL містить ваш ідентифікатор користувача й виявляє помилку, і ви вважаєте, що можете відредагувати URL, щоб змінити свій ідентифікатор користувача на інший.

  • Чи прийнятно тому, хто виявив, це робити, наприклад, з єдиною метою з'ясувати, чи це впливає і на інших користувачів?

  • Чи важливіше швидко зрозуміти масштаб ризику для всіх користувачів, ніж захистити кількох користувачів, інформація яких уже може бути видимою для хакерів?

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

  • Чи прийнятно тому, хто виявив, намагатися зв'язатися з користувачами, щоб повідомити їм, що вони постраждали? Чи прийнятно пропонувати поради щодо пом'якшення?

Відмова в обслуговуванні

Приклад: ви виявляєте помилку, яка випадково призупиняє ваш обліковий запис, наприклад, запускає блокування пароля.

  • Чи вважається це атакою типу відмова в обслуговуванні?

Небажана електронна пошта

Приклад: ви намагаєтеся повідомити про проблему безпеки людям у компанії, яких вважаєте відповідними й яких знаходите, досліджуючи LinkedIn, Facebook тощо або використовуючи конвенції іменування, як-от «webmaster@example.com» або «security@example.com».

  • Чи це прийнятно?

  • Чи це вважається небажаною електронною поштою?

  • Чи це вважається несанкціонованою електронною поштою?

Виключені групи

Приклад: ви належите до виключеної групи, наприклад, ви неповнолітній, або у санкційному списку, або в країні, що в санкційному списку.

  • Чи прийнятно вам робити звіт?

  • Чи прийнятно повідомляти анонімно?

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

Третя сторона

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

  • Чи прийнятно вам повідомити всю знайдену інформацію обом сторонам?

  • Чи необхідно зробити два різні відповідальні розкриття, наприклад, один звіт одній компанії й інший звіт компанії-третій стороні, з метою обмежити інформацію, що надсилається кожній компанії?

  • Чи прийнятно тому, хто виявив, зв'язати компанії між собою?

Деструктивне програмне забезпечення

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

  • Чи це прийнятно?

  • Чи прийнятно тому, хто виявив, скеровувати користувачів до такого програмного забезпечення та/або до посібників чи навчальних матеріалів, що описують, як створити такий вид програмного забезпечення?

Скоординоване розкриття вразливостей і відповідальне розкриття

Скоординоване розкриття вразливостей — це бажаний термін.

  • Найважливіший аспект — координація між тим, хто виявив, і виробником.

Відповідальне розкриття (responsible disclosure) — це застарілий термін.

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

Відстеження