ПОЛИТИКА РАСКРЫТИЯ УЯЗВИМОСТЕЙ
Обеспечение координации работы с уязвимыми местами в системе безопасности
Сообщение об уязвимости
Мы настоятельно рекомендуем сообщать о потенциальных уязвимостях в системе безопасности сначала нам, прежде чем раскрывать их на публичном форуме.
Основной адрес электронной почты для сообщения о любой уязвимости или проблеме безопасности [email protected]. Использование других контактных адресов общего назначения не обеспечит должного управления вопросами безопасности, пожалуйста, используйте этот адрес для сообщения о нераскрытых уязвимостях безопасности.
Пожалуйста, обратите внимание, что контакты безопасности должны использоваться только для сообщения о нераскрытых уязвимостях безопасности в Pandora FMS и управления процессом их устранения. Мы не можем принимать обычные сообщения об ошибках или вопросы об архитектуре безопасности по этим адресам. Вся почта, отправленная на эти адреса и не относящаяся к нераскрытой проблеме безопасности в Pandora FMS, будет проигнорирована.
Также обратите внимание, что команда безопасности занимается устранением уязвимостей в Pandora FMS, а не предоставляет поддержку, консультационные услуги, развертывание или разработку пользовательских функций. Все сообщения об уязвимостях следует отправлять только на адрес
[email protected] . Пожалуйста, отправляйте по одному письму в открытом виде для каждой уязвимости, о которой вы сообщаете. Мы можем попросить вас повторно отправить отчет, если вы пришлете его в виде изображения, фильма, HTML или PDF, когда его можно было бы с тем же успехом описать обычным текстом. Пожалуйста, не отправляйте одно письмо, содержащее сразу несколько проблем.
Отправка зашифрованных сообщений не обязательна и предпочтительна, так как нам потребуется гораздо больше времени, чтобы ответить на такие сообщения.
Как сообщить о проблеме безопасности?
Следующая информация будет полезна для команды безопасности Pandora FMS:
- Дата и время, когда вы обнаружили дефект безопасности.
- Диапазон затронутых версий Pandora FMS.
- Тип проблемы безопасности, о которой вы сообщаете, например: XSS, CSRF, SQLi, RCE.
- Затронутые компоненты, например: Консоль, Сервер, Агент, API…
- Любые подробности, которые вы можете предоставить, например, скриншоты, записи экрана, журналы транзакций http(s), POC-эксплойты (пожалуйста, не передавайте доказательства через неаутентифицированные файлообменные службы и избегайте передачи конфиденциальной информации.
- Пошаговые инструкции по воспроизведению проблемы, так как проблема может быть нелегко идентифицируема.
Информация об уязвимостях
Информацию об опубликованных уязвимостях для Pandora FMS обычно можно найти в примечаниях к выпуску. Если вы не можете найти интересующую вас информацию на сайте проекта, задайте свой вопрос на форумах. Контакты службы безопасности не следует использовать для того, чтобы задавать вопросы о том.
- Как безопасно сконфигурировать пакет;
- Если опубликованная уязвимость относится к конкретным версиям
- используемых вами пакетов Pandora FMS;
- Если опубликованная уязвимость относится к конфигурации используемых вами пакетов Pandora FMS;
- Получение дополнительной информации об опубликованной уязвимости;
- наличие исправлений и/или новых выпусков для устранения опубликованной уязвимости.
Задавать такие вопросы можно на наших публичных форумах. Любые подобные вопросы, направленные команде безопасности Pandora FMS, будут проигнорированы.
Обработка уязвимостей
Типичный процесс обработки новой уязвимости безопасности выглядит следующим образом:
Примечание: Не следует публиковать никакой информации об уязвимости до тех пор, пока она не будет официально объявлена в конце этого процесса. Это означает, например, что для отслеживания проблемы НЕ должна создаваться проблема на Github, поскольку это сделает проблему публичной. Также сообщения, связанные с любыми фиксами, не должны содержать НИКАКИХ ссылок на безопасность фикса.
- Человек, обнаруживший проблему, сообщает об уязвимости в частном порядке на [email protected].
- Сообщения, не относящиеся к сообщению о нераскрытой уязвимости в Pandora FMS, игнорируются и не требуют дальнейших действий.
- Если сообщение поступило на [email protected], команда безопасности пересылает его (не подтверждая) другим членам команды безопасности.
- Команда проекта отправляет электронное письмо первоначальному автору сообщения, чтобы подтвердить его.
- Команда проекта изучает отчет и либо отклоняет его, либо принимает.
- Если отчет отклоняется, проектная группа направляет корреспонденту письмо с объяснением причин.
- Если отчет принят, проектная группа пишет сообщение, чтобы сообщить, что отчет принят и что они работают над исправлением.
- Команда безопасности присваивает внутренний номер дела безопасности и один или несколько тикетов разработки, связанных с этим номером дела безопасности.
- Команда безопасности присвоит репортеру номер CVE. Pandora FMS теперь является CVE CNA.
- Команда проекта предоставляет репортеру копию исправления и проект объявления об уязвимости для комментариев.
- Команда безопасности согласовывает с репортером исправление, объявление и график выпуска. Уровень детализации отчета – это вопрос суждения. Как правило, отчеты должны содержать достаточно информации, чтобы люди могли оценить риск, связанный с уязвимостью, для своей системы, и не более того.
- Шаги по воспроизведению уязвимости обычно не включаются.
- Команда проекта фиксирует исправление и включает его в релиз.
- Команда проекта объявляет о выпуске. Объявление о выпуске должно быть разослано по обычным каналам (рассылка, форумы, веб-сайт).
- Клиентам с действующими соглашениями о поддержке отправляется электронное письмо с указанием периода времени, в течение которого можно обновиться до того, как проблема станет общеизвестной.
- Команда проекта объявляет об уязвимости общественности (включая обновление CVE). Объявление об уязвимости должно быть отправлено ПОСЛЕ объявления о выпуске. Чаще всего публичное оповещение происходит не менее чем через ОДИН МЕСЯЦ после выпуска исправления, чтобы дать пользователям и заказчикам достаточно времени для обновления программного обеспечения.
Информация может быть передана экспертам в данной области (например, коллегам вашего работодателя) по усмотрению команды безопасности проекта при условии, что будет ясно, что информация не предназначена для публичного раскрытия и что [email protected] должен быть скопирован на любое сообщение, касающееся уязвимости.