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

Мы приветствуем пул-реквесты, задачи (issues) на GitHub или письма на адрес security@joelparkerhenderson.com.

Что такое скоординированное раскрытие уязвимостей?

Скоординированное раскрытие уязвимостей описывает три шага, когда кто-то обнаруживает проблему безопасности (например, программную ошибку) и хочет сообщить о ней производителю (например, компании, выпускающей это программное обеспечение).

Шаги:

  1. Обнаруживший добросовестно и конфиденциально сообщает о проблеме производителю.

  2. Производитель добросовестно пытается защитить пользователей и устранить проблему.

  3. Через оговорённое время проблема безопасности становится публичной.

Шаг 1: Сообщите о проблеме

Шаг 1 предназначен для обнаружившего: добросовестно и конфиденциально сообщите о проблеме.

  • Хорошо: обнаруживший отправляет соответствующую информацию производителю, например по электронной почте на адрес безопасности производителя (обычно «security@example.com») или через веб-форму на сайте производителя (обычно «https://www.example.com/security»).

  • Плохо: публикация сообщения в открытом блоге, оповещение СМИ, угрозы или попытки продать проблему безопасности хакерам и так далее.

  • Совет: обнаруживший может остаться анонимным; производитель тоже может остаться анонимным.

При желании продолжайте следить за проблемой.

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

  • Плохо: забыть о проблеме.

  • Совет: обнаруживший может выбрать, помогать или нет, а также поддерживать связь или нет, а также может изменить договорённость, если обстоятельства изменятся.

При желании раскройте проблему другим.

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

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

  • Совет: если обстоятельства изменятся, например будет обнаружен более высокий риск или активная эксплуатация в дикой природе (active exploit 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), постмортем-отчётов, диаграмм Исикавы или причинного анализа на основе системной теории (CAST).

  • Рассортированы ли и отслеживаются ли остающиеся нерешённые вопросы?

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

Руководство

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

Если вы ищете руководство, вас могут заинтересовать эти три области, описанные ниже.

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

  • Обязанность спасать

  • Обязанность проявлять осмотрительность

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

Wikipedia: Закон о добром самаритянине

Законы о добром самаритянине (Good Samaritan laws) предоставляют правовую защиту людям, оказывающим разумную помощь тем, кто ранен, болен, находится в опасности или иным образом беспомощен, либо кого они считают таковыми. Защита призвана уменьшить колебания очевидцев, которые не решаются помочь из страха быть привлечёнными к суду или преследованию.

Обязанность спасать

Wikipedia: Обязанность спасать

Обязанность спасать — это понятие, описывающее обстоятельства, при которых сторона может быть привлечена к ответственности за то, что не пришла на помощь другой стороне, находящейся в опасности. Обязанность спасать может иметь моральные и/или юридические области.

Обязанность проявлять осмотрительность

Wikipedia: Обязанность проявлять осмотрительность

Обязанность проявлять осмотрительность — это обязательство соблюдать стандарт разумной осмотрительности при совершении любых действий, которые могут предсказуемо причинить вред другим. Обязанность проявлять осмотрительность может иметь моральные и/или юридические области. Некоторые аспекты, которые следует учитывать: предсказуемость вреда или ущерба, возможный масштаб потенциального вреда или ущерба, важность или общественная ценность деятельности, которой занимался ответчик, полезность поведения для ответчика, осуществимость альтернативного поведения, затраты и бремя, связанные с альтернативным поведением, относительная полезность альтернативного поведения и относительная безопасность альтернативного поведения.

Особые случаи

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

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

Доступ к информации других пользователей

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

  • Допустимо ли обнаружившему делать это, например с единственной целью выяснить, затрагивает ли это и других пользователей?

  • Важнее ли быстро понять масштаб риска для всех пользователей, чем защитить пару пользователей, чья информация, возможно, уже видна хакерам?

  • Допустимо ли обнаружившему делать это с таким количеством пользователей, сколько он захочет?

  • Допустимо ли обнаружившему пытаться связаться с пользователями, чтобы сообщить им, что они затронуты? Допустимо ли предлагать меры по смягчению?

Отказ в обслуживании

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

  • Считается ли это атакой типа «отказ в обслуживании»?

Нежелательная электронная почта

Пример: вы пытаетесь сообщить о проблеме безопасности людям в компании, которых считаете подходящими и которых находите, изучая LinkedIn, Facebook и т. д. или используя соглашения об именовании, такие как «webmaster@example.com» или «security@example.com».

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

  • Считается ли это нежелательным письмом (unsolicited email)?

  • Считается ли это несанкционированным письмом (unauthorized email)?

Исключённые группы

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

  • Допустимо ли вам отправлять сообщение?

  • Допустимо ли сообщать анонимно?

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

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

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

  • Допустимо ли вам сообщить всю найденную информацию обеим сторонам?

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

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

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

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

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

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

Скоординированное раскрытие уязвимостей и ответственное раскрытие

Скоординированное раскрытие уязвимостей — предпочтительный термин.

  • Самый важный аспект — координация между обнаружившим и производителем.

Ответственное раскрытие (responsible disclosure) — устаревший термин.

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

Отслеживание