Создание вашего ВДП

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

Как создать и разместить политику вашей программы

Используйте приведенные ниже рекомендации для разработки политики программы для вашего VDP. Политики программы обычно занимают всего 1–3 страницы и обычно включают следующие темы:

  • Обещание исследователя
  • Рекомендации по тестированию
  • Объем программы

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

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

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

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

Дополнительные сведения о том, что включить в политику вашей программы, можно найти в документе Министерства юстиции США « Структура программы раскрытия уязвимостей для онлайн-систем ».

Заинтересованные стороны политики программы

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

Акционер Соображения
Юридический
  • Вместе со своей командой юристов разработайте политику и условия вашей программы, на которых будут участвовать хакеры.
  • Исследователи не получают вознаграждения, поэтому нет веских причин подвергать себя строгим требованиям по адаптации или обременительным условиям.
ЭТО
  • Работайте со своей ИТ-командой, чтобы помочь разработать требования и объем тестирования, например, не создавать условий отказа в обслуживании.
Инженерное дело
  • Инженерные специалисты могут внести свой вклад в определение требований и объема тестирования, включая определение того, какие типы уязвимостей являются наиболее или наименее интересными.
пиар
  • Вместе со своей командой по связям с общественностью изучите формулировки политики раскрытия информации.
Безопасность
  • Команда безопасности обычно руководит созданием политики.
  • Команда безопасности, скорее всего, будет получать отзывы от хакеров и со временем дорабатывать политику вместе с другими заинтересованными сторонами.

Обещание исследователя

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

Пример:

<Название вашей организации> стремится сотрудничать с исследователями безопасности, чтобы помочь выявить и устранить уязвимости в наших системах и службах. Если вы действуете добросовестно и соблюдаете правила, изложенные в настоящей политике, мы приложим все усилия, чтобы обеспечить следующее:
  • Предоставьте первоначальный ответ на ваш отчет об уязвимости в течение трех рабочих дней.
  • Определите, примем ли мы (намеримся исправить) или отклоним (определим ваш отчет как ложноположительный или приемлемый риск) ваш отчет об уязвимости в течение десяти рабочих дней.
  • Держите вас в курсе прогресса в исправлении отчетов, которые мы получаем от вас.

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

Рекомендации по тестированию

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

Пример:
При проведении тестирования безопасности придерживайтесь следующих правил:

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


Нас особенно интересуют следующие типы уязвимостей и воздействий:

  • Удаленное выполнение кода
  • XSS, приводящий к доступу к конфиденциальным данным (например, информации о сеансе)
  • SQL-инъекция, приводящая к доступу к конфиденциальным данным или функциям
  • Ошибки бизнес-логики, которые приводят к доступу к конфиденциальным данным или функциям.


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

  • Отсутствие заголовка X-Frame-Options на страницах без функции изменения состояния.
  • Непроверенные результаты автоматического сканирования
  • Проблемы, которые вряд ли можно будет использовать и/или которые не оказывают реального влияния на безопасность.

Объем

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

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

Объект mail.example.com
Описание Основной домен для доступа пользователей к своей электронной почте.
Интересные уязвимости и последствия
  • Уязвимости, приводящие к несанкционированному доступу к электронной почте других пользователей.
  • Возможность безвозвратно удалить электронную почту или всю учетную запись другого пользователя.
Проблемы, которые могут быть отклонены
  • СПФ
  • Фишинг или проблемы, способствующие фишингу
  • Возможность отправлять потенциально вредоносные вложения.
Рекомендации по тестированию Тестируйте только на учетных записях, которыми вы владеете или на которые вы дали явное согласие. При создании тестовых учетных записей укажите «vdptest» где-нибудь в имени пользователя. Вы можете создать тестовые учетные записи по адресу mail.example.com/new.

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

В области

  • mail.example.com
  • example.com

Вне сферы применения

  • blog.example.com

Ресурсы для вашего VDP

Перед запуском VDP вам потребуются определенные ресурсы. Вам понадобятся ресурсы для:

  • Просмотр входящих отчетов об уязвимостях
  • Общение с хакерами
  • Поиск владельцев активов и регистрация ошибок
  • Исправление ошибок
  • Управление уязвимостями/последующие действия по устранению

