Регламент управления уязвимостями и патчей: шаблон

Регламент не должен быть толстым. Его задача — чтобы на вопросы «кто проверяет, как часто, за сколько дней закрываем и что делать, если не успели» был один письменный ответ, под которым стоит подпись руководителя и подписи людей, которые обязаны его выполнять. Ниже каркас документа для небольшой компании: что должно быть в каждом разделе, пример формулировок, таблица SLA и порядок доведения до исполнителей. Подгоняйте под свои роли и инструменты, а не копируйте дословно.

Общая политика компании остаётся более высоким документом: как утвердить политику ИБ. Регламент — следующий уровень детализации. Практика, которую он закрепляет, описана в основной статье: управление уязвимостями.

Чем регламент отличается от политики и инструкции

Документ	Отвечает на вопрос	Пример содержания
Политика	Что компания считает обязательным и зачем	«Все системы сканируются на уязвимости, критичные устраняются в сроки»
Регламент	Кто, что, когда и в какие сроки делает	«Внешний периметр сканируется еженедельно, P1 устраняется за 3 дня, исключение утверждает директор»
Инструкция	Как технически выполнить шаг	«Запустить задачу в сканере, выгрузить отчёт, создать заявку»

Если вы объединяете всё в один документ, он получается длинным и никем не читается. Держите регламент на 3–5 страницах, а технические детали выносите в инструкции со ссылками.

Каркас регламента

Ниже структура с примерами формулировок. Текст в квадратных скобках замените своим.

РЕГЛАМЕНТ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ И УСТАНОВКИ ОБНОВЛЕНИЙ
Версия 1.0, утверждён [дата], пересмотр не реже раза в год

1. Цель и область применения
1.1. Регламент определяет порядок выявления, оценки и устранения уязвимостей
     в информационных системах [компании].
1.2. Распространяется на все серверы, рабочие станции, сетевое оборудование,
     внешние сервисы и разрабатываемое программное обеспечение.

2. Роли и ответственность
2.1. Ответственный за ИБ: организует сканирование, оценивает приоритет,
     подтверждает закрытие, ведёт реестр, отчитывается руководству.
2.2. Владелец системы: принимает решения об окнах обслуживания и остаточном риске.
2.3. Администратор: устанавливает обновления, выполняет откат, отчитывается по заявке.
2.4. Руководитель [компании]: утверждает исключения высокого риска и сроки.

3. Источники информации об уязвимостях
3.1. Сканирование (раздел 4).
3.2. Открытые источники: каталог KEV, БДУ ФСТЭК, бюллетени производителей.
     Дежурный по уязвимостям проверяет их каждый рабочий день и ведёт журнал.
3.3. Результаты пентестов, SAST и SCA, сообщения пользователей и исследователей.

4. Сканирование и периодичность
4.1. Внешний периметр: еженедельно и перед публикацией нового сервиса.
4.2. Внутренняя сеть с учётной записью: ежемесячно.
4.3. Конфигурации критичных устройств: ежемесячно; остальных: ежеквартально.
4.4. Результат каждого скана фиксируется в отчётной системе. Если отчёт
     не получен в течение суток после планового запуска, ответственный за ИБ
     выясняет причину и перезапускает скан.

5. Оценка и приоритеты
5.1. Приоритет определяется по матрице (приложение 1) с учётом наличия
     уязвимости в каталоге KEV, вероятности эксплуатации (EPSS),
     доступности из интернета и критичности актива.
5.2. Приоритет может быть повышен или понижен ответственным за ИБ
     с письменным обоснованием в карточке.

6. Сроки устранения (SLA)
6.1. Сроки по приоритетам указаны в приложении 1 и отсчитываются
     от даты обнаружения.
6.2. Эскалация просрочки: приложение 2.

7. Установка обновлений
7.1. Обновления тестируются на стенде и устанавливаются по кольцам
     (тест, пилот, основное, критичные).
7.2. Для срочных уязвимостей (P1) допускается сокращённая выдержка колец.
7.3. Перед установкой на критичные системы готовится план отката.

8. Закрытие и подтверждение
8.1. Заявка закрывается только после повторного скана, подтвердившего
     устранение, или после документированного принятия риска.
8.2. Закрывает ответственный за ИБ; закрытие исполнителем не допускается.

9. Исключения и принятие риска
9.1. Исключение оформляется по форме (приложение 3): причина,
     компенсирующая мера, остаточный риск, срок пересмотра не более 90 дней.
9.2. Исключения P1 и P2 утверждает руководитель [компании].

10. Реестр и отчётность
10.1. Все уязвимости регистрируются в едином реестре с полями:
      узел, тип, критичность, приоритет, статус, срок, ответственный.
10.2. Раз в месяц ответственный за ИБ представляет руководству
      показатели: открытое по приоритетам, просрочка, среднее время закрытия.

