Zero‑day: редкость или невидимый рынок?

“О zero‑day говорят как о редких и ценных находках — сокровищах, которые добывают раз в несколько лет. На самом деле всё проще. Дыры в софте возникают постоянно. Просто те, кто их находит, не афишируют. Вопрос не в редкости, а в том, кто и зачем ведёт поиск.”

Что такое zero-day и почему они создают иллюзию редкости

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

Но это только видимая часть. Большинство zero‑day уязвимостей остаются в тени. Их находят исследователи безопасности, тестировщики, участники программ Bug Bounty и киберпреступники. И у каждой из этих групп свои мотивы. Кто‑то сообщает об уязвимости разработчику за вознаграждение. Кто‑то продаёт её на теневом рынке или использует в целевых атаках, не оставляя следов. Так возникает разрыв между реальным количеством найденных уязвимостей и теми, о которых становится известно публично.

Кто и как ищет эти уязвимости

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

  • Легальные программы Bug Bounty. Многие крупные российские IT-компании и разработчики корпоративного софта запускают собственные программы поощрения для исследователей. Суммы вознаграждений варьируются в зависимости от критичности уязвимости. Этот рынок прозрачен и регулируется правилами ответственного раскрытия, но охватывает только тех, кто готов работать в легальном поле.
  • Исследовательские группы и коммерческие компании. Существуют организации, специализирующиеся на поиске уязвимостей для их последующей продажи клиентам — как для оборонительных целей (например, тестирование собственных систем), так и для наступательных. Здесь действует модель «нулевой день как товар».
  • Теневой рынок. Это закрытые форумы, каналы, площадки, где уязвимости и эксплойты продаются за криптовалюту. Цены определяются спросом: на уязвимости в массово используемом корпоративном ПО, в системах виртуализации или межсетевых экранах они будут значительно выше. Такой рынок невидим для большинства, и статистика по нему почти не фиксируется.
  • Государственные и полугосударственные структуры. Имеют собственные подразделения для разработки или покупки уязвимостей, которые впоследствии могут использоваться в рамках киберопераций. Часть из этих уязвимостей никогда не попадает в поле зрения разработчика.

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

Почему некоторые zero‑day годами остаются необнаруженными

Сложность кода и архитектурные особенности

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

Ограничения методов анализа

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

Стимулы и экономика поиска

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

Можно ли оценить реальное количество необнаруженных уязвимостей

Прямых способов подсчитать неизвестные уязвимости нет. Но есть косвенные методы оценки.

  • Анализ исторической динамики. Когда проект переходит на более безопасные практики разработки (например, использует памятьбезопасные языки), количество уязвимостей определённого класса резко снижается. Если посмотреть на проекты, которые ещё не прошли такой переход, можно экстраполировать примерное количество скрытых проблем.
  • Сравнение с подобными системами. Если в одном популярном веб-сервере за год находят 20 критических уязвимостей, а в другом, схожем по сложности и распространённости, — только 5, это не значит, что второй безопаснее. Скорее, он хуже исследован.
  • Анализ патчей после публикации zero‑day. Когда уязвимость всё-таки раскрывается, разработчик часто выпускает патч, который исправляет не только её, но и смежные проблемы, обнаруженные в ходе внутреннего аудита. Изучение таких патчей показывает, сколько потенциальных проблем могло оставаться незамеченным рядом с найденной дырой.

Большинство экспертов сходятся во мнении, что в типичном сложном корпоративном приложении существует некоторое количество неизвестных zero‑day. Это не апокалиптическая оценка, а просто следствие сложности современных систем.

Что это значит для российских регуляторов и 152-ФЗ

В контексте выполнения требований ФСТЭК и 152-ФЗ понимание природы zero‑day критически важно для построения реалистичной модели защиты.

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

  1. Слои защиты (Defense in Depth). Нельзя полагаться на один периметр. Нужна сегментация сети, строгий контроль доступа на уровне приложений, мониторинг аномальной активности. Цель — усложнить жизнь атакующему даже после успешного использования zero‑day.
  2. Минимизация поверхности атаки. Отключение ненужных сервисов, удаление избыточных прав, использование принципа наименьших привилегий. Чем меньше возможностей у системы, тем меньше шансов, что неизвестная уязвимость окажется в доступном для эксплуатации компоненте.
  3. Проактивный поиск уязвимостей. Вместо пассивного ожидания обновлений — регулярное проведение пентестов и аудитов безопасности, в том числе с использованием методов, имитирующих действия злоумышленника, который мог бы иметь доступ к zero‑day. В рамках 152-ФЗ это соответствует требованиям к оценке эффективности принимаемых мер.
  4. Подготовка к инцидентам. Понимание, что защита может быть прорвана. Наличие отработанных процедур обнаружения, реагирования и восстановления. Это уже не столько техническая, сколько организационная задача.

ФСТЭК в своих методических рекомендациях всё чаще смещает фокус от «заплатки всех известных дыр» к построению устойчивых архитектур. Zero‑day, это просто ещё один аргумент в пользу такого подхода.

Вывод: редкость, это миф, неизбежность, это реальность

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

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

Оставьте комментарий