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

NCSC.nl

1. Введение

Общество всё больше цифровизируется. Сегодня почти во всех процессах в какой-то момент используются компьютеры — от мобильных телефонов до специализированного программного обеспечения. Хотя это развитие открывает много новых возможностей, уязвимости в ИТ-системах могут иметь серьёзные последствия. Поэтому знания об этих уязвимостях необходимо использовать эффективно.

В начале 2013 года ряд организаций начал публиковать политики о том, как сообщать об уязвимостях. После консультаций с этими сторонами Национальный центр кибербезопасности (NCSC) обобщил эти разработки в виде «Руководящих принципов достижения практики ответственного раскрытия» (нидерл.: ‘Leidraad om te komen tot een praktijk van Responsible Disclosure’; далее — «Руководящие принципы»). Через такую политику компании показывают, что открыты для внешних сообщений об уязвимостях, описывают свои предварительные условия и дают обещания. Этот процесс создал ясность и относительно безопасную среду, в которой сообщающие стороны могли исследовать и сообщать об уязвимостях, не совершая напрямую уголовного преступления. На совещании высокого уровня ЕС по кибербезопасности в 2016 году 29 организаций вновь подтвердили важность политики обращения с уязвимостями, подписав Манифест скоординированного раскрытия уязвимостей (Coordinated Vulnerability Disclosure Manifesto)1, инициированный CIO Platform Netherlands и Rabobank в сотрудничестве с NCSC.

Скоординированное раскрытие уязвимостей (CVD) доказало свою большую значимость для государственных и частных сторон. В повседневной практике они в значительной мере зависят от бесперебойного функционирования информационных систем. Сообщения об уязвимостях в их системах помогли в последние годы повысить безопасность и непрерывность работы систем — с одной стороны, за счёт устранения уязвимостей, с другой — за счёт вклада в общую осведомлённость нидерландских компаний об ИТ-безопасности.

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

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

В следующих главах обсуждаются определение CVD, строительные блоки политики CVD и процесс коммуникации.

Примечание: в прежних Руководящих принципах использовался термин «ответственное раскрытие» (responsible disclosure), который тогда был общепринятым для этой практики. С тех пор стало ясно, что этот термин слишком сильно подчёркивает ответственность сообщающей стороны, тогда как основной принцип состоит в том, что сообщающая сторона и потенциально уязвимая организация должны быть равноправными партнёрами в диалоге. Это настроение лучше передаёт нынешний общеупотребительный термин «скоординированное раскрытие уязвимостей» (Coordinated Vulnerability Disclosure, CVD), которым этот процесс называется и в стандартах ISO 29147 и 30111.

2. Скоординированная уязвимость

За последние 30 лет для повышения осведомлённости об уязвимостях в ИТ-системах использовались различные методы. Примеры:

  • «Полное раскрытие» (Full Disclosure) — полное обнародование уязвимости;

  • «Нераскрытие» (Non-disclosure) — продажа или использование уязвимости самостоятельно;

  • «Скоординированное раскрытие уязвимостей» (CVD) — скоординированное раскрытие уязвимости.

Последняя практика однозначно предпочтительна.

ИТ-сообщество продемонстрировало большую готовность делиться знаниями и опытом. Поэтому стремление к сотрудничеству с этим сообществом может помочь повысить общую безопасность систем.

Цель скоординированного раскрытия уязвимостей

Цель CVD — внести вклад в безопасность ИТ-систем путём обмена знаниями об уязвимостях. В CVD знания передаются одной или нескольким потенциально уязвимым организациям, чтобы совместно с сообщающей стороной прийти к общему решению для найденной уязвимости. Важно, чтобы затронутые организации располагали достаточным временем для устранения любых уязвимостей или защиты систем, чтобы по возможности ограничить или предотвратить потери или ущерб. Краеугольный камень процесса — раскрытие знаний об уязвимостях после устранения.

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

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

Может быть важно информировать несколько сторон одновременно, если уязвимость затрагивает много систем. В таком случае NCSC или другие стороны в сообществе безопасности могут поддержать процесс CVD, выступая в координирующей роли.

3. Области ответственности

Цель реализации политики CVD — чтобы сообщающие стороны и организация работали вместе для сокращения уязвимостей в ИТ-системах. Внедрение этой политики следует рассматривать как дополнение к существующим мерам по информационной безопасности. У различных участников свои роли и обязанности. Они подробнее объясняются ниже.

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

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

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

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

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

