? Это часть 2 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Законодательный аспект

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

Базовые законы, регулирующие вопросы информационной безопасности в России:

• Федеральный закон № 149-ФЗ “Об информации, информационных технологиях и о защите информации”;

• Федеральный закон № 187-ФЗ “О безопасности критической информационной инфраструктуры Российской Федерации”;

• Федеральный закон № 152-ФЗ “О персональных данных”.

И приказы ФСТЭК России, которые переводят законы на язык конкретных технических требований:

• приказ № 21 от 18.02.2013 - меры по обеспечению безопасности персональных данных

• приказ № 31 от 14.03.2014 - это документ, который утверждает требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды

• приказ № 235 от 21.12.2017 - об утверждении требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования

• приказ № 117 от 11.04.2025 - требования о защите информации в государственных информационных системах и иных системах госорганов. С 1 марта 2026 года заменил легендарный 17-й приказ, по которому отрасль жила 13 лет [1]

За несоблюдение предусмотрены санкции, и они растут. С 30 мая 2025 года действуют новые штрафы за утечки персональных данных: до 15 млн рублей за первую утечку, а за повторную - оборотный штраф 1-3% годовой выручки [2]. Появилась и уголовная ответственность за незаконный оборот персональных данных (статья 272.1 УК РФ). Времена, когда утечка стоила компании 60 тысяч рублей и формального извинения, закончились.

Перелом 2022 года

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

В апреле 2022 года НКЦКИ выпустил документ “Критерии для принятия решения по обновлению критичного ПО, не относящегося к open source”. Еще лет за пять до этого кейс с закладкой в обновлении ПО казался страшилкой, придуманной вендорами ИБ для продажи своих решений. Теперь это рабочая реальность: с февраля 2022 года любой пользователь на территории России может быть отключен от обновлений просто по геолокации. А само обновление из доверенной процедуры превратилось в потенциальный вектор атаки. Несколько примеров для наглядности:

В документе НКЦКИ прописаны важные оговорки:

• алгоритм - это рекомендация, а не догма;

• перед переносом в продуктивную среду обновление нужно проверить в тестовом сегменте;

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

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

• для АСУ ТП и мобильных ОС этот алгоритм применять не рекомендуется.

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

Дальше события развивались по нарастающей.

Октябрь 2022 года - ФСТЭК выпускает “Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств”. Главная фишка методики: оценка привязывается к вашей инфраструктуре. Каждая компания уникальна, как отпечатки пальцев, и одна и та же уязвимость в разных инфраструктурах несет разный риск. В июне 2025 года методика обновлена: теперь расчет строится на базовой оценке CVSS, доступности эксплойта и последствиях эксплуатации, без трудоемких временных и контекстных метрик [3]. Формулу мы подробно разберем в главе про приоритизацию.

Май 2023 года - ФСТЭК публикует “Руководство по организации процесса управления уязвимостями в органе (организации)”. Это уже полноценная методика построения процесса: пять этапов (мониторинг, оценка, определение методов устранения, устранение, контроль), роли участников, связь с методикой оценки критичности [4]. По сути, государственный учебник по VM. Рекомендательный, но именно по нему проверяющие понимают, как “должно быть”.

Апрель 2025 года - выходит приказ № 117, и управление уязвимостями впервые становится обязательным требованием с конкретными сроками. Для государственных информационных систем: критические уязвимости - устранить за 24 часа, высокие - за 7 дней, сканирование - не реже раза в месяц. А если вы нашли уязвимость, которой нет в БДУ, - сообщите о ней во ФСТЭК в течение 5 рабочих дней [1]. Регулятор фактически ввел SLA на уровне нормативного акта. Для понимания масштаба: еще недавно многие компании считали нормой квартальный цикл патчинга.