11. Ознакомление и пересмотр
11.1. С регламентом под подпись знакомятся все лица из раздела 2.
11.2. Пересмотр: раз в год и после значимых инцидентов.

Обратите внимание на раздел 4.4: контроль завершения скана вписан прямо в регламент. Это тот самый пункт, про который обычно забывают, и который затем нечем подтвердить. Подробнее о настройке: Greenbone в Docker.

Приложение 1: матрица приоритетов и SLA

Приоритет	Условие	Срок
P1	Уязвимость из KEV на системе, доступной из интернета; либо доступна из интернета и EPSS не меньше 0,9	3 дня
P2	Из KEV на внутренней системе; EPSS не меньше 0,5; либо в интернете и CVSS не меньше 9	14 дней
P3	CVSS не меньше 7 или EPSS не меньше 0,1	30 дней
P4	Остальное	В плановом обновлении, не более 90 дней

Цифры подберите под вашу инфраструктуру. Операторы КИИ и государственных систем учитывают методику ФСТЭК; сроки в ней приведены в основной статье. Если ваши сроки строже или мягче, пишите те, которые вы реально способны выполнять: неисполнимый срок хуже длинного, потому что просрочка становится нормой.

Приложение 2, эскалация просрочки, можно оформить одной таблицей: на какой день и кому сообщается (владелец системы, его руководитель, директор). Пример в статье про реестр уязвимостей.

Как довести регламент до людей

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

Проведите короткую встречу (30 минут) с администраторами и владельцами систем: что меняется на практике, кто за что отвечает, где реестр.
Разошлите регламент и соберите подписи в листе ознакомления. Электронная форма допустима, если у вас есть способ зафиксировать, кто и когда прочитал.
Включите регламент в программу вводного инструктажа для новых администраторов: ознакомление с правилами ИБ при приёме.
Хранить версии и даты изменений нужно в одном месте, ссылка должна быть известна всем ролям.

Лист ознакомления:

Регламент управления уязвимостями, версия 1.0 от 01.12
С регламентом ознакомлен, обязанности роли понимаю.

ФИО            | Роль                     | Дата  | Подпись
Иванов И.И.    | Администратор            | 03.12 |
Петров П.П.    | Владелец системы 1С      | 03.12 |
Сидорова С.С.  | Руководитель ИТ-отдела   | 04.12 |

Как убедиться, что регламент соблюдается

Через месяц после ввода сверьте документ с реальностью. Возьмите по одному примеру на каждый раздел и найдите след: расписание скана, отчёт за последний месяц, закрытая заявка с отчётом повторного скана, форма исключения, ежемесячный отчёт руководству. Если следа нет, либо процесс не работает, либо регламент требует невозможного. Исправьте то, что проще: чаще это сам регламент.

Какие артефакты хранить

Что хранить	Что показывает
Утверждённый регламент с версией и датой	Процесс полностью регламентирован
Лист ознакомления с подписями или электронный журнал	Регламент доведён до всех вовлечённых
Приложение с SLA, утверждённое и известное исполнителям	Сроки зафиксированы в зависимости от критичности
Примеры, где процесс шёл по регламенту: заявка, скан, закрытие	Практика соответствует документу

Диагностика

Симптом	Причина и что делать
Регламент утверждён, а скан раз в квартал	Сроки в документе не подкреплены расписанием. Настройте расписание и контроль завершения
Администраторы говорят, что не знали	Нет ознакомления. Проведите встречу и соберите подписи
Все заявки закрыты в срок, но уязвимости остаются	Закрывают исполнители без повторного скана. Закрытие — только ответственный за ИБ
Исключений становится больше нормальных заявок	Сроки не реалистичны или нет ресурсов. Пересмотрите SLA и поднимите вопрос ресурсов на руководство

Где это в модели зрелости

Материал относится к направлению «Управление уязвимостями» (хаб: уязвимости, карта: карта зрелости). На третьем уровне процесс управления уязвимостями и патч-менеджмента регламентирован и доведён до всех работников, вовлечённых в него, а для исполнителей утверждены SLA. Шаблон закрывает оба требования, если дополнить его реальным расписанием и реестром.

Как проверить

Регламент утверждён, в шапке указаны версия и дата пересмотра.
В листе ознакомления подписи всех лиц из раздела о ролях.
Для каждого срока из приложения есть запись реестра, по которой видно, что срок контролируется.
Три последние заявки закрыты по пунктам 8 и 9 регламента, а не по слову администратора.

Источники

NIST SP 800-40 Rev. 4, управление корпоративными исправлениями: csrc.nist.gov.
CIS Control 7: cisecurity.org/controls.
ФСТЭК России, методика оценки уровня критичности уязвимостей (в редакции, действующей на дату чтения): fstec.ru.