Сторона, сообщающая об уязвимости

Каким-то образом сообщающая сторона смогла выявить уязвимость и хочет внести вклад в безопасность ИТ-систем, добиваясь устранения этой уязвимости и, возможно, её обнародования на более позднем этапе. Сообщающая сторона могла что-то обнаружить путём пассивного наблюдения или активного тестирования ИТ-системы. Разумеется, эта сторона отвечает за свои действия и за то, как она обнаружила уязвимость. Знать условия, установленные организацией в её политике CVD, — собственная ответственность сообщающей стороны. Большинство правительств и компаний опубликовали свои политики CVD на своих сайтах.

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

Если есть подозрение, что сообщающая сторона нарушила закон, политика CVD прежде всего может помочь предотвратить заявление на сообщающего в органы власти. Эта процедура целиком зависит от предварительных условий политики, соблюдения которых организация требует от сообщающей стороны, и от того, достигнуто ли такое соблюдение, возможно, с соответствующим обещанием не подавать уголовное заявление, пока сторона действует в рамках условий политики. Если подаётся заявление в полицию, наличие политики CVD и её соблюдение — релевантное обстоятельство в Нидерландах, которое прокурор учтёт при решении, начинать ли уголовное расследование и/или осуществлять ли уголовное преследование. В принципе, полиция и Прокуратура (OM) не будут начинать уголовное расследование, если сообщающая сторона явно соблюдала правила политики CVD соответствующей организации. Однако Прокуратура и полиция могут продолжить расследование дела, если есть признаки того, что сообщающая сторона сознательно или неосознанно зашла слишком далеко в своих действиях и/или не соблюдала политику CVD. На основании этого расследования Прокуратура может решить, преследовать ли в уголовном порядке.

Прокуратура опубликовала письмо о политике, в котором более конкретно рассматриваются аспекты, важные для принятия решения о расследовании и/или преследовании. Например, служили ли действия сообщающей стороны важному общественному интересу, действовала ли сторона несоразмерно и могла ли сторона, возможно, действовать иным, менее радикальным образом. В соответствующем письме эти аспекты раскрываются подробнее.2 Релевантная судебная практика с 2013 года3 показывает, что эти аспекты учитываются и в суде, если у организации нет политики CVD.

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

Ниже приведены строительные блоки для формирования процесса CVD для организации, сообщающей стороны и NCSC.

Организация

Продвижение CVD начинается с организации, которой принадлежат ИТ-системы или которая поставляет ИТ-продукт/систему. В конце концов, именно эта организация несёт основную ответственность за информационную безопасность этих ИТ-систем. Чтобы эффективно работать с различными сторонами над устранением уязвимостей, организация может решить составить и опубликовать политику CVD. Составление собственной политики CVD позволяет организации продемонстрировать, как она обращается с сообщениями об уязвимостях. Таким образом организация может также определить, каким образом она хочет получать уведомления. Такой процесс можно организовать следующим образом:

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

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

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

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

  • Практический опыт показывает, что после первоначальной публикации политики CVD интерес к сообщению организации об уязвимостях возрастёт. Организации следует учитывать это при планировании (дополнительных) ресурсов.

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

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

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

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

  • Может быть желательно продлить или сократить этот срок по взаимной договорённости в зависимости от того, много или мало ИТ-систем зависит от системы, для которой сообщено об уязвимости, или уязвимость проще или сложнее решить.

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

  • Организация будет информировать сообщающую сторону о ходе процесса.

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

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

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

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

Сообщающая сторона

Сообщающая сторона — ключ к успешному процессу CVD. Каким-то образом эта сторона смогла выявить уязвимость и хочет внести вклад в безопасность ИТ-систем, добиваясь устранения этой уязвимости организацией и её обнародования. Тем самым сообщающие стороны признают, что могут внести важный вклад в жизнь общества, раскрывая уязвимости скоординированным образом. Для успешного процесса CVD для сообщающей стороны важны следующие строительные блоки:

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

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

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

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

  • Сообщающая сторона и организация заключают чёткие договорённости о раскрытии уязвимости. Если задействована более чем одна организация, основной принцип состоит в том, что уязвимости могут быть опубликованы, только если все организации с этим согласны. Желательно заключать такие договорённости на раннем этапе.

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

NCSC