Повторный визит к ключевым заинтересованным сторонам

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

Создайте свою команду

Запуск VDP требует приличного объема оперативной работы, управляемой прерываниями. Если вы попытаетесь самостоятельно просматривать, технически проверять и реагировать на каждый поступающий отчет об уязвимостях, а также регистрировать каждую ошибку, отслеживать статусы и сообщать обновления исследователям, вы можете перегореть. Даже если у вас нет большой команды безопасности, найдите добровольцев, заботящихся о безопасности, которые помогут создать команду, которая поможет ввести в эксплуатацию и запустить ваш VDP. Вам по-прежнему понадобится определенный «владелец» или «лидер» вашего VDP, который в конечном итоге будет нести ответственность за успех вашего VDP, но вам также понадобится команда для поддержки этого лидера.

Постройте график дежурств

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

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

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

  • Убедитесь, что ваша команда готова вмешаться и помочь поддержать дежурство в особенно тяжелые недели.
  • Иметь хороший процесс передачи управления; Если есть проблемы, которые могут потребовать немедленного внимания со стороны следующего дежурного, напишите несколько записок или проведите живую беседу в конце недели.
  • Создайте автоматическое расписание, чтобы каждый знал, когда он на дежурстве. Это может быть так же просто, как создание повторяющихся записей календаря для каждого человека.
  • Особенно перед началом вашего VDP, дважды посоветуйтесь с дежурным, чтобы убедиться, что он помнит, что это его неделя, а также узнать, нужна ли ему какая-либо помощь. Если у вас в ротации больше младших сотрудников, попросите более старших сотрудников работать с ними, чтобы они чувствовали себя комфортно и могли задавать вопросы по мере их роста.
  • Используйте гибкий процесс смены недель. Неизбежно у кого-то возникнет чрезвычайная ситуация, и ему потребуется взять отпуск в течение недели, или кто-то возьмет отпуск и т. д. Когда это произойдет, предложите команде менять недели по мере необходимости, чтобы учесть график каждого.
  • Создайте «шпаргалку» по дежурству, в которой будет указано, какие обязанности необходимо выполнять, включая документацию о том, как это сделать.

Определитесь с собственными или сторонними организациями.

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

Получение отчетов

Если вы решите использовать стороннюю платформу, у хакеров должна быть возможность отправлять отчеты непосредственно вам. Если вы создаете свою программу самостоятельно, вам придется создать ее самостоятельно. Это может быть адрес электронной почты, который автоматически создает заявку или ошибку в вашей системе отслеживания проблем (например, security@example.com), или это может быть веб-форма с обязательными полями формы, которая либо связана с политикой вашей программы, либо находится на ней на той же странице. . В какой бы форме это ни было, это ваш лучший шанс проинформировать хакеров о формате, в котором вы хотели бы получать ваши отчеты. Имейте в виду, что просьба хакеров отправлять отчеты в определенном формате не всегда гарантирует, что они это сделают, но это не так. больно спрашивать. Вот пример того, что вы можете запросить в форме отправки отчета:

Заголовок: [Пожалуйста, добавьте описание проблемы в одну строку, например «XSS в mail.example.com».
приводит к краже сеанса"]

Краткое описание: [Пожалуйста, добавьте краткое описание уязвимости и почему это важно, например, из-за отсутствия экранирования вы можете отправить электронное письмо другому пользователю, содержащее полезную нагрузку XSS, которая позволит злоумышленнику украсть файлы cookie другого пользователя, содержащие информацию о сеансе. Это позволит злоумышленнику войти в учетную запись жертвы.] Этапы воспроизведения: [Пожалуйста, добавьте пошаговые инструкции о том, как воспроизвести уязвимость.]
1.
2.
3.

Сценарий атаки и последствия: [Как это можно использовать? Какое влияние это оказывает на безопасность
возникла проблема?] Совет по устранению: [При необходимости, если у вас есть какие-либо советы о том, как можно исправить или исправить эту проблему, добавьте их сюда.]