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

Технологии - это половина дела. Вторая половина, на которой чаще всего и спотыкается процесс VM, - организация. Кто за что отвечает, в какие сроки, по каким правилам. Об этом и поговорим.

Предварительные мероприятия

Чтобы построить работающий процесс VM, нужно заранее:

• провести предварительные мероприятия

• определить перечень недопустимых событий

• распределить роли и функции среди всех участников

• убедиться, что эти роли есть кому исполнять

• согласовать параметры процесса со всеми участниками и заинтересованными сторонами

Без ресурсов выстроить процесс невозможно - в лучшем случае он получится медленным и неэффективным. Поэтому на старте важно запланировать расширение команды или привлечение сторонних ресурсов (например, через аутсорсинг). Разобравшись с ролями, переходим к параметрам процесса.

Первичные параметры - это технические условия сканирования: учетные записи и режимы. По мере развития процесса появятся главные параметры - SLA и KPI. Исходными данными для них послужат сведения об ИТ-активах: их количество, группировка, принадлежность к целевым или ключевым системам, технологические окна.

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

И еще один параметр - источники данных об уязвимостях. Это сведения от вендоров средств защиты, ОС и прикладного ПО, а также из общедоступных баз: MITRE CVE, NVD, БДУ ФСТЭК. Заранее продумайте, из каких источников и как часто компания будет получать эту информацию. Тема источников сейчас особенно актуальна: мировая экосистема данных об уязвимостях фрагментируется (кризис NVD, появление европейской базы EUVD), и опираться только на один источник стало рискованно. Подробно об этом - в главе про источники данных.

Распределение ролей и функций

На практике мы часто видим типичную картину: функции анализа уязвимостей повесили на администратора средств защиты. Средств много, администратор один. В итоге задачи выполняются неохотно: запустил сканер, сгенерировал отчет - и все. Пользы от такого VM немного.

Нужно назначить человека, который отвечает за VM в целом. Поскольку это один из ключевых процессов кибербезопасности, владельцем должен быть эксперт из команды ИБ. Это не должность “по совместительству”, это ответственность.

Кроме владельца, понадобятся:

• Выделенные эксперты из команды ИБ. Они сканируют инфраструктуру, анализируют результаты, приоритизируют уязвимости и контролируют устранение

• Представители команды ИТ. Они отвечают за техническую часть и непосредственно устраняют уязвимости

• Владельцы активов со стороны бизнеса. Они больше всех заинтересованы в бесперебойной работе систем. Они дают необходимую информацию и участвуют в выработке мер по устранению

Ключевая мысль: VM - это командная игра трех сторон (ИБ, ИТ, бизнес), а не сольное выступление одного безопасника.

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

Артефакты процесса

Чтобы у всех участников было единое понимание процесса, рекомендуем описывать его тремя документами: workflow, регламентом и карточкой.

Workflow - маршрут процесса. Визуализация всех шагов и участников на каждом этапе: входные данные, выходные результаты, взаимосвязи, используемые инструменты. Это “карта местности”.

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

Карточка - лаконичное представление процесса на одну-две страницы, не больше. Позволяет новому участнику быстро вникнуть в суть. Карточка содержит:

1. Описание - в нескольких словах о процессе и его назначении

2. Владелец - ответственный за VM и его контакты, чтобы было понятно, к кому идти с вопросами

3. Границы - сегменты и сервисы, на которые распространяется процесс

4. Входные параметры - все, что нужно для работы процесса, и данные из смежных процессов

5. Участники - роли и функции, чтобы было ясно, кто за что отвечает

6. Этапы - основные этапы с ключевыми шагами (подробности - в регламенте)

7. Результаты - в чем выражается итог

8. Артефакты - вспомогательные источники: регламент, заявки, отчеты, сканирования

9. Технические решения - инструменты автоматизации, а также метрики и SLA, зафиксированные на старте

Согласование и актуализация

Описание процесса VM должно быть согласовано со всеми заинтересованными сторонами и не конфликтовать с другими процессами. Например, у ИБ есть процесс VM, а у ИТ - смежный процесс управления обновлениями. Они не должны противоречить друг другу.

Живой пример. У одного клиента в регламенте управления уязвимостями было написано, что критические уязвимости устраняются за 30 дней, а в регламенте управления обновлениями у ИТ стоял срок 90 дней. Команды месяцами не могли понять, почему процесс буксует: каждый честно работал по своему документу. А документы противоречили друг другу.

Вывод: согласовывать нужно с самого начала разработки документов. Тогда итоговое согласование станет формальностью - все уже будут согласны.