Процесс CVD — это прежде всего дело организаций и сообщающих сторон. Тем не менее NCSC будет поощрять использование процесса CVD. По согласованию с сообщающей стороной и организацией NCSC также может быть привлечён к обмену информацией об уязвимости со своей целевой аудиторией (constituency), чтобы ограничить дальнейшие риски безопасности, возникающие из-за уязвимости.

Если сообщение об уязвимости идёт не так, как ожидает сообщающая сторона, или если она предпочла бы не сообщать об уязвимости непосредственно организации, она может обратиться в 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 — смягчить уязвимость, но «полное раскрытие» уязвимости всегда остаётся для сообщающей стороны возможным вариантом, если она считает, что процесс займёт слишком много времени. Эта мера — пресловутая «большая дубинка» в руках сообщающей стороны. Естественно, этой ситуации следует по возможности избегать.

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

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

Сообщающие стороны получают публичное признание через благодарность в обновлении или включение в зал славы. Однако потребность в публичном признании есть не у всех сообщающих сторон; некоторые, напротив, не хотят становиться известными публике. Поэтому при коммуникации со стороны организации желательно получить согласие сообщающей стороны на упоминание её имени.

Кроме того, сообщающие стороны могут также решить говорить о сообщении после завершения процесса CVD. Например, сообщающая сторона может описать процесс обнаружения или предупредить других об уязвимости. Сообщающий может решить представить публикацию организации в информационных целях. Поскольку процесс CVD в принципе завершён после устранения уязвимости, сообщающая сторона впоследствии вправе свободно говорить об этом, если только в политике или в ходе процесса не заключены дополнительные договорённости.

Список

Коммуникация о процессе раскрытия

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

  • Чёткость в отношении ограничений (см. главу 6 о различных подходах)

  • Ограничения в методах исследования

  • Рекомендации по коммуникации

  • Рекомендации о возможных вознаграждениях: зал славы, денежное вознаграждение, футболка и т. д.

  • Чёткость в отношении любых обновлений политики CVD, включая даты изменений

Коммуникация во время процесса раскрытия

  • Сообщающий связывается с организацией по поводу обнаруженной уязвимости.

  • Организация управляет ожиданиями, такими как время ответа на первый технический отклик

  • Организация и сообщающий дают друг другу ясность относительно ожидаемого срока решения

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

  • При необходимости сообщающий и организация обсуждают обращение к другим соответствующим организациям

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

  • Обсуждение (публичного) признания и вознаграждения сообщающего

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

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

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

В политике CVD важны следующие элементы:

  • способ связи для безопасной коммуникации;

  • предварительные условия для сообщающих сторон;

  • чёткие ожидания относительно обработки сообщения;

  • способ вознаграждения за сообщение;

  • номер версии и дата последнего пересмотра.

Ниже приведены три примера: многие организации в Нидерландах опирались на базовый пример ResponsibleDisclosure.nl. Другие организации включают дополнительные предварительные условия, см. политику Fox IT. Третьи организации применяют более свободный формат, чтобы соответствовать своей целевой аудитории, см. политику Bits of Freedom.

В Acme Corporation мы считаем безопасность наших систем главным приоритетом. Но сколько бы усилий мы ни прилагали к безопасности систем, уязвимости всё равно могут присутствовать.

Если вы обнаружили уязвимость, мы хотели бы знать о ней, чтобы принять меры для её устранения как можно скорее.

Мы просим вас помочь нам лучше защищать наших клиентов и наши системы.

Пожалуйста, сделайте следующее:

  • Отправьте свои находки по электронной почте на cert@example.com. Зашифруйте свои находки нашим ключом PGP, чтобы эта критически важная информация не попала в чужие руки,

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

  • Не раскрывайте проблему другим, пока она не будет решена,

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

  • Предоставьте достаточно информации для воспроизведения проблемы, чтобы мы смогли решить её как можно скорее. Обычно достаточно IP-адреса или URL затронутой системы и описания уязвимости, но для сложных уязвимостей могут потребоваться дополнительные пояснения.

