Координированное раскрытие уязвимостей
Координированное раскрытие уязвимостей (англ. coordinated vulnerability disclosure)[1] — это модель раскрытия уязвимостей в области компьютерной безопасности, при которой информация о выявленной уязвимости или проблеме становится публичной только после того, как соответствующие ответственные лица получили достаточно времени для устранения (установки патча или иных мер по исправлению) обнаруженного изъяна. Такая координация отличает модель CVD от подхода «полного раскрытия уязвимостей».
Термин «координированное раскрытие» (CVD) вытеснил ранее использовавшийся термин «ответственное раскрытие» (англ. responsible disclosure)[2]. Процесс регламентируется международными стандартами ISO/IEC 29147 и ISO/IEC 30111[3][4].
Описание
Разработчикам аппаратного и программного обеспечения часто требуются время и ресурсы для исправления собственных ошибок. Как правило, подобные уязвимости находят этические хакеры[1]. Многие специалисты по безопасности и исследователи считают своим социальным долгом информировать общественность о подобных недостатках. Сокрытие проблем приводит к иллюзии безопасности. Во избежание этого заинтересованные стороны договариваются и координируют «разумный» срок для устранения проблемы. В зависимости от потенциального эффекта уязвимости, предполагаемого времени на разработку исправления или временного обходного решения, а также других факторов этот период может составлять от нескольких дней до нескольких месяцев.
Современные политики координированного раскрытия уязвимостей часто включают принцип «безопасной гавани» (англ. safe harbor), защищающий добросовестных исследователей, действующих в рамках опубликованной политики, от судебного преследования[2].
Жизненный цикл и участники
Исторически важную роль в процессе координации играл Координационный центр CERT (CERT/CC). С 1988 года он выступал в качестве доверенного посредника между исследователями безопасности и производителями, помогая координировать процесс раскрытия уязвимостей[5].
Жизненный цикл координированного раскрытия уязвимостей включает следующие основные этапы:[3]
- Обнаружение (англ. Detection): исследователь безопасности обнаруживает потенциальную уязвимость.
- Уведомление (англ. Reporting): обнаружившая сторона конфиденциально сообщает об уязвимости поставщику продукта.
- Оценка и подтверждение (англ. Triage and Validation): поставщик подтверждает получение отчёта, проверяет наличие уязвимости и определяет степень её критичности.
- Координация и исправление (англ. Coordination and Remediation): стороны договариваются о сроках исправления и раскрытия, а разработчики создают исправление (патч).
- Раскрытие (англ. Disclosure): после выпуска обновления безопасности информация об уязвимости становится публичной.
В процессе координированного раскрытия уязвимостей взаимодействуют несколько ключевых участников:[6]
- Исследователи безопасности (англ. Security Researchers): обнаруживают уязвимости, ответственно уведомляют разработчиков и соблюдают установленные сроки до публичного разглашения.
- Разработчики и поставщики (англ. Vendors / Developers): принимают отчёты, анализируют уязвимости, разрабатывают исправления и информируют пользователей.
- Координаторы (англ. Coordinators): выступают в роли третьей стороны, помогая в коммуникации, техническом анализе и управлении процессом.
- Конечные пользователи (англ. End-Users): устанавливают выпущенные обновления безопасности и применяют меры защиты.
Связь с Bug Bounty и Full Disclosure
Координированное раскрытие уязвимостей не всегда устраивает исследователей по информационной безопасности, ожидающих финансового вознаграждения за доклады об уязвимостях. В то же время сообщение об уязвимостях с расчетом на вознаграждение некоторыми рассматривается как шантаж[7][8]. Некоторые организации запускают так называемые программы поощрения обнаружения ошибок, чтобы вознаградить сообщения об уязвимостях через официальные каналы. К числу таких организаций относятся Facebook, Google, Barracuda Networks и другие[9].
Координированное раскрытие уязвимостей является фундаментом для легальных платформ Bug Bounty (таких как HackerOne и Bugcrowd)[10][11]. Эти платформы выступают посредниками между исследователями безопасности и организациями, обеспечивая структурированный и безопасный процесс сообщения об уязвимостях и их последующего раскрытия.
Принципиальное различие существует между координированным раскрытием и подходом полного раскрытия (англ. Full Disclosure). При полном раскрытии информация об уязвимости публикуется немедленно после обнаружения, без предварительного уведомления разработчика и предоставления ему времени на исправление. В то время как сторонники полного раскрытия стремятся максимально быстро проинформировать общественность, этот подход создаёт риск массовых атак до выхода патча. Программы Bug Bounty несовместимы с полным раскрытием и построены исключительно на принципах координированного раскрытия, при котором публикация деталей до исправления уязвимости запрещена[12].
Стандартизация и правовое регулирование
Основными международными стандартами в области координированного раскрытия являются ISO/IEC 29147:2018, определяющий методы раскрытия уязвимостей, и ISO/IEC 30111:2019, предоставляющий рекомендации для поставщиков по их обработке и устранению[3].[4]
В США регулирование для федеральных органов власти опирается на рекомендации Национального института стандартов и технологий (NIST) и директивы Агентства по кибербезопасности и защите инфраструктуры (CISA). Специальная публикация NIST SP 800-216 предлагает структуру для управления раскрытием уязвимостей[13]. Операционная директива CISA BOD 20-01 обязывает федеральные агентства разрабатывать собственные политики раскрытия уязвимостей, а также CISA ведёт Каталог известных эксплуатируемых уязвимостей (KEV)[14].[15]
В Европейском союзе требования к координированному раскрытию закреплены в Законе о киберустойчивости (Cyber Resilience Act, CRA). С сентября 2026 года эти требования становятся обязательными для производителей продуктов с цифровыми элементами на рынке ЕС. Закон обязывает производителей уведомлять Агентство ЕС по кибербезопасности (ENISA) и соответствующую национальную группу реагирования на инциденты компьютерной безопасности (CSIRT) в течение 24 часов с момента выявления активно эксплуатируемой уязвимости[16].
Политики раскрытия
Google Project Zero придерживается 90-дневного срока раскрытия, который отсчитывается с момента уведомления вендора об уязвимости: через 90 дней (или раньше, если производитель выпускает патч ранее) детали становятся общедоступными для сообщества специалистов по информационной безопасности[17]. С 2025 года введено правило раннего публичного уведомления: в течение недели после сообщения вендору раскрывается базовая информация об уязвимости (без технических деталей), при этом общие сроки в 90 дней на исправление и дополнительные 30 дней на установку патча сохраняются[18].
ZDI использует 120-дневный срок раскрытия, который начинается после получения ответа от вендора[19]. Помимо стандартных 120 дней, в политику введены сокращённые сроки (30, 60 и 90 дней) для случаев неполного или ошибочного исправления уязвимостей[19].
Компании Microsoft и GitHub применяют гибкий подход без жёстко фиксированных сроков раскрытия. Их политики ориентированы на сотрудничество с исследователями безопасности для совместного устранения проблемы до её публичного обнародования[20].[21]
Примеры
Избранные уязвимости были устранены по схеме координированного раскрытия:
- Коллизии MD5, позволившие создавать поддельные сертификаты центров сертификации, срок — 1 неделя[22]
- Гоночные условия/состояния с подарочными картами Starbucks, позволявшие создать дополнительные кредиты, срок — 10 дней (Егор Хомаков)[23]
- Обнаружение Дэном Камински массовой уязвимости в виде отравления кеша DNS (DNS cache poisoning), срок — 5 месяцев[24]
- Студенты MIT нашли уязвимость в системе безопасности метрополитена Массачусетса, дело MBTA против Андерсона, срок — 5 месяцев[25]
- Специалисты Университета Радбауда (Неймеген) взломали защиту карт MIFARE Classic, срок — 6 месяцев
- Уязвимость Meltdown, аппаратная уязвимость в процессорах Intel x86 и некоторых чипах на основе ARM, срок — 7 месяцев[26]
- Уязвимость Spectre, связанная с ошибками в реализации прогнозирования переходов и спекулятивного исполнения в современных процессорах, что позволяло получать доступ к данным в виртуальной памяти других процессов; срок — 7 месяцев[26]
- Уязвимость ROCA, связанная с небезопасно сгенерированными ключами RSA при помощи библиотеки от Infineon и устройств Yubikey, срок — 8 месяцев[27]
- Уязвимости HTTP/2 «Continuation Flood» (апрель 2024 года), координация раскрытия которых осуществлялась через CERT/CC с множеством вендоров[28].
- Критическая уязвимость в Fortinet SSL VPN (февраль 2024 года), устранение которой сопровождалось одновременным выпуском патча и публичным уведомлением[29].
Примечания
Литература
- ISO/IEC TR 5895:2022 — Многосторонняя координация раскрытия уязвимостей и работа с ними (англ.). ISO. Дата обращения: 5 октября 2024.
Ссылки
- Руководство CERT по координированному раскрытию уязвимостей
- Координированный процесс раскрытия уязвимостей (CVD) Агентства по кибербезопасности и защите инфраструктуры США (CISA)
- Подход Microsoft к координированному раскрытию уязвимостей
- Руководство Национального центра кибербезопасности Нидерландов по координированному раскрытию уязвимостей (архив)
- Программа координированного раскрытия уязвимостей Linksys
- Политика Глобального форума по киберэкспертизе (GFCE) по координированному раскрытию уязвимостей
- Заявление Philips по координированному раскрытию уязвимостей
- Политика ETSI по координированному раскрытию уязвимостей