Не забывайте про актуализацию. Изменился процесс, пересмотрели документы, подошел срок планового пересмотра - значит, пора проанализировать процесс и внести изменения. Кстати, с появлением приказа ФСТЭК № 117 для государственных систем эта дисциплина стала обязательной: регулятор требует устранять уязвимости в жесткие сроки (критические - 24 часа, высокие - 7 дней) и при этом вести документированный, повторяемый процесс [1].

Отдельная больная тема - психология ИТ. Парадигма “лучше не трогать то, что и так работает” до сих пор живуча. Обновления ставят неохотно, особенно на критически значимых системах, где сбой при некорректном обновлении обернется катастрофой. Обычно ИТ ждет от ИБ особого указания на такие обновления. Это нормально - главное, чтобы механизм такого указания был прописан и работал.

Поскольку в процессе участвуют специалисты разного профиля, важнее всего выстроенные отношения и слаженное взаимодействие ИТ и ИБ. Хороший VM рушится не из-за плохого сканера, а из-за того, что две команды не разговаривают друг с другом.

Цифры это подтверждают. По отраслевым исследованиям заметная доля успешных атак приходится на уязвимости, для которых патч был давно доступен: проблема не в незнании, а в том, что устранение не довели до конца [2]. А среди причин, по которым устранение буксует, на первом месте обычно не нехватка инструментов, а две вещи. Первая - неотлаженное взаимодействие между командами. Вторая - так называемый паралич приоритизации, когда уязвимостей в очереди тысячи, а понятного порядка их разбора нет. Почти половина специалистов по безопасной разработке называют именно неумение расставить приоритеты главной причиной растущего бэклога [2]. И то и другое - проблемы организации, а не технологий.

SLA

Самый эффективный процесс устроен так: большинство уязвимостей команда ИТ устраняет в ходе регулярных плановых обновлений, а критически опасные уязвимости (и те, для которых еще нет официального патча) устраняются внепланово по согласованию с ИБ.

Основные параметры, которые нужно учитывать при разработке SLA:

• дата выхода обновлений ОС или прикладного ПО

• время, необходимое команде ИТ на тестирование обновления

• технологические окна для установки

• уровень значимости активов и их принадлежность к целевым или ключевым системам

С учетом этих параметров команды совместно определяют SLA для каждого актива или группы активов. Важно, чтобы условия были выполнимы для ИТ и при этом прозрачны для ИБ.

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

Полезно держать в голове отраслевой ориентир. По данным открытых отчетов, реальное среднее время устранения критических и высоких уязвимостей в индустрии измеряется неделями, а не часами: порядка 40 дней для сетевого оборудования и около 55 дней для приложений [2]. Это не оправдание для медлительности, а трезвое напоминание: между нормативным идеалом в 24 часа и тем, как процесс работает у большинства, лежит пропасть. Задача зрелого VM - системно ее сокращать, а не делать вид, что ее нет.

Если ваша организация подпадает под требования ФСТЭК (госсистемы, объекты КИИ) или Банка России, часть параметров SLA вам уже задана сверху, но устроено это тоньше, чем кажется.

Для госсистем приказ № 117 прямо устанавливает 24 часа на критические уязвимости и 7 дней на высокие - это уже норма нормативного акта, а не рекомендация [1]. А вот сроки для средних и низких уязвимостей приказ отдает на усмотрение оператора: их нужно зафиксировать в собственном регламенте.

Для объектов КИИ ситуация другая. Приказ № 239 (мера АУД.2) обязывает выявлять и устранять уязвимости, но конкретных сроков в самом приказе нет. Цифры берутся из методического “Руководства по организации процесса управления уязвимостями” ФСТЭК: критические - 24 часа, высокие - 7 дней, средние - 4 недели, низкие - 4 месяца [3]. Формально это рекомендация, но при разработке плана защиты КИИ именно эти сроки становятся ориентиром, по которому проверяющие оценивают ваш процесс.

У Банка России (положения по ГОСТ Р 57580) жестких числовых сроков на устранение уязвимостей нет вовсе - требуется “своевременное устранение”, а что считать своевременным, организация определяет сама. На практике многие банки берут за основу те же сроки ФСТЭК.

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

А как у вас?

Кто у вас владелец процесса VM - реальный человек с полномочиями или “на бумаге безопасник, а по факту никто”? И как вы дошли до выполнимого SLA: сразу угадали или переписывали несколько раз, когда реальность не сошлась с планом?

Навигация по серии: ⬅️ Предыдущая: Гл. 5. Не строить, а арендовать · ? Оглавление серии · Следующая: Гл. 7. Нашли уязвимости - что дальше ➡️

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