Что мы обещаем:

  • Мы ответим на ваше сообщение в течение 3 рабочих дней, указав нашу оценку сообщения и ожидаемую дату решения,

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

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

  • Мы будем держать вас в курсе прогресса в решении проблемы,

  • В публичной информации о сообщённой проблеме мы назовём ваше имя как обнаружившего проблему (если вы не пожелаете иначе), и

  • В знак нашей благодарности за вашу помощь мы предлагаем вознаграждение за каждое сообщение о проблеме безопасности, которая ещё не была нам известна. Размер вознаграждения будет определяться исходя из серьёзности утечки и качества сообщения. Минимальное вознаграждение — подарочный сертификат на 50 евро.

Мы стремимся решить все проблемы как можно скорее и хотели бы играть активную роль в окончательной публикации о проблеме после её решения.

Пример: Fox-IT

В Fox-IT мы считаем безопасность наших систем, нашей сети и наших продуктов чрезвычайно важной. Несмотря на большую заботу о безопасности, слабые места всё же могут оставаться. Если вы нашли такое слабое место, мы хотели бы узнать об этом как можно скорее, чтобы принять соответствующие меры как можно быстрее.

Слабые места можно обнаружить двумя способами: вы можете случайно наткнуться на что-то при обычном использовании цифровой среды или можете явно сделать всё возможное, чтобы их найти.

Наша политика ответственного раскрытия — не приглашение активно сканировать нашу бизнес-сеть для обнаружения слабых мест. Мы сами отслеживаем свою бизнес-сеть. Это означает, что существует высокая вероятность того, что сканирование будет обнаружено и наш Центр операций безопасности (SOC) проведёт расследование, что может привести к ненужным затратам. Тем не менее вас приглашают активно искать уязвимости в наших продуктах в автономной непроизводственной среде и сообщать нам о своих находках. Наша ответственность перед клиентами означает, что мы не намерены поощрять попытки взлома их инфраструктуры; однако мы хотели бы услышать от вас как можно скорее, если будут найдены уязвимости, чтобы мы могли надлежащим образом их устранить.

Мы хотели бы работать с вами, чтобы лучше защищать наших клиентов и наши системы.

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

  • Отправлять свои находки по электронной почте как можно скорее на security-alert@fox-it.com.

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

  • Не делиться проблемой с другими, пока она не будет решена.

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

  • Предоставлять достаточно информации для воспроизведения проблемы, чтобы мы могли решить её как можно скорее. Обычно достаточно IP-адреса или URL затронутой системы и описания уязвимости, хотя для более сложных уязвимостей может потребоваться больше информации.

Что мы обещаем:

  • Мы ответим на ваше сообщение в течение трёх рабочих дней, указав нашу оценку сообщения и ожидаемую дату решения.

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

  • Мы будем держать вас в курсе прогресса в решении проблемы.

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

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

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

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

Пример: Bits of Freedom

Наша зависимость от цифровой инфраструктуры постоянно растёт. Это относится к обществу в целом, но также и к нам самим. Поэтому мы считаем, что правительства и организации (включая нашу) должны твёрдо взять на себя обязательство по защите нашей цифровой инфраструктуры. Мы понимаем, что, несмотря на наши лучшие намерения и величайшую осторожность, в наших системах могут существовать уязвимости. Если вы случайно найдёте одно из таких слабых мест, мы с радостью выслушаем вас, чтобы мы могли решить проблему.

Что мы ожидаем от вас

  • Исследуя одну из наших систем, помните о соразмерности атаки. Нет необходимости демонстрировать, что если подвергнуть наш сайт крупнейшей в истории интернета DDoS-атаке, сайт может стать недоступным. Мы это знаем. Мы также понимаем, что если вы въедете бульдозером в наш офис, вы, вероятно, сможете утащить один из наших ноутбуков.

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

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

  • Открытый ключ OpenPGP для security@bof.nl

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

  • Вы удалите всю конфиденциальную информацию, которую вы получили в ходе своего исследования, как только мы устраним уязвимость.

Что вы можете ожидать от нас

  • Мы ответим на ваше сообщение в течение трёх дней подробно. Мы укажем оценку времени, которое потребуется нам для решения проблемы. Конечно, мы будем регулярно информировать вас о нашем прогрессе.

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

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

  • Для нас важно отметить вашу заслугу в том, что вы сделали, — если вы пожелаете. Мы упомянем ваше имя в публикации об уязвимости, только если вы на это согласитесь.

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

  • Если вы найдёте уязвимость в стороннем программном обеспечении, которое мы используем, и эта уязвимость охвачена программой bug bounty, мы не станем пытаться претендовать на это вознаграждение; на него должны претендовать вы.