Ноябрь 2025 года - ФСТЭК утверждает “Методику анализа защищённости информационных систем” (информационное сообщение № 240/22/6902 от 04.12.2025). Тут регулятор впервые расписывает не “что искать”, а “как сканировать”. Работу разделили на два обязательных вида. Внешнее сканирование (С1) - это взгляд на инфраструктуру глазами внешнего нарушителя: периметр, торчащие в интернет сервисы, доменные имена. Внутреннее (С2) - серверы, сетевое оборудование, средства защиты, рабочие места. Привязана методика к аттестации по приказам № 117, 21, 31, 235 и 239.

Отдельно стоит отметить Указ Президента № 250 от 01.05.2022: он закрепил персональную ответственность заместителя руководителя за ИБ и с 1 января 2025 года запретил госорганам и субъектам КИИ использовать средства защиты из “недружественных” стран [5]. Для процесса управления уязвимостями это означало смену всего инструментария - об этом чуть ниже.

Российский путь в деле борьбы с уязвимостями

Ни одна страна сейчас не подвергается такому количеству кибератак, и ни у кого нет такого опыта их отражения: по сути, мы находимся в состоянии кибервойны. Многие нюансы процесса управления уязвимостями приходится пересматривать и “резать наживую”. Зато этот опыт - боевой, а не кабинетный.

Киберпреступники и APT-группировки в основном используют три типа атак: DDoS, фишинг и эксплуатацию уязвимостей. По статистике НКЦКИ, еще в 2023 году эксплуатация уязвимостей на периметре была второй по распространенности причиной инцидентов в крупных российских компаниях (первое место заняли атаки через подрядчиков, но подрядчиков тоже сначала кто-то взламывает, и чаще всего - через уязвимости). Мировая статистика подтверждает тренд: по данным Verizon DBIR 2026, эксплуатация уязвимостей вышла на первое место среди векторов взлома - 31% всех инцидентов [6].

Многие иронизируют над фразами “сделаем свое”, “отечественное лучше зарубежного”, “аналогов нет”. Но в управлении уязвимостями национальная специфика - это не пропаганда, а необходимость. Посмотрите на руководство по построению VM-процесса от Национального центра кибербезопасности Великобритании (NCSC): думаете, до англичан никто таких документов не писал? Писали, конечно. Но в каждой стране своя специфика: свое законодательство, свой ландшафт угроз, свой софт. Самым ярким отечественным примером стала уязвимость в продуктах “1С-Битрикс”: в 2022-2023 годах через нее массово ломали российские сайты (примеры не сложно найти, можно сходить на Хакер, Habr или еще куда), и этот кейс не нашел бы отражения ни в одном западном руководстве. Ну или RCE в Trueconf 2025 года, тоже чисто отечественная специфика.

Раньше Россия активно участвовала в международных кампаниях по борьбе с киберугрозами: обмен информацией, совместные расследования, работа с международными CERT. Сейчас многие из этих связей приостановлены или разорваны. Кстати, чтобы прочувствовать картину международных взаимодействий, рекомендую мини-сериал “Русские хакеры: Начало” ну и из последнего не могу не рекомендовать фильм про Реверс-инжиниринг.

Есть и еще одно следствие изоляции, уже глобальное: мир движется к фрагментации баз данных уязвимостей. В апреле 2025 года программа CVE, на которой держится вся мировая идентификация уязвимостей, едва не остановилась из-за прекращения финансирования контракта MITRE (его продлили в последний момент, буквально за день) [7]. Евросоюз в мае 2025 года запустил собственную базу уязвимостей EUVD. Россия задолго до этого сделала ставку на БДУ ФСТЭК. Единого мирового “реестра дыр” больше не существует: источников теперь несколько, и работать приходится со всеми.

Ключевое отличие России - массовое импортозамещение. Технологически отечественные вендоры во многом догоняют западных (точно не везде, но отдельные исключения правда есть), у которых за плечами десятилетия опыта разработки, публикации уязвимостей и выстраивания процессов их устранения. Мы встали на этот путь недавно, но идем по нему семимильными шагами: Указ № 250 и закон № 325-ФЗ (обязательное использование ПО из реестра Минцифры для КИИ с 2026 года) не оставляют выбора [5].

“Неуязвимое” российское ПО

Множество отечественного ПО, включая операционные системы, базируется на общеизвестных открытых проектах: дистрибутивах Linux (Debian, CentOS, RHEL и их производных) и BSD-системах. Возникает вопрос: что делать с их уязвимостями? Система ведь переработана, это уже не тот дистрибутив, который брали за основу. Уязвимость исходного Debian может быть применима к российской ОС, а может и нет, и наоборот: доработки могли привнести собственные уязвимости.

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

1. поиск уязвимостей еще на этапе разработки (статический и динамический анализ кода, фаззинг);

2. после вывода продукта на рынок - багбаунти с финансовой мотивацией исследователей;

3. при нахождении уязвимости - разработка патча, присвоение идентификатора (если не CVE, то как минимум BDU в БДУ ФСТЭК) и публикация информации в общий доступ.

Кстати, требования к безопасной разработке у нас теперь тоже закреплены стандартом: ГОСТ Р 56939-2024 описывает 25 процессов безопасной разработки ПО, включая управление уязвимостями, и с 2025 года применяется при сертификации средств защиты [8].

Но многие разработчики отечественного ПО до сих пор считают: продукт получил сертификат ФСТЭК, прошел испытания в лаборатории - значит, он неуязвим, и больше ничего делать не нужно. Это опасное заблуждение. В решении могут быть уязвимости нулевого дня, и когда их найдут, их нужно устранить, а информацию опубликовать для всех клиентов. Если в продукте используются open source компоненты, при нахождении в них уязвимостей клиентам как минимум должна быть предоставлена информация о методах исправления. Подробно эту тему разбирали в подкасте “КиберДуршлаг” с экспертом Astra Linux Владимиром Тележниковым.

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

От себя добавлю то, с чем сталкиваюсь постоянно. Российское ПО проходит сертификацию в регуляторах, получает сертификат о соответствии требованиям - и многие вендоры после этого начинают говорить, что теперь-то их продукт безопасен и уязвимостей не содержит. Это не так. Сертификат не делает тебя неуязвимым! И это, пожалуй, главная проблема в мышлении российских вендоров. На Западе давно сложилась культура публикации информации об уязвимостях: компании из одной ниши порой соревнуются между собой, кто нашел и раскрыл больше уязвимостей в собственном продукте. Это характеризует вендора как открытого со своими клиентами и показывает, что он действительно делает продукт безопаснее. В России это пока работает с трудом. Но очень хочется это изменить.

Справедливости ради: с момента, когда писались эти слова, ситуация начала меняться. Российские вендоры выходят на багбаунти-платформы, количество программ на Standoff Bug Bounty за 2025 год выросло в 2,2 раза (до 233), а БДУ ФСТЭК пополняется записями об уязвимостях отечественного ПО [9]. Культура формируется. Медленнее, чем хотелось бы, но формируется.

А что с белыми хакерами?

Раз уж заговорили о багбаунти, нельзя обойти юридический парадокс: деятельность белых хакеров в России до сих пор законодательно не урегулирована. Законопроект о легализации поиска уязвимостей обсуждается с 2022 года, в июле 2025-го Госдума отклонила его во втором чтении (не договорились о доступе исследователей к гостайне и КИИ), осенью 2025-го началась работа над новой редакцией, где контроль предлагается отдать ФСБ, ФСТЭК и НКЦКИ [10]. Пока же исследователи и компании работают в серой зоне, опираясь на оферты багбаунти-платформ. На практике система работает, но всем участникам было бы спокойнее с нормальным законом.

А как у вас?

Под какие из приказов вы попадаете и как встретили приказ № 117 с его сутками на критическую уязвимость - как реальную задачу или как “бумажку, которую невозможно выполнить”? И изменился ли у вас процесс обновления зарубежного ПО после 2022 года?

Навигация по серии: ⬅️ Предыдущая: Гл. 1. Управление уязвимостями с нуля · ? Оглавление серии · Следующая: Гл. 3. Через что вас взломают ➡️

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