Управление уязвимостями без формализованного регламента — это тушение пожаров вслепую. Сканер выдаёт сотни находок, ИТ-служба закрывает то, что проще, а критические бреши остаются открытыми неделями. Регламент управления уязвимостями превращает хаотичное «патчим по возможности» в измеримый процесс с ответственными, сроками и эскалацией.
В этой статье — полная структура документа, RACI-матрица, SLA-таблица, примеры формулировок разделов и чек-лист полноты. Материал рассчитан на CISO и руководителей ИБ, которым нужно подготовить или актуализировать регламент.
Зачем нужен регламент управления уязвимостями
Формализация процесса
Регламент фиксирует правила игры: кто сканирует, кто патчит, за какое время, кого эскалировать при срыве сроков. Без документа процесс существует «в головах» и ломается при смене сотрудников, аудите или инциденте.
Ключевые задачи регламента:
- Повторяемость — процесс работает одинаково вне зависимости от конкретного специалиста.
- Измеримость — определены метрики (MTTR, SLA compliance, покрытие сканирования).
- Подотчётность — каждое действие привязано к роли и срокам.
- Аудитопригодность — документ подтверждает наличие процесса для регулятора и аудиторов.
Требования ФСТЭК и ISO 27001
Руководство ФСТЭК по организации процесса управления уязвимостями прямо требует формализации процедур выявления, оценки и устранения уязвимостей для ГИС, ИСПДн, значимых объектов КИИ и АСУ ТП. В международном контексте ISO 27001:2022, контроль A.8.8 «Management of technical vulnerabilities», обязывает организацию иметь задокументированный процесс.
Регламент закрывает оба требования одним документом.
Что происходит без регламента
- Уязвимости с CVSS 9.0+ остаются открытыми месяцами — нет SLA.
- ИТ и ИБ спорят о приоритетах — нет RACI.
- Аудитор фиксирует несоответствие — нет доказательной базы.
- Инцидент через известную уязвимость — нет эскалации.
Начните с ScanOVAL — бесплатный сканер ФСТЭК для первой проверки. HTML-отчёт загружается в КиберОснова в один клик: SLA рассчитается автоматически, задачи разойдутся по ответственным.
Структура регламента: 10 обязательных разделов
Ниже — шаблон оглавления, который покрывает требования ФСТЭК и ISO 27001. Каждый раздел раскрыт далее.
| № | Раздел | Назначение |
|---|---|---|
| 1 | Общие положения | Цели, область применения, нормативные ссылки |
| 2 | Термины и определения | CVSS, SLA, VM, BDU, компенсирующая мера |
| 3 | Организационная структура и роли | RACI-матрица участников процесса |
| 4 | Классификация активов | Категории критичности для расчёта SLA |
| 5 | Выявление уязвимостей | Источники данных, периодичность сканирования |
| 6 | Оценка и приоритизация | CVSS, контекст актива, наличие эксплойта |
| 7 | SLA устранения | Матрица «критичность уязвимости x критичность актива» |
| 8 | Эскалация и компенсирующие меры | Действия при невозможности патча в срок |
| 9 | Отчётность и метрики | Периодичность, формат, получатели отчётов |
| 10 | Порядок пересмотра | Плановый и внеплановый пересмотр документа |
Нет времени писать регламент с нуля? Управление уязвимостями в КиберОснова включает встроенные SLA-матрицы и RACI-шаблоны, настроенные под приказы ФСТЭК. Загружайте результаты сканирования и работайте — регламент уже "зашит" в процесс.
Ключевые разделы регламента: содержание и примеры
Раздел 3. Роли и RACI-матрица
RACI-матрица определяет, кто за какой этап отвечает. Четыре роли: R (Responsible — исполняет), A (Accountable — отвечает за результат), C (Consulted — консультирует), I (Informed — информируется).
| Этап процесса | CISO | Аналитик ИБ | Администратор ИТ | Владелец системы | Руководство |
|---|---|---|---|---|---|
| Мониторинг БДУ/CVE | A | R | I | I | I |
| Сканирование | A | R | C | I | I |
| Оценка критичности | A | R | C | C | I |
| Приоритизация | R | C | C | C | I |
| Установка патча | I | I | R | A | I |
| Применение комп. мер | A | R | R | C | I |
| Верификация | A | R | C | I | I |
| Отчётность | R | R | I | I | A |
| Эскалация | R | C | I | C | A |
Принцип: ИБ выявляет и приоритизирует, ИТ устраняет, владелец системы принимает риск при отклонении от SLA.
Раздел 5. Процедура сканирования: периодичность и инструменты
Регламент обязан определить не только то, что сканировать, но и как часто, чем и кто инициирует внеплановое сканирование.
Периодичность сканирования зависит от категории актива:
| Категория актива | Плановое сканирование | Внеплановое (триггеры) |
|---|---|---|
| Критичный (КИИ, ГИС 1 кл.) | Еженедельно | При выходе критической уязвимости в БДУ/NVD |
| Высокий (внутренние системы) | Раз в 2 недели | При изменении конфигурации |
| Средний (рабочие станции) | Ежемесячно | По решению CISO |
| Низкий (изолированные стенды) | Ежеквартально | При инциденте |
Источники данных об уязвимостях — обязательные для включения в регламент:
- БДУ ФСТЭК — основной российский реестр уязвимостей. Регламент должен предусматривать мониторинг обновлений БДУ не реже одного раза в сутки.
- NVD (NIST) и CVE — международные базы для продуктов без записи в БДУ.
- Бюллетени вендоров (Microsoft Patch Tuesday, Oracle CPU и т.д.) — при использовании коммерческого ПО.
- CERT-уведомления — рассылки ГосСОПКА и отраслевых CERT.
Инструменты сканирования — в регламенте фиксируется, каким сканером и в каком режиме проводится проверка:
ScanOVAL — бесплатный сканер ФСТЭК/АЛТЭКС-СОФТ для проверки активов на соответствие БДУ ФСТЭК. Подходит для малых инфраструктур и ГИС без крупного бюджета. Сканер формирует HTML-отчёт с перечнем выявленных уязвимостей, который затем импортируется в личный кабинет КиберОснова — так ручной результат сканирования встраивается в автоматизированный процесс управления уязвимостями.
Для средних и крупных инфраструктур используются коммерческие сканеры с API-интеграцией: MaxPatrol VM, RedCheck, XSpider. В регламенте прописывается формат экспорта (XML, CSV, API) и способ загрузки результатов в систему учёта.
Верификация результатов сканирования — отдельный обязательный шаг: не все «находки» сканера являются реальными уязвимостями. Регламент должен предусматривать процедуру ручного подтверждения критических уязвимостей (CVSS ≥ 9.0) до постановки задачи на устранение.
Подробнее о методике расчёта приоритетов и инструментах — в статье Методика управления уязвимостями ФСТЭК. Пошаговое описание пяти этапов VM-цикла с RACI и таблицей SLA — в статье Процесс управления уязвимостями.
Раздел 6. SLA по приказам ФСТЭК: что требует регулятор
Если организация является оператором ГИС, ИСПДн или значимым объектом КИИ, SLA-матрица в регламенте должна соответствовать требованиям ФСТЭК. Установленные дедлайны по приказам:
Приказ №239 ФСТЭК (значимые объекты КИИ):
- Критические уязвимости — 24 часа
- Высокие уязвимости — 168 часов (7 дней)
- Средние уязвимости — 720 часов (30 дней)
Приказ №117 ФСТЭК (ГИС):
- Критические уязвимости — 24 часа
- Высокие уязвимости — 168 часов (7 дней)
Приказ №21 ФСТЭК (ИСПДн):
- Критические уязвимости — 72 часа
- Прочие — 720 часов (30 дней)
Обратите внимание: дедлайны ФСТЭК жёстче, чем типовые корпоративные SLA. Регламент организации не должен их превышать — он может быть строже, но не мягче. Для объектов КИИ реальная матрица должна начинаться от дедлайнов №239, а не от внутренних предпочтений ИТ-службы.
Управление уязвимостями на платформе КиберОснова автоматически контролирует соблюдение SLA по выбранному приказу ФСТЭК — система показывает остаток времени и эскалирует при приближении к дедлайну.
Раздел 7. SLA-матрица устранения
SLA рассчитывается на пересечении двух осей: критичность уязвимости (по CVSS v3.1) и критичность актива (определяется при классификации).
| Критичность уязвимости (CVSS) | Критичный актив | Высокий актив | Средний актив | Низкий актив |
|---|---|---|---|---|
| Критическая (9.0–10.0) | 24 часа | 48 часов | 72 часа | 7 дней |
| Высокая (7.0–8.9) | 168 часов (7 дн.) | 7 дней | 14 дней | 21 день |
| Средняя (4.0–6.9) | 14 дней | 21 день | 30 дней | 60 дней |
| Низкая (0.1–3.9) | 30 дней | 60 дней | 90 дней | Следующее ТО |
Критичный актив — продуктивные серверы, БД с ПДн, КИИ, внешний периметр. Высокий — внутренние бизнес-системы, почтовые серверы. Средний — рабочие станции, тестовые среды с доступом к продуктиву. Низкий — изолированные тестовые среды, лабораторные стенды.
Отсчёт SLA начинается с момента первичной регистрации уязвимости в системе учёта (не с момента публикации в БДУ).
Раздел 8. Эскалация и компенсирующие меры
Не каждую уязвимость можно закрыть патчем в срок. Регламент должен предусматривать два сценария:
Эскалация при срыве SLA:
- При превышении SLA на 25% — уведомление CISO.
- При превышении SLA на 50% — уведомление CTO и владельца системы.
- При превышении SLA на 100% — эскалация на уровень руководства с обязательным принятием риска.
Компенсирующие меры (применяются, когда патч невозможен):
- Сегментация сети — изоляция уязвимого актива на уровне VLAN/firewall.
- Ограничение доступа — минимизация привилегий и отключение неиспользуемых сервисов.
- Усиленный мониторинг — дополнительные правила SIEM на признаки эксплуатации.
- Виртуальный патчинг — правила IPS/WAF, блокирующие вектор эксплуатации.
Компенсирующая мера не отменяет необходимость установки патча — она продлевает допустимый срок устранения на согласованный период. Срок действия компенсирующей меры фиксируется в системе учёта и согласовывается с CISO; для объектов КИИ и ГИС — не более срока, допустимого требованиями применимого приказа ФСТЭК.
Примеры формулировок: как заполнить ключевые разделы регламента
Пример: Раздел 1 — Общие положения
1.1. Цель документа
Настоящий Регламент устанавливает порядок выявления, оценки, приоритизации и устранения уязвимостей в информационной инфраструктуре ООО «Название». Регламент направлен на минимизацию рисков реализации угроз безопасности информации через эксплуатацию известных уязвимостей программного и аппаратного обеспечения.
1.2. Область применения
Регламент распространяется на все информационные системы, серверное и сетевое оборудование, рабочие станции и средства защиты информации, находящиеся в зоне ответственности ООО «Название», включая облачные ресурсы (IaaS/PaaS).
1.3. Нормативные ссылки
- Руководство ФСТЭК по организации процесса управления уязвимостями
- Приказы ФСТЭК №117, №21, №239
- ISO/IEC 27001:2022, контроль A.8.8
- Политика информационной безопасности ООО «Название» от ДД.ММ.ГГГГ
- Регламент управления инцидентами ИБ от ДД.ММ.ГГГГ
Пример: Раздел 3 — Роли и ответственность
3.1. Руководитель направления ИБ (CISO)
Руководит процессом управления уязвимостями в целом. Утверждает приоритеты устранения, принимает решения об эскалации, подписывает отчёты для руководства. Имеет право инициировать внеплановое сканирование при получении информации о критической уязвимости (0-day).
3.2. Аналитик ИБ (VM-оператор)
Проводит регулярное сканирование инфраструктуры, регистрирует уязвимости в системе учёта, выполняет оценку критичности по CVSS v3.1 с учётом контекста актива, формирует задачи на устранение для ИТ-подразделения, контролирует соблюдение SLA и проводит верификацию после устранения.
3.3. Администратор ИТ
Устанавливает обновления безопасности, применяет компенсирующие меры, обеспечивает доступ к системам для сканирования. При невозможности установки патча в срок — инициирует запрос на компенсирующую меру с обоснованием.
Пример: SLA-таблица в теле регламента
7.2. Сроки устранения уязвимостей
Максимально допустимые сроки устранения уязвимостей определяются в соответствии с Таблицей 1 (SLA-матрица). Срок исчисляется в рабочих часах с момента регистрации уязвимости в системе управления задачами.
При невозможности устранения в установленный срок ответственный исполнитель обязан не позднее чем за 4 часа до истечения SLA инициировать процедуру эскалации в соответствии с разделом 8 настоящего Регламента.
Пример: Раздел 9 — Отчётность
9.1. Периодичность и формат отчётов
Отчёт Периодичность Получатель Содержание Операционный дашборд Ежедневно Аналитик ИБ, CISO Открытые уязвимости, просроченные SLA Еженедельный отчёт Пятница, 17:00 CISO, CTO Динамика закрытия, топ-10 рисков Ежемесячный отчёт 5-е число Руководство, аудит MTTR, SLA compliance, покрытие, тренды Квартальный обзор По графику Комитет ИБ Сводный анализ, план улучшений
Связь с другими документами ИБ
Регламент управления уязвимостями не существует в вакууме. Он встраивается в иерархию документов ИБ организации.
Политика информационной безопасности
Политика ИБ — документ верхнего уровня, который устанавливает общие принципы защиты информации. Регламент VM является документом второго уровня и реализует конкретные требования политики в части управления техническими уязвимостями. Политика определяет что делать, регламент — как именно.
Регламент управления инцидентами
При обнаружении признаков эксплуатации уязвимости запускается параллельный процесс — управление инцидентами. Регламент VM должен содержать перекрёстную ссылку на процедуру инцидентов и определять точку перехода: если уязвимость уже эксплуатируется — это инцидент, а не штатная задача на патч.
Управление изменениями
Установка патча — это изменение в продуктивной среде. Регламент VM должен быть согласован с процедурой управления изменениями (Change Management). Для критических уязвимостей целесообразно предусмотреть упрощённый (ускоренный) порядок согласования Emergency Change.
Модель угроз
Результаты управления уязвимостями питают модель угроз: данные о реальных уязвимостях в инфраструктуре уточняют оценку актуальности угроз. И наоборот — модель угроз определяет, какие типы уязвимостей наиболее критичны для конкретной организации.
Документы ИБ — единый реестр
Регламент VM входит в общий реестр документов ИБ организации наряду с политикой ИБ, регламентом инцидентов, положением о классификации информации, планом обеспечения непрерывности и другими нормативными документами. Единый реестр показывает, какие документы просрочены, кем не согласованы и когда требуют пересмотра.
Как автоматизировать исполнение регламента
Регламент на бумаге работает только при постоянном контроле исполнения. На практике контроль SLA, эскалация, формирование отчётов и верификация — задачи для автоматизации, не для ручного мониторинга.
Что даёт SGRC-платформа
SGRC-система (Security Governance, Risk and Compliance) переводит регламент из PDF в рабочий процесс:
- Автоматический импорт уязвимостей — интеграция с БДУ ФСТЭК и сканерами, уязвимости привязываются к активам автоматически.
- SLA-трекинг — система рассчитывает крайний срок устранения по SLA-матрице и показывает оставшееся время в реальном режиме.
- Автоэскалация — при приближении к сроку SLA платформа уведомляет ответственных по цепочке эскалации из регламента.
- Задачи на устранение — задачи на патч создаются автоматически и назначаются на конкретные роли из RACI.
- Отчётность по расписанию — еженедельные и ежемесячные отчёты генерируются автоматически и отправляются получателям из раздела 9 регламента.
- Аудит ИБ — вся история действий фиксируется: когда обнаружена, кем приоритизирована, когда закрыта, кем верифицирована.
КиберОснова: регламент как рабочий процесс
КиберОснова не хранит регламент — она его исполняет:
- Настройка SLA-матрицы — таблица из раздела 7 регламента загружается в платформу и автоматически применяется ко всем новым уязвимостям.
- RACI в ролях платформы — каждая роль из раздела 3 маппится на пользователей системы, задачи назначаются автоматически.
- Документ регламента — хранится в модуле Документы ИБ с контролем версий, сроков актуализации и электронным согласованием.
- Дашборд CISO — показывает ключевые метрики из раздела 9: MTTR, SLA compliance, покрытие сканирования, динамику backlog.
Стартовый сценарий для малых ГИС: если бюджет не позволяет коммерческий сканер, используйте бесплатный ScanOVAL для генерации отчётов по БДУ ФСТЭК, а полученный HTML-файл импортируйте в КиберОснова. Уязвимости автоматически попадают в реестр, SLA рассчитывается по матрице регламента, задачи назначаются ИТ-администратору. Полноценный процесс без лицензий на сканер. Сравнение доступных инструментов и платформ для автоматизации регламента — в обзоре Системы управления уязвимостями.
Хотите увидеть, как КиберОснова автоматизирует исполнение VM-регламента? Запросите демо — покажем на реальных данных.
Чек-лист полноты регламента
Перед утверждением регламента проверьте каждый пункт. Если хотя бы один не закрыт — документ потребует доработки.
Общая часть:
- Указаны цели и область применения документа
- Перечислены нормативные ссылки (ФСТЭК, ISO, внутренние документы)
- Определены термины и сокращения (CVSS, SLA, VM, RACI, БДУ)
- Указана дата вступления в силу и порядок ознакомления
Организация процесса:
- Определены все роли участников процесса
- Составлена RACI-матрица для каждого этапа
- Описана классификация активов по критичности (минимум 3-4 уровня)
- Указана периодичность сканирования для каждой категории активов
SLA и эскалация:
- SLA-матрица «критичность уязвимости x критичность актива» заполнена
- Определён момент начала отсчёта SLA
- Описан порядок эскалации при срыве SLA (3+ уровня)
- Определены допустимые компенсирующие меры и срок их действия
Процедуры:
- Описан порядок выявления (сканеры, ручной мониторинг, БДУ/CVE)
- Описана процедура оценки и приоритизации (CVSS + контекст)
- Описан порядок устранения (патч, компенсирующая мера, принятие риска)
- Описана процедура верификации (повторное сканирование, закрытие тикета)
Отчётность и контроль:
- Определены метрики эффективности (MTTR, SLA compliance, покрытие)
- Указана периодичность и получатели каждого типа отчёта
- Определён порядок планового пересмотра (не реже 1 раза в год)
- Предусмотрен лист регистрации изменений документа
Итоги
Регламент управления уязвимостями — это рабочий документ, а не формальность для аудитора. Он определяет, кто, что, когда и как делает с уязвимостями в вашей инфраструктуре. Используйте структуру из 10 разделов, адаптируйте SLA-матрицу под свою классификацию активов, закрепите RACI для каждого этапа процесса.
Главное: регламент работает только при контроле исполнения. Автоматизируйте SLA-трекинг, эскалацию и отчётность через SGRC-платформу — и документ перестанет быть бумагой в шкафу.
Запросить демо КиберОснова — покажем, как платформа превращает регламент VM в автоматизированный процесс с контролем SLA, RACI и отчётностью для CISO.
