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").

  • Лошо: публикуване на доклада в публичен блог, уведомяване на медиите, заплахи или опити проблемът със сигурността да бъде продаден на хакери и т.н.

  • Съвет: откривателят може да избере да остане анонимен; производителят също може да избере да остане анонимен.

Ако желаете, продължавайте да следите проблема.

  • Добре: поддържане на връзка, предоставяне на допълнителна информация или наблюдение на ситуацията.

  • Лошо: забравяне на проблема.

  • Съвет: откривателят може да избере дали да помага, или не, дали да поддържа връзка, или не, и може да промени договорката, ако обстоятелствата се променят.

Ако желаете, разкрийте проблема и пред други хора.

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

  • Лошо: неразкриване на проблема пред други, освен ако смятате, че това би създало риск за вас или за други, по-голям от съпоставимия.

  • Съвет: ако обстоятелствата се променят, например бъде открит по-висок риск или активна експлоатация в реална среда, откривателят може да разкрие проблема пред други по-рано.

Стъпка 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).

  • Всички неразрешени въпроси подредени по приоритет и проследявани ли са?

  • Разбират ли производителят и откривателят какво да правят при всякакви следващи стъпки? Това е особено важно да се направи правилно, в случай че последват още координирани разкривания на уязвимости.

Насоки

Насоки за координираното разкриване на уязвимости могат да идват от много области, като експерти по етика, правни защитници, разумните очаквания на широката общественост и т.н.

Ако търсите насоки, може да ви заинтересуват тези три области, описани по-долу.

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

  • Задължение за спасяване

  • Задължение за полагане на грижа

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

Уикипедия: Закон за добрия самарянин

Законите за добрия самарянин предлагат правна защита на хора, които оказват разумна помощ на онези, които са или които те смятат, че са ранени, болни, в опасност или по друг начин неспособни да се справят сами. Защитата има за цел да намали колебанието на наблюдателите да помогнат от страх да не бъдат съдени или преследвани.

Задължение за спасяване

Уикипедия: Задължение за спасяване

Задължението за спасяване е понятие, описващо обстоятелство, при което една страна може да бъде подведена под отговорност за неспасяване на друга страна в опасност. Задължението за спасяване може да има морални и/или правни аспекти.

Задължение за полагане на грижа

Уикипедия: Задължение за полагане на грижа

Задължението за полагане на грижа е задължение да се спазва стандарт на разумна грижа при извършване на каквито и да било действия, които могат предвидимо да навредят на други. Задължението за полагане на грижа може да има морални и/или правни аспекти. Някои аспекти, които трябва да се имат предвид, са: предвидимостта на вредата или увреждането, възможният размер на потенциалната вреда или увреждане, значимостта или обществената стойност на дейността, с която се занимава ответникът, полезността на поведението за ответника, осъществимостта на алтернативно поведение, разходите и тежестите, свързани с алтернативното поведение, относителната полезност на алтернативното поведение и относителната безопасност на алтернативното поведение.

Специални случаи

Нашите екипи по сигурността са виждали широк кръг от специални случаи.

Описваме ги тук, за да помогнем на хората да разберат къде има широк спектър от мнения какво може да е допустимо и какво не. Препоръчваме всички участници да общуват добросъвестно по тези въпроси.

Достъп до информация на други потребители

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

  • Допустимо ли е откривателят да направи това, например с единствената цел да установи дали това засяга и други потребители?

  • По-важно ли е бързо да се разбере обхватът на риска за всички потребители, отколкото да се защитят няколко потребители, чиято информация може вече да е видима за хакерите?

  • Допустимо ли е откривателят да го направи с колкото потребители пожелае?

  • Допустимо ли е откривателят да се опита да се свърже с потребителите, за да ги уведоми, че са засегнати? Допустимо ли е да предложи мерки за смекчаване?

Отказ на услуга

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

  • Счита ли се това за атака за отказ на услуга?

Нежелана електронна поща

Пример: опитвате се да докладвате проблем със сигурността на хора в компанията, които смятате за подходящи и които откривате чрез проучване в LinkedIn, Facebook и др. или чрез конвенции за имена като „webmaster@example.com" или „security@example.com".

  • Допустимо ли е това?

  • Счита ли се това за нежелана електронна поща?

  • Счита ли се това за неупълномощена електронна поща?

Изключени групи

Пример: вие сте в изключена група, например сте непълнолетен, в санкционен списък или в държава от санкционен списък.

  • Допустимо ли е да подадете доклад?

  • Допустимо ли е да докладвате анонимно?

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

Трети страни

Пример: откривате, че софтуерът на дадена компания има грешка, свързана с трета страна, например интеграция с друг софтуер или друг уебсайт.

  • Допустимо ли е да докладвате цялата информация, която намерите, и на двете страни?

  • Необходимо ли е да се направят две отделни отговорни разкривания, например един доклад до едната компания и различен доклад до компанията на третата страна, с цел ограничаване на информацията, изпращана на всяка компания?

  • Допустимо ли е откривателят да свърже компаниите една с друга?

Деструктивен софтуер

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

  • Допустимо ли е?

  • Допустимо ли е откривателят да насочва потребителите към подобен софтуер и/или към ръководства или уроци, описващи как се създава този вид софтуер?

Координирано разкриване на уязвимости срещу отговорно разкриване

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

  • Най-важният аспект е координацията между откривателя и производителя.

Отговорното разкриване е остарял термин.

  • Хората имат различни виждания за това какво означава да си отговорен. Например някои хора твърдят, че е отговорно откривателят незабавно да уведоми обществеността независимо от всякакво взаимодействие с производителя, и безотговорно да се прави координирано разкриване на уязвимости, защото то скрива информация от обществеността.

Проследяване