Программа профессиональной переподготовки · День I

Риски ИБ,
безопасность ЗО КИИ,
инциденты

Авторский курс В.А. Пикова, преподавателя НОУ ДПО «УЦБИ "МАСКОМ"». Полный учебный день из пяти лекционных блоков: от принципов риск-менеджмента ИБ до управления компьютерными инцидентами.

5Лекций
7,5Академических часов
103Слайда
май 2026Актуальность нормативки
01 / 103
Расписание · вторник 26.05

Учебный день в одной таблице

Пять лекционных блоков с тремя короткими переходами и обеденным перерывом. Каждый блок — кликабелен, ведёт на свой стартовый слайд.

БлокВремяТемаСлайды
Блок 109:30 — 11:00Основы управления рисками ИБ4 — 28
Переход11:00 — 11:10——
Блок 211:10 — 12:40Эксплуатация защищённых ИС и объектов КИИ29 — 53
Обед12:40 — 13:30——
Блок 313:30 — 15:00Планирование работ по обеспечению ИБ54 — 73
Переход15:00 — 15:10——
Блок 415:10 — 16:40Управление компьютерными инцидентами. Часть 174 — 90
Переход16:40 — 16:50——
Блок 516:50 — 18:20Управление компьютерными инцидентами. Часть 291 — 102
Открытие02 / 103
О курсе · аудитория · навигация

Кому адресован день и как им пользоваться

—Целевая аудитория
Роль 1
Специалист по защите информации
Должностные обязанности по 152-ФЗ, 187-ФЗ, приказам ФСТЭК. Получает чёткие критерии оценки и обработки рисков.
Роль 2
Инженер по ИБ
Эксплуатирует СЗИ, SIEM, ГосСОПКА. Учится связывать меры из приказа 239 с реальным жизненным циклом инцидента.
Роль 3
Аудитор ИБ
Проверяет СУРИБ, планы по ТЗИ, готовность к проверкам ФСТЭК и ФСБ. Получает чек-листы и типовые ошибки.
Роль 4
Руководитель ИБ-функции
Связывает риск-менеджмент с бюджетом, метриками, готовностью к ФЗ-58 / ФЗ-325 / приказу № 117.
Главная мысль курсаРиски, защита значимых объектов КИИ и реагирование на инциденты — это единый цикл управления, а не три отдельные дисциплины. Каждое решение в одной области отзывается во всех остальных.
—Как читать материал
  • В режиме «Слайды» — лекция по слайдам, навигация клавишами или кликами по краям экрана.
  • В режиме «Лонгрид» — самостоятельное изучение и повторение: поиск (Ctrl+F), копирование, печать.
  • В каждом блоке — заголовок, материал, контрольные вопросы.
  • Нормативные документы — в действующих редакциях на май 2026 года.
—Горячие клавиши
  • ← → — предыдущий / следующий слайд
  • Home End — в начало / в конец
  • Esc — обзор всех слайдов сеткой
  • G — переключение режима «слайды / лонгрид»
  • F — полноэкранный режим
  • T — переключение темы
Открытие03 / 103
Блок 1·09:30 — 11:00·25 слайдов
01

Основы управления рисками ИБ

ГОСТ Р ИСО 31000 — 2019, ГОСТ Р ИСО/МЭК 27005 — 2010, NIST SP 800-30. Полный цикл: контекст → оценка → обработка → принятие → коммуникация и мониторинг. Где риск-менеджмент встраивается в СУИБ и как обходить типовые ловушки.

—Цели блока
  • Дать единый язык: риск, риск ИБ, обработка, остаточный риск.
  • Показать процесс целиком, а не отдельные методики.
  • Отделить полезный риск-менеджмент от «оценки для бумаги».
  • Связать СУРИБ, СУИБ (ISO 27001) и инструментальные платформы.
—После блока вы умеете
  • Установить контекст оценки рисков под цели организации.
  • Выбрать качественный, количественный или комбинированный подход.
  • Сформировать план обработки рисков с владельцами и сроками.
  • Защищать остаточный риск перед руководством и регулятором.
Блок 1 · Риск-менеджмент04 / 103
1.1 · Зачем риск-менеджмент в ИБ

Ресурсы конечны — приоритеты обязательны

Обеспечение ИБ — это не «навесить как можно больше СЗИ». Это системный процесс с ограниченными бюджетом, временем и кадрами. Инструмент направления ресурсов туда, где «снижение ущерба / стоимость меры» максимально, — управление рисками ИБ.

1
Ресурсы ограничены
Деньги, время, люди. Закрыть все угрозы одновременно невозможно — нужны критерии приоритизации.
2
Угрозы неравноценны
Вероятность и ущерб различаются на порядки. Без количественной (хотя бы качественной) оценки решения произвольны.
3
Решения обоснованы
Риск-менеджмент даёт обоснование выбора мер для руководства, бюджетного комитета, регулятора, аудитора.
Главный тезисБез оценки рисков любая Политика ИБ — гадание. С оценкой — управляемое решение, которое можно защищать в любой аудитории.
Блок 1 · Риск-менеджмент05 / 103
1.1 · Возможности риск-менеджмента ИБ

Что даёт оценка рисков

  1. Количественная оценка уровня ИБ. Обоснование приемлемых рисков, план мероприятий на организационно-управленческом, технологическом и техническом уровнях.
  2. Экономическое обоснование вложений. Расчёт и обоснование размера вложений в СОИБ. Соотнесение расходов с потенциальным ущербом и вероятностью реализации.
  3. Первоочередные мероприятия по уязвимостям. Закрытие наиболее опасных уязвимостей до того, как они будут эксплуатированы.
  4. Функциональные отношения и зоны ответственности. Кто за что отвечает: служба ИБ, ИТ, кадры, СБ, юристы, финансы; пути эскалации.
  5. Согласованный проект внедрения защиты. Учёт современного уровня и тенденций развития ИТ; согласование со службами и надзорными органами.
  6. Поддержание защиты в актуальном состоянии. Регулярные доработки ОРД, модификация процессов и СЗИ по итогам переоценки.
Блок 1 · Риск-менеджмент06 / 103
1.2 · Нормативная база. Часть 1 — общая методология

Общие стандарты риск-менеджмента

Российская система опирается на серию ГОСТ Р ИСО, идентичных международным стандартам. Это «общая рамка» — не отраслевая.

ДокументСодержаниеДействует с
ГОСТ Р ИСО 31000—2019
Идентичен ISO 31000:2018		«Менеджмент риска. Принципы и руководство». Утверждён приказом Росстандарта от 10.12.2019 № 1379-ст. Заменил редакцию 2010 года.01.03.2020
IEC 31010«Risk management — Risk assessment techniques». Каталог методик оценки риска: матрицы, FMEA, дерево событий, Монте-Карло и др.международный
ГОСТ Р ИСО 19011—2021«Руководящие указания по аудиту систем менеджмента». Используется для проверки риск-процессов и СУИБ.с 2021
ЛогикаГОСТ 31000 даёт принципы и структуру для любой области управления риском. ГОСТ 27005 уже специализирует этот язык под информационную безопасность.
Блок 1 · Риск-менеджмент07 / 103
1.2 · Нормативная база. Часть 2 — риски ИБ

Стандарты по рискам информационной безопасности

ДокументСодержаниеСтатус
ГОСТ Р ИСО/МЭК 27005—2010
Идентичен ISO/IEC 27005:2008		«Менеджмент риска информационной безопасности». Утверждён приказом Росстандарта от 30.11.2010 № 632-ст. Действует с 01.12.2011.2008/2010
ISO/IEC 27001СМИБ — требования. Рамка для системы менеджмента ИБ; Statement of Applicability (SoA) опирается на оценку рисков.международный
ISO/IEC 27002Свод правил по менеджменту ИБ — каталог мер защиты.международный
NIST SP 800-30 Rev. 1«Guide for Conducting Risk Assessments» — рамка NIST RMF. Для справки.для справки
Методдокументы ФСТЭКМодели угроз; Руководство по управлению уязвимостями (17.05.2023); Методики критичности уязвимостей и тестирования обновлений.2021 — 2025
Важная оговоркаРоссия пока не приняла переработанную ISO/IEC 27005:2018/2022. Российский ГОСТ остаётся в редакции 2008/2010; международный стандарт двинулся вперёд.
Блок 1 · Риск-менеджмент08 / 103
1.3 · Термины. Часть 1

Базовый язык риск-менеджмента

Риск
Следствие неопределённости
Влияние неопределённости на достижение целей. Характеризуется парой «событие — последствие» или произведением «вероятность × ущерб».
Риск ИБ
Реализация угрозы через уязвимость
Возможность того, что данная угроза воспользуется уязвимостью актива или группы активов и нанесёт ущерб организации.
Менеджмент риска
Скоординированные действия
Действия по руководству и управлению организацией в области риска. Не «оценка», а «руководство».
Источник риска
Объект или деятельность
Сами или в комбинации с другими обладают возможностью вызывать повышение риска. Не то же самое, что нарушитель.
Событие
Возникновение / изменение условий
Может быть инцидентом, аварией, угрозой. Само по себе ущерб не определяет — нужно последствие.
Последствие
Результат воздействия события
Ранжируется от позитивного до негативного. Первоначальные последствия могут эскалироваться по «принципу домино».
Блок 1 · Риск-менеджмент09 / 103
1.3 · Термины. Часть 2

Оценка и обработка: продвинутый язык

Likelihood
Правдоподобность
Возможность и частота появления события. В ИБ часто используется как «вероятность». На практике — пятибалльная шкала.
Impact
Влияние
Неблагоприятное изменение уровня достижения бизнес-целей. Финансовое, операционное, репутационное, правовое.
Identification
Идентификация риска
Процесс нахождения, составления перечня и описания элементов риска. Активы, угрозы, уязвимости, последствия.
Estimation
Количественная оценка
Присвоение значений вероятности и последствий. Часто — ALE (ожидаемый годовой ущерб) или баллы.
Evaluation
Сравнительная оценка
Сравнение результатов анализа риска с критериями риска для определения приемлемости.
Residual
Остаточный риск
Риск, оставшийся после обработки. Принятие — однозначное решение руководства с фиксацией ответственности.
Блок 1 · Риск-менеджмент10 / 103
1.4 · ГОСТ Р ИСО 31000 — 2019, раздел 4

Восемь принципов менеджмента риска

1
Интегрированность
Менеджмент риска неотделим от деятельности организации. Не «довесок», а её часть.
2
Структурированность и комплексность
Единый подход даёт согласованные и сопоставимые результаты во всех подразделениях.
3
Адаптированность
Структура и процесс настраиваются под внешнюю и внутреннюю среду организации.
4
Вовлечённость
Надлежащее и своевременное участие причастных сторон, в том числе бизнеса и ИТ.
5
Динамичность
Риски возникают, меняются и исчезают. Реакция должна быть своевременной, а не плановой раз в год.
6
Лучшая информация
Базирование на наилучших доступных данных: исторические факты, текущее состояние, прогнозы.
7
Поведенческие факторы
Учёт человеческого фактора и культуры. Они существенно влияют на каждый этап.
8
Непрерывное улучшение
Обучение, накопление опыта, корректировка методик. PDCA на уровне всей структуры.
Блок 1 · Риск-менеджмент11 / 103
1.5 · ГОСТ Р ИСО 31000 — 2019, раздел 5

Структура менеджмента риска — каркас встраивания

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

Лидерство и приверженность 02Адаптацияпод цели и сложность 03Проектированиероли, ресурсы, коммуникации 04Внедрениеплан, процессы, решения 05Оценкаэффективности структуры 06Улучшение и обновление

Цикл проходится итеративно. Старт — с лидерства: высшее руководство выпускает политику, выделяет ресурсы, устанавливает полномочия.

Блок 1 · Риск-менеджмент12 / 103
1.6 · ГОСТ Р ИСО/МЭК 27005 — 2010, раздел 6

Процесс менеджмента риска ИБ — большая картина

01Установление контекстацели, критерии, скоуп,границы, ответственные 02Оценка рискаидентификация + анализ +сравнительная оценка 03Обработка рискаснижение · сохранениеизбежание · передача 04Принятие рискаформальное решениеруководства 05 · СКВОЗНОЙ Коммуникация риска — обмен информацией между владельцами рисков, активов, ЛПР, причастными сторонами 06 · СКВОЗНОЙ Мониторинг и переоценка — среда меняется, реестр стареет за полгода

В фазах СУИБ (PDCA): Plan — контекст, оценка, планирование обработки, принятие; Do — реализация плана; Check — мониторинг и переоценка; Act — улучшение.

Блок 1 · Риск-менеджмент13 / 103
1.7 · Этап 1 · Установление контекста (раздел 7)

До оценки — установить контекст

—Возможные цели этапа
  • Поддержка СУИБ (ISO/IEC 27001).
  • Исполнение НПА и проявление «разумной предосторожности».
  • Подготовка плана ОНРБ / BCM.
  • Подготовка плана реагирования на инциденты.
  • Описание требований ИБ для продукта, услуги, механизма.
—Область применения и границы
  • Какие активы, процессы, подразделения, локации, ИС попадают в скоуп.
  • Где проходят границы — поставщик, ЦОД, облако, контрагент.
  • Кто разрабатывает, кто владельцы рисков; пути эскалации.
—Три обязательных критерия
Критерий А
Оценки рисков
Стратегическая ценность бизнес-информации, критичность активов, законодательные и договорные обязательства, репутационные риски.
Критерий Б
Влияния
Степень ущерба или расходов: классификация актива, нарушение К/Ц/Д, операционная деятельность, потеря ценности бизнеса, ущерб репутации, нарушение НПА.
Критерий В
Принятия риска
Пороги приемлемости. Целевой уровень + допустимое отклонение, соотношение «выгода / риск», разные шкалы для разных классов.
На что обратить вниманиеК нарушению НПА (152-ФЗ, 187-ФЗ, гостайна) применяется нулевая толерантность. Это нужно зафиксировать в критериях принятия до начала оценки — потом не переписать.
Блок 1 · Риск-менеджмент14 / 103
1.8.1 · Этап 2 · Оценка риска — идентификация

Активы → угрозы → меры → уязвимости → последствия

  1. Определение активов. Не только «железо и софт»: информация (БД, файлы, ноу-хау), бизнес-процессы и сервисы, люди (компетенции), репутация и бренд, физическая инфраструктура. У каждого актива — владелец, отвечающий за получение, разработку, поддержку, использование и безопасность.
  2. Определение угроз. Природные, техногенные, человеческие случайные, человеческие умышленные (внутренние, внешние, организованные группы, спецслужбы). Источники: внутренние инциденты, отраслевая статистика, БДУ ФСТЭК, открытые источники, CERT-сообщества.
  3. Существующие меры и средства управления. Что уже работает и насколько, не дублируется ли. Цель — строить от текущего состояния, а не «заново».
  4. Уязвимости. Организационные, технические, физические, человеческие. Источники: сканеры (БДУ ФСТЭК, NVD, отраслевые БД), пентесты, аудиты конфигураций.
  5. Последствия. Финансовые потери, штрафы, простой бизнеса, утечка ПДн (152-ФЗ), нарушение режима гостайны, репутационный ущерб, угроза жизни и здоровью.
Блок 1 · Риск-менеджмент15 / 103
1.8.2 · Этап 2 · Оценка риска — анализ

Три типа анализа и четыре подхода

—Типы анализа
Качественный
Низкий / средний / высокий
Описательные шкалы. Ранние этапы, отсутствие данных, быстрая приоритизация.
Количественный
Численные значения
Вероятность и ущерб числами. Позволяет считать ALE и сравнивать варианты обработки. Требует исторических данных.
Полуколичественный
Числовые шкалы над категориями
Гибрид. Чаще всего применяется на практике.
—Подходы (приложение E ГОСТ 27005)
Базовый
Каталог мер
Типовой набор (ISO 27002, Приказы ФСТЭК № 17/117, № 21, № 239). Быстро, дёшево, без учёта специфики.
Неформальный
Экспертная оценка
Только для малых, некритичных систем. Без формальной методики.
Детальный
Полное моделирование
«Актив → угроза → уязвимость → последствие → вероятность». Дорого, но обосновано для критичной инфраструктуры.
Комбинированный
Высокий уровень + приоритеты
Высокоуровневая оценка всей организации + детальная — приоритетных активов. На практике встречается чаще всех.
Блок 1 · Риск-менеджмент16 / 103
1.8.3 · Этап 2 · Сравнительная оценка

Решения по итогам сравнения с критериями

Сравниваем уровень риска (выход анализа) с критериями риска (выход контекста). Возможные решения:

1
Не предпринимать действий
Риск ниже порога приемлемости.
2
Рассмотреть обработку
Перейти к этапу обработки — выбор варианта.
3
Доп. анализ
Информации недостаточно — собрать данные.
4
Поддерживать меры
Существующие меры работают, ничего не менять.
5
Пересмотреть цели
Риск неприемлем, обработать нельзя — менять цели.
ДокументированиеРезультаты сравнительной оценки документируются и доводятся до причастных сторон. Без документа решение «не считается».
Блок 1 · Риск-менеджмент17 / 103
1.9 · Этап 3 · Обработка риска ИБ

Четыре классических варианта обработки

ВариантЧто делаемКогда применять
Снижение
risk reduction		Внедряем дополнительные меры защиты, уменьшающие вероятность и/или последствия.Основной способ. Риск выше порога, есть экономически разумная мера.
Сохранение
risk retention		Осознанно принимаем риск как есть, фиксируем решение.Риск ниже критериев принятия; стоимость обработки выше ожидаемого ущерба.
Избежание
risk avoidance		Прекращаем или не начинаем рискованную деятельность.Риск принципиально неприемлем — например, обработка ПДн без оснований по 152-ФЗ.
Передача
risk transfer		Передаём риск третьей стороне: страхование, аутсорсинг, договорные SLA.Можно покрыть финансовую составляющую. Репутация и юридическая ответственность остаются.
Главное про передачуАутсорсинг и страхование переносят финансовый ущерб, но не репутационный и не юридическую ответственность по 152-ФЗ, 187-ФЗ, гостайне. Оператор ПДн отвечает перед субъектом ПДн, даже если обработку ведёт процессор.

Дополнительные варианты ГОСТ 31000: принятие или увеличение риска для использования благоприятной возможности; устранение источника риска; изменение вероятности; изменение последствий.

Блок 1 · Риск-менеджмент18 / 103
1.9 · План обработки риска — состав

Восемь обязательных элементов плана

1
Обоснование выбора варианта
Почему именно снижение / сохранение / избежание / передача. Ожидаемые выгоды.
2
Ответственные
За утверждение и за реализацию. Привязка к должностям, не к ФИО.
3
Предлагаемые действия
Конкретные меры, технические и организационные.
4
Требуемые ресурсы
Бюджет, кадры, время, инфраструктура. Включая непредвиденные.
5
Показатели эффективности
Как поймём, что мера сработала. KPI и KRI.
6
Ограничения
Технические, организационные, бюджетные, регуляторные.
7
Отчётность и мониторинг
Кто, кому, в каком виде, с какой периодичностью.
8
Сроки
Реализации и завершения. Привязка к бюджетному циклу обязательна.
Остаточный рискПосле обработки остаётся остаточный риск. Он документируется и принимается руководством. Без подписи под остаточным риском процесс не закрыт.
Блок 1 · Риск-менеджмент19 / 103
1.10 · Этапы 4 — 6

Принятие, коммуникация, мониторинг

Этап 4
Принятие риска
Формальное решение уполномоченного лица — как правило, владелец актива или представитель руководства. Без подписи под остаточным риском процесс не закрыт.
Этап 5 · Сквозной
Коммуникация риска
Обмен информацией о риске между владельцем риска, владельцем актива, лицом, принимающим решения, и причастными сторонами. Обучение, информирование, отчётность.
Этап 6 · Сквозной
Мониторинг и переоценка
Постоянная деятельность: среда меняется, появляются новые угрозы и уязвимости, меняются бизнес-цели и законодательство.
—Переоценка обязательна
  • при существенном изменении инфраструктуры или бизнес-процессов;
  • после крупного инцидента (своего или отраслевого);
  • при изменении нормативки (например, выход ФЗ-58, ФЗ-325, приказа № 117);
  • по плану — например, ежегодно.
Без коммуникациисотрудники не понимают, зачем меры — и обходят их. Самая хорошая оценка рисков, не дошедшая до владельцев активов, бесполезна.
Блок 1 · Риск-менеджмент20 / 103
1.11 · Документальное обеспечение СУРИБ

Минимальный комплект документов

  • Политика управления рисками ИБ — высокоуровневый документ, утверждаемый руководством.
  • Методика оценки и обработки рисков ИБ — детальный регламент: шкалы, формулы, ответственные.
  • Реестр активов — с владельцами, ценностью, классификацией.
  • Реестр угроз — отраслевой и внутренний, с источниками.
  • Реестр уязвимостей — с приоритизацией по методике ФСТЭК от 30.06.2025.
  • Карта рисков — матрица «вероятность × ущерб», с цветовой кодировкой.
  • План обработки рисков — с действиями, ответственными, сроками.
  • Протоколы принятия остаточных рисков — подписанные руководством.
  • Отчёты по мониторингу — периодические, с трендами.
Блок 1 · Риск-менеджмент21 / 103
1.12 · Инструментальные средства

Платформы риск-менеджмента

—Российские
«Гриф» Digital Security
Оценка рисков ИБ. Поддерживает количественный и качественный подходы; интегрируется со сканерами уязвимостей.
«АванГард» АО «НТЦ Атлас»
Анализ защищённости и рисков. Применяется для систем с повышенными требованиями к безопасности.
R-Vision SGRC, Security Vision SGRC
SGRC-платформы с модулями риск-менеджмента, инвентаризацией активов, регистрацией инцидентов, отчётностью.
Сканеры VM
MaxPatrol VM, ScanOVAL, RedCheck — для шага «сбор сведений об уязвимостях» в процессе VM.
—Международные (для справки)
RSA Archer GRC
Доступность под санкциями ограничена; используется в зарубежных контурах.
ServiceNow GRC
Интеграция с ITSM-платформой ServiceNow.
IBM OpenPages
Корпоративная GRC-платформа.
Для отдельных шагов: системы инвентаризации активов, BCM-платформы, тикет-системы.
Блок 1 · Риск-менеджмент22 / 103
1.13 · Связь с СУИБ (ISO/IEC 27001, ISO/IEC 27002)

Риск-менеджмент — фундамент СУИБ

PLAN · ПЛАНИРОВАНИЕУстановление контекстаОценка рискаПланирование обработкиПринятие риска DO · ОСУЩЕСТВЛЕНИЕРеализация планаобработки рисковМеры из SoA — внедрены. CHECK · ПРОВЕРКАМониторинги переоценка рискаАудит СУИБ — ISO 19011. ACT · УЛУЧШЕНИЕКорректировкипо итогам инцидентови переоценки
  • Решения о выборе мер (Statement of Applicability, SoA) принимаются на основе оценки риска.
  • Цели ИБ, KPI и KRI выбираются из приоритетных рисков.
  • Бюджет на ИБ обосновывается через расчётный ущерб.
  • Аудит СУИБ (ISO 19011) включает в т.ч. аудит риск-процессов.
Блок 1 · Риск-менеджмент23 / 103
1.14 · СУРИБ — система управления рисками ИБ

Три уровня структуры и четыре режима работы

СУРИБ — набор элементов системы управления организации в отношении средств управления рисками ИБ на всех уровнях. Часть общей СУИБ. По материалам учебника Милославской, Сенаторова, Толстого (Горячая линия–Телеком, 2014).

—Три составляющие СУРИБ
1
Формализованные процессы
От анализа и планирования до проверки и совершенствования. PDCA на уровне всей СУРИБ.
2
Документальное обеспечение
Политика, методология оценки, план обработки, SoA, реестр рисков, протоколы принятия остаточных рисков.
3
Кадры и оргструктура
Квалифицированные специалисты и трёхуровневая организационная структура.
—Три уровня структуры
УровеньКто и что делает
ВерхнийКоллегиальный орган (риск-комитет, инвестиционный комитет). Принимает решения по конкретным рискам ИБ, утверждает процедуры передачи полномочий.
СреднийСпециальные подразделения контроля. Контролируют исполнение установленных процедур остальными подразделениями.
НижнийПодразделения-исполнители. Совершают действия по управлению рисками в рамках повседневной деятельности.
—Четыре режима работы
Режим A
Обычный
По умолчанию в нормальных условиях ведения бизнеса.
Режим B
Контроля
К отдельному подразделению при сигналах о концентрации рисков ИБ.
Режим C
Чрезвычайный
Ко всей организации при превышении допустимого уровня концентрации рисков.
Режим D
Отладки
Испытание новых продуктов, процедур, элементов СУРИБ; по решению руководства.
Ключевые ролиРиск-менеджер — владелец процесса (при отсутствии должности — CISO). Эксперт по оценке — практик, владеющий бизнесом, ИТ, СЗИ, методом, инструментами. Владельцы активов и руководители подразделений участвуют в оценке. Высшее руководство утверждает план обработки и принимает остаточный риск.
Блок 1 · Риск-менеджмент24 / 103
1.15 · Три подхода в зависимости от критичности систем

Один процесс, три глубины проработки

Поскольку риски ИБ не во всех организациях рассматриваются как одни из основных, выделяются три подхода. На практике в одной организации применяется комбинированный подход: высокоуровневая оценка по всей инфраструктуре + детальный анализ для критичных систем.

Подход 1
Некритичные (вспомогательные) системы
Базовый подход из ГОСТ 27005: применяются стандартные требования по ОИБ из законодательства, стандартов, лучших практик. Типовой набор мер из каталога.
Подход 2
Критичные системы
Особое внимание системам с наибольшими рисками. Требуется высокоуровневая оценка рисков с неформальными качественными подходами.
Подход 3
Особо критичные системы
Необходима детальная оценка рисков для всех активов с количественной (или комбинированной) шкалой. ЗОКИИ, гостайна, ключевые финансовые системы.
Главный принципГлубина проработки риска должна соответствовать критичности системы. Детальная количественная оценка для печатной техники в АХО — пустая трата ресурсов. Базовый подход для ЗОКИИ — нарушение НПА.
Блок 1 · Риск-менеджмент25 / 103
1.16 · NIST SP 800-30

Девять стадий оценки + семь шагов снижения

NIST SP 800-30 «Risk Management Guide for Information Technology Systems» — ключевой международный методический ориентир. Учебник Милославской подробно цитирует эту схему.

—9 стадий оценки рисков ИБ
№СтадияВыход
1Описание системыГраницы, функции, критичные элементы
2Идентификация угрозПеречень классов угроз
3Идентификация уязвимостейСписок потенциальных уязвимостей
4Анализ системы управленияМодель нарушителя, оценка уязвимостей
5Оценка параметров угрозВозможности реализации, диапазон воздействий
6Анализ последствийСтепень последствий, критичные данные
7Определение рисковРанжированный список
8Выработка рекомендацийРекомендации по управлению
9Разработка отчётностиОтчётные документы
—7 стадий снижения рисков
  1. Приоритизация действий. Список ранжированных действий.
  2. Оценивание элементов управления. Технических, управленческих, операционных.
  3. Cost-benefit анализ. С учётом всех ассоциированных затрат.
  4. Выбор элементов управления. Реализуемых на практике.
  5. Распределение ответственности. Кто внедряет, кто контролирует.
  6. Разработка плана реализации защитных мер.
  7. Внедрение выбранных элементов управления рисками ИБ.
Блок 1 · Риск-менеджмент26 / 103
1.17 — 1.18 · OCTAVE и РС БР ИББС-2.2-2009

Метод сам-себе-аудит и банковская методика

1.17 · CMU CERT, США
OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation. Особенность: оценка проводится самой организацией через серию внутренних семинаров (workshops). Снижает зависимость от внешних экспертов.

Три этапа:

  1. Разработка профилей угроз ИБ (инвентаризация, ценность активов, требования НПА, угрозы и их вероятность).
  2. Технический анализ уязвимостей в отношении угроз.
  3. Оценка и обработка рисков ИБ. Риск = усреднённая величина годовых потерь (ALE).

Варианты: OCTAVE-S (малые), OCTAVE Allegro (упрощённый).

1.18 · Банк России
РС БР ИББС-2.2-2009

Стандарт СТО БР ИББС-1.0 и рекомендация РС БР ИББС-2.2-2009. Активы рассматриваются вместе с материальными объектами среды (хранение, передача, обработка, уничтожение).

Риск ИБ = СВР × СТП СВР — степень возможности реализации СТП — степень тяжести последствий

Качественная шкала СВР: Нереализуемая · Минимальная · Средняя · Высокая · Критическая.

Качественная шкала СТП: Минимальная · Средняя · Высокая · Критическая.

Сопоставление СВР × СТП даёт оценку «Допустимый / Недопустимый».

—РС БР ИББС-2.2-2009 · количественная шкала (в денежной форме)
СВР (вероятность)Значение
Нереализуемая0%
Минимальная1 — 20%
Средняя21 — 50%
Высокая51 — 100%
Критическая100%
СТП (% от капитала)Значение
Минимальнаядо 0,5%
Средняя0,5 — 1,5%
Высокая1,5 — 3%
Критическая> 3%

Количественный риск = СВРкол × СТПкол. Суммарная оценка = сумма по всем рискам. Размер резерва на возможные потери ≈ суммарной количественной оценке.

Блок 1 · Риск-менеджмент27 / 103
1.20 — 1.22 · Завершение блока 1

Методы идентификации, типовые ошибки, контрольные вопросы

1.20Четыре метода идентификации рисков
1
Исторический анализ
Сравнение текущей ситуации с прошлыми анализами. Прошлые проблемы часто остаются рисками.
2
Аналитический метод
Моделирование, «причина-результат», таблицы истинности, FMEA.
3
Совещания (workshops)
Целевые встречи. Базовый формат метода OCTAVE.
4
Индивидуальные интервью
С руководством, сотрудниками, заинтересованными лицами.

Каждый выявленный риск ИБ документируется: суть, причины, последствия.

1.21Восемь типовых ошибок
  • «Для бумаги» — без связи с реальными решениями.
  • «Красное всё» — критерии приёмки занижены.
  • Риск без владельца — некому принимать решение.
  • Третьи стороны не учтены — поставщики, ЦОД, облака.
  • Однократная оценка — без переоценки реестр стареет за полгода.
  • «Передача = безопасность» — репутация и юр. ответственность остаются.
  • Нет коммуникации — оценка лежит у CISO, владельцы активов не знают.
  • Разрыв с инцидент-менеджментом — уроки не возвращаются в реестр.
1.22Контрольные вопросы блока 1
  1. Разница между «риском» по ГОСТ 31000 и «риском ИБ» по ГОСТ 27005?
  2. 8 принципов менеджмента риска по ГОСТ 31000—2019.
  3. Этапы процесса риск-менеджмента по ГОСТ 27005—2010.
  4. 4 классических варианта обработки риска ИБ.
  5. «Владелец актива» и «владелец риска» — одно лицо?
  6. Остаточный риск — кто принимает?
  7. Три критерия в установлении контекста.
  8. Когда применяется качественная оценка, а когда количественная?
  1. Три составляющие СУРИБ.
  2. Три уровня структуры и четыре режима СУРИБ.
  3. Кто такой риск-менеджер и его задачи.
  4. 9 стадий оценки рисков по NIST SP 800-30.
  5. Метод OCTAVE и три его этапа.
  6. Расчёт риска ИБ по РС БР ИББС-2.2-2009; шкалы СВР и СТП.
  7. Три подхода в зависимости от критичности систем.
  8. 4 метода идентификации рисков.
Блок 1 · Риск-менеджмент28 / 103
Блок 2·11:10 — 12:40·25 слайдов
02

Эксплуатация защищённых ИС и объектов КИИ

187-ФЗ в действующей редакции с учётом ФЗ-58 и ФЗ-325. Категорирование, приказы ФСТЭК № 235 и № 239, технологическая независимость, доверенные ПАК. Всё в фокусе — реальная эксплуатация значимого объекта, а не «однажды аттестовали и забыли».

—Цели блока
  • Дать рабочее понятие КИИ, объекта КИИ, ЗОКИИ — после ФЗ-58 и ФЗ-325.
  • Показать карту действующей нормативки по состоянию на май 2026.
  • Раскрыть категорирование как процесс с этапами и решениями.
  • Связать требования № 235 и № 239 с реальными процессами эксплуатации.
—После блока вы умеете
  • Определить субъекта КИИ и квалифицировать объект КИИ.
  • Адаптировать базовый набор мер приказа № 239 под угрозы и условия.
  • Готовиться к плановой / внеплановой проверке ФСТЭК и ФСБ.
  • Планировать переход на доверенные ПАК.
Блок 2 · КИИ29 / 103
2.1 · Понятие защищённой ИС

Что делает информационную систему «защищённой»

Защищённой ИС называют систему, в которой реализован комплекс организационных и технических мер защиты в соответствии с её классом защищённости и категорией обрабатываемой информации.

Контекст 1
ГИС
Государственные информационные системы. Приказ ФСТЭК № 17 до 01.03.2026, затем приказ № 117.
Контекст 2
ИСПДн
Информационные системы персональных данных. 152-ФЗ, приказ ФСТЭК № 21.
Контекст 3
ЗОКИИ
Значимые объекты КИИ. 187-ФЗ, приказы ФСТЭК № 235 (системы безопасности) и № 239 (меры).
Контекст 4
АС по гостайне
АС обработки сведений, составляющих государственную тайну. Отдельная регуляторная база.
Курс охватываетГИС/ИСПДн/ЗОКИИ. Гостайна — за рамками. Меняется и общее требование: «однажды аттестовали — и забыли» уходит. На смену — непрерывный мониторинг и реагирование как часть эксплуатации.
Блок 2 · КИИ30 / 103
2.1 · Базовая терминология КИИ

КИИ, объект, субъект, ЗОКИИ

КИИ
Совокупность объектов КИИ и сетей электросвязи, используемых для организации взаимодействия таких объектов.
Объект КИИ
ИС, ИТКС или АСУ, функционирующая в одной из 14 сфер КИИ (см. слайд 32).
Субъект КИИ с 01.09.2025
Юридическое лицо (после ФЗ-58 ИП исключены), которому на законном основании принадлежат или у которого находятся объекты КИИ. С 01.03.2026 (ФЗ-325) — только российские ЮЛ под контролем граждан РФ / органов власти / муниципалитетов.
Значимый объект КИИ (ЗОКИИ)
Объект КИИ, которому присвоена одна из категорий значимости — 1, 2 или 3. Базовый набор требований и контроль регулятора по приказам ФСТЭК № 235 и № 239.
ТонкостьОбъект без присвоенной категории — не ЗОКИИ, но остаётся объектом КИИ и попадает в общую систему ГосСОПКА (информирование о компьютерных инцидентах).
Блок 2 · КИИ31 / 103
2.2 · 187-ФЗ, статья 2

Четырнадцать сфер функционирования КИИ

После изменений 2025 года перечень детализируется подзаконными актами Правительства РФ — отраслевые особенности категорирования вводятся министерствами.

1
Здравоохранение
2
Наука
3
Транспорт
4
Связь
5
Энергетика
6
Банковская и финансовая сфера
7
ТЭК
8
Атомная энергия
9
Оборонная промышленность
10
Ракетно-космическая промышленность
11
Горнодобывающая промышленность
12
Металлургическая промышленность
13
Химическая промышленность
14
Госрегистрация прав на недвижимость
Блок 2 · КИИ32 / 103
2.3.1 · Нормативная база КИИ — Федеральное законодательство

Федеральные законы

ДокументО чёмДействующая редакция
187-ФЗ
26.07.2017		«О безопасности критической информационной инфраструктуры Российской Федерации» — базовый закон.С учётом 312-ФЗ (2023), 58-ФЗ (07.04.2025), 325-ФЗ (31.07.2025)
193-ФЗ
26.07.2017		Пакетные изменения в смежное законодательство.—
194-ФЗ
26.07.2017		Изменения в УК РФ и УПК РФ. Введена ст. 274.1 УК — атаки на КИИ.—
58-ФЗ
07.04.2025		ИП исключены из субъектов КИИ. Полномочия Правительства по отраслевым перечням. Требования к ПО.с 01.09.2025
325-ФЗ
31.07.2025		Субъект КИИ — только российское ЮЛ под контролем РФ. Перечень доверенного ПО Минцифры.с 01.03.2026
Блок 2 · КИИ33 / 103
2.3.2 · Нормативная база КИИ — Указы Президента

Указы Президента Российской Федерации

УказО чём
УП № 31с
15.01.2013		Создание ГосСОПКА.
УП № 620
22.12.2017		Совершенствование ГосСОПКА.
УП № 569
25.11.2017		Изменения в Положение о ФСТЭК.
УП № 166
30.03.2022		«О мерах по обеспечению технологической независимости и безопасности КИИ». С изм. УП № 887 (2023) и УП № 214 (07.04.2025).
УП № 250
01.05.2022		«О дополнительных мерах по обеспечению ИБ». С изм. УП № 500 (13.06.2024). Назначение зам. руководителя по ИБ.
УП № 203
14.04.2022		Межведомственная комиссия Совета Безопасности по технологическому суверенитету в сфере КИИ.
Блок 2 · КИИ34 / 103
2.3.3 · Нормативная база КИИ — Постановления Правительства

Постановления Правительства Российской Федерации

ППО чём
ПП № 127
08.02.2018		«Правила категорирования объектов КИИ». С изм. ПП № 452, 2431, 1463, 2360, № 1281 (19.09.2024).
ПП № 162
17.02.2018		Правила государственного контроля за обеспечением безопасности ЗОКИИ.
ПП № 743
08.06.2019		Правила использования ресурсов ЕСЭ для безопасности ЗОКИИ.
ПП № 402
13.04.2026		«Отраслевые особенности категорирования объектов КИИ в сфере связи» — первый отраслевой подзаконный акт ФЗ-58. Расчётный метод + моделирование атак; показатель — количество абонентов. с 01.09.2026
ПП № 1478
22.08.2022		Требования к ПО (в т.ч. в составе ПАК) на ЗОКИИ. С изм. ПП № 1716 (17.10.2023).
ПП № 1912
14.11.2023		Порядок перехода субъектов КИИ на доверенные ПАК на ЗОКИИ.
ПП № 1272
15.07.2022		Типовое положение о заместителе руководителя по ИБ.
ПП № 1636
17.09.2022		Субсидии на создание отраслевого центра компетенций по ИБ в промышленности.
Блок 2 · КИИ35 / 103
2.3.4 · Нормативная база КИИ — Приказы ФСТЭК

Приказы ФСТЭК

ПриказО чём
№ 227
06.12.2017		Порядок ведения реестра ЗОКИИ. С изм. № 26 (2022), № 177 (2023), № 254 (17.07.2025).
№ 235
21.12.2017		Требования к созданию систем безопасности ЗОКИИ. С изм. № 64 (2019), № 69 (2023).
№ 236
22.12.2017		Форма направления сведений о категорировании. С изм. № 59 (2019), № 247 (11.07.2025).
№ 239
25.12.2017		Требования по обеспечению безопасности ЗОКИИ. С изм. № 138, 60, 35, № 159 (28.08.2024).
№ 229
11.12.2017		Форма акта проверки.
№ 75
28.05.2020		Согласование подключения ЗОКИИ к сетям общего пользования.
№ 77
18.04.2021		Порядок аттестации объектов информатизации.
№ 135
16.07.2019		Перечень НПА для целей государственного контроля.
№ 117
11.04.2025		Требования о защите информации в ГИС, иных ИС госорганов, ГУП и госучреждений. с 01.03.2026, заменит № 17
№ 163 и № 164
12.05.2025		Лицензионный контроль ТЗКИ и разработки/производства СЗКИ.
Проект изм. № 235 и № 239
07.04.2026		Вводятся показатели Кзи (защищённость ЗОКИИ, оценка ≥1 раз в 6 мес.) и Пзи (зрелость мер, ≥1 раз в 2 года). При несоответствии — уведомление руководителя в 3 дня, отчёт во ФСТЭК — 5 рабочих дней. планируется с 01.09.2026
Блок 2 · КИИ36 / 103
2.3.5 · Нормативная база КИИ — Приказы ФСБ

Приказы ФСБ

ПриказО чём
№ 366
24.07.2018		НКЦКИ — Национальный координационный центр по компьютерным инцидентам.
№ 367
24.07.2018		Перечень информации, представляемой в ГосСОПКА, и порядок представления.
№ 368
24.07.2018		Порядок обмена информацией о компьютерных инцидентах.
№ 196
06.05.2019		Требования к средствам обнаружения, предупреждения и ликвидации последствий компьютерных атак.
№ 281
19.06.2019		Порядок установки и эксплуатации средств обнаружения/предупреждения/ликвидации КА.
№ 282
19.06.2019		Порядок информирования ФСБ о компьютерных инцидентах в отношении ЗОКИИ. С изм. № 348 (07.07.2022).
№ 213
11.05.2023		Мониторинг защищённости ИР ФОИВ, ВИОГВ, госфондов, госкорпораций, стратегических предприятий и субъектов КИИ.
№ 543
01.11.2022		Переходный период по Указу № 250. С изм. № 282 (21.07.2025).
Блок 2 · КИИ37 / 103
2.3.6 · ГОСТы по КИИ и компьютерным инцидентам

ГОСТы и ПНСТ

—ГОСТы
  • ГОСТ Р 59548—2022 — Регистрация событий безопасности. Требования к регистрируемой информации.
  • ГОСТ Р 59709—2022 — Управление компьютерными инцидентами. Термины и определения.
  • ГОСТ Р 59710—2022 — Управление компьютерными инцидентами. Общие положения.
  • ГОСТ Р 59711—2022 — Управление компьютерными инцидентами. Организация деятельности.
  • ГОСТ Р 59712—2022 — Управление компьютерными инцидентами. Руководство по реагированию.
  • ГОСТ Р 70732—2023 — Функциональная и информационная безопасность ПО АСУ ТП железнодорожного транспорта.
—ПНСТ (предварительные нац. стандарты)
  • ПНСТ 905—2023 — КИИ. Доверенные ПАК. Термины и определения.
  • ПНСТ 911—2024 — КИИ. Доверенные интегральные микросхемы и электронные модули.
  • ПНСТ 1007—2025 — КИИ. ПАК. Классификация по назначению.
  • ПНСТ 1009—2025 — КИИ. ПО для доверенных ПАК.
Блок 2 · КИИ38 / 103
2.3.7 · Методические документы ФСТЭК

Методические документы — фактический инструментарий

  • Методика оценки уровня критичности уязвимостей ПО/ПАК — от 30.06.2025. Заменила версию от 28.10.2022. Расширен скоуп (+ГУП/госучреждения), новые показатели Iat и Iimp.
  • Методика тестирования обновлений безопасности — от 28.10.2022. Безопасное развёртывание обновлений на ЗОКИИ и ГИС.
  • Методика оценки показателя состояния защиты информации и безопасности объектов КИИ РФ — от 02.05.2024.
  • Руководство по организации процесса управления уязвимостями — от 17.05.2023.
  • Рекомендации по подготовке планов мероприятий при уровнях опасности целевых атак — от 09.08.2021.
  • Рекомендации по разработке Плана реагирования на компьютерные инциденты на ЗОКИИ.
  • Методический документ ФСТЭК от 12.04.2026 — методические рекомендации по категорированию объектов КИИ в сфере связи (приложение к ПП-402). с 01.09.2026
Блок 2 · КИИ39 / 103
2.9 · ФЗ-58 от 07.04.2025

Изменения с 01 сентября 2025 года

Федеральный закон от 07.04.2025 № 58-ФЗ внёс системные изменения в 187-ФЗ. Главное:

1
ИП — больше не субъект КИИ
Из числа субъектов КИИ исключаются индивидуальные предприниматели. Это касается всех 14 сфер.
2
Отраслевые перечни
Правительство уполномочено утверждать перечни типовых отраслевых объектов КИИ и особенности категорирования по сферам.
3
Требования к ПО
Закреплены требования к применяемому ПО, в т.ч. переход на ПО из реестра российских программ.
Что делатьСубъектам, у которых были оформлены ИП-схемы, — реструктурировать. Тем, кто ждал отраслевых типовых перечней, — отслеживать выход подзаконных актов по своей сфере.
Блок 2 · КИИ40 / 103
2.9 · ФЗ-325 от 31.07.2025

Изменения с 01 марта 2026 года

Федеральный закон от 31.07.2025 № 325-ФЗ продолжает курс на технологический суверенитет.

Главное
Субъект КИИ — только российское ЮЛ
Субъектами КИИ могут быть только российские юридические лица, находящиеся под контролем граждан РФ, органов государственной власти или муниципальных образований.
Реестр Минцифры
Перечень доверенного ПО
Минцифры формирует и ведёт перечень российских программ для ЭВМ и БД, разработанных и используемых для собственных нужд российскими ЮЛ. Использование такого ПО приравнено к выполнению требования об использовании ПО из единого реестра российских программ.
На что обратить вниманиеИностранным контролем «по факту» (даже через цепочку владения) субъект КИИ быть не может. Это потребует у ряда холдингов реструктуризации корпоративной собственности к 01.03.2026.
Блок 2 · КИИ41 / 103
2.4 · ПП № 127 — категорирование объектов КИИ

Восемь этапов категорирования

1
Создание комиссии
Приказом руководителя субъекта КИИ.
2
Перечень объектов
Формирование перечня объектов КИИ, подлежащих категорированию.
3
Направление перечня
Во ФСТЭК. Уточнения — серия инфосообщений 2018–2025 гг.
4
Сбор сведений
Характеристики, состав, технологические процессы, угрозы, нарушители.
5
Оценка значимости
По 5 группам критериев. Определение категории.
6
Акт категорирования
С обоснованием категории.
7
Сведения во ФСТЭК
Приказ № 236 + № 247 от 11.07.2025.
8
Реестр ЗОКИИ
Внесение в реестр (приказ № 227).
ДлительностьПолный цикл категорирования у крупного субъекта КИИ — 6 — 12 месяцев. Этап 4 (сбор сведений) обычно самый трудоёмкий.
Блок 2 · КИИ42 / 103
2.4 · ПП № 127 — критерии значимости

Пять групп показателей значимости

Группа 1
Социальная
Вред жизни и здоровью, прекращение объектов жизнеобеспечения, транспорта, связи, нарушение госуслуг.
Группа 2
Политическая
Нарушение функционирования госорганов.
Группа 3
Экономическая
Прямой и косвенный ущерб бюджету и субъектам КИИ.
Группа 4
Экологическая
Вред окружающей среде.
Группа 5
Оборона и безопасность
Значимость для обороны страны, безопасности и правопорядка.

Каждая группа имеет числовые пороги в приложении к ПП № 127. Категория объекта определяется по наивысшему из достигнутых показателей значимости.

Блок 2 · КИИ43 / 103
2.4 · Категории значимости

Три категории, три уровня требований

Высшая
Категория 1
Системы национального значения. Наиболее жёсткие требования по приказу № 239: расширенный базовый набор, обязательные средства ГосСОПКА, кратчайшие сроки информирования.
Средняя
Категория 2
Существенная значимость для отрасли / региона. Базовый набор мер, регулярное взаимодействие с НКЦКИ.
Низшая
Категория 3
Менее критичные ЗОКИИ. Сокращённый базовый набор. По-прежнему — система безопасности по приказу № 235.
Объект без категорииНе является ЗОКИИ, но остаётся объектом КИИ. Информирование о компьютерных инцидентах через ГосСОПКА — обязательно для всех объектов КИИ.
Блок 2 · КИИ44 / 103
2.4 · Отраслевые особенности категорирования (с 01.09.2025)

Перечни и особенности по отраслям

ФЗ-58 ввёл механизм отраслевых типовых перечней и особенностей категорирования. Утверждают подзаконными актами Правительства по своим сферам:

Минцифры
Связь.
Минэнерго
ТЭК, энергетика.
Минпромторг
Химическая, металлургическая, оборонная промышленность.
Минздрав
Здравоохранение.
Минобрнауки
Наука.
Минтранс
Транспорт.
Роскосмос
Ракетно-космическая промышленность (проект ПП от 02.07.2025).
Госкорпорация «Росатом»
Атомная энергия.
Уже принято — сфера связиПостановление Правительства от 13.04.2026 № 402 «Отраслевые особенности категорирования объектов КИИ в сфере связи» — первый отраслевой подзаконный акт, развивающий ФЗ-58. Вступает в силу 01.09.2026. Расчётный метод + моделирование атак; ключевой показатель — количество абонентов оператора связи. Сопровождающая методика ФСТЭК — от 12.04.2026. Следом ожидаются аналогичные ПП по другим сферам.

Ссылки на источники — в footer-сноске лонгрид-режима.

Блок 2 · КИИ45 / 103
2.5 · Приказ ФСТЭК № 235

Система безопасности ЗОКИИ — что обеспечивает

—Должна обеспечивать
  • Предотвращение неправомерного доступа, уничтожения, модификации, блокирования, копирования, распространения информации.
  • Недопущение воздействия на технические средства обработки информации, при котором нарушается или прекращается функционирование ЗОКИИ.
  • Восстановление функционирования ЗОКИИ.
  • Непрерывное взаимодействие с ГосСОПКА.
—Состав системы безопасности
1
ОРД
Политики, регламенты, инструкции по обеспечению безопасности.
2
Структурные подразделения
Или назначенные лица, ответственные за обеспечение безопасности.
3
Технические меры
СЗИ, средства обнаружения и реагирования, средства ГосСОПКА.
—Документация системы безопасности
  • Документы целей и задач обеспечения безопасности; документы по категорированию.
  • Документы по моделированию угроз.
  • Проектная и эксплуатационная документация на систему безопасности.
  • ОРД по реагированию на инциденты и взаимодействию с ГосСОПКА.
Блок 2 · КИИ46 / 103
2.6 · Приказ ФСТЭК № 239

Восемнадцать групп мер защиты

Меры защиты группируются в подсистемы. Для каждой категории значимости установлен базовый набор, адаптируемый под актуальные угрозы и условия.

ИАФ
Идентификация и аутентификация
УПД
Управление доступом
ОПС
Ограничение программной среды
ЗНИ
Защита машинных носителей
АУД
Аудит безопасности
АВЗ
Антивирусная защита
СОВ
Предотвращение вторжений (IPS)
АНЗ
Контроль защищённости
ОЦЛ
Обеспечение целостности
ОДТ
Обеспечение доступности
ЗТС
Защита технических средств
ЗИС
Защита ИС и её компонентов
УКФ
Управление конфигурацией
ОПО
Управление обновлениями
ИНЦ
Реагирование на инциденты
ОНРБ
Управление непрерывностью
ДНС
Действия в нештатных ситуациях
ИПО
Информирование и обучение персонала
Готовится с 01.09.2026Проект изменений в приказы № 235 и № 239 (опубликован 07.04.2026) вводит для ЗОКИИ два показателя: Кзи (защищённости, оценка ≥1 раз в 6 месяцев) и Пзи (зрелости мер, ≥1 раз в 2 года). При несоответствии нормам — уведомление руководителя в течение 3 календарных дней и направление результатов во ФСТЭК в течение 5 рабочих дней. Это закрепляет переход от «однажды аттестовали» к непрерывному самомониторингу.
Блок 2 · КИИ47 / 103
2.6 · Адаптация базового набора мер

Логика приказа № 239 — три шага

ШАГ 1Базовый наборпо категории значимости (1/2/3) ШАГ 2Исключение неактуальныхпо модели угроз и условиям ШАГ 3Компенсирующие мерыесли базовая не реализуема
ПринципМеры № 239 — это не «бумажные» меры, а функции, которые должны быть реально реализованы в системе. Для каждой меры разрабатываются процедуры, фиксируются ответственные, проверяется эффективность.
Блок 2 · КИИ48 / 103
2.7 · ПП № 162, приказы ФСТЭК № 229 и № 135

Государственный контроль ЗОКИИ

Государственный контроль осуществляет ФСТЭК. Предмет — соблюдение требований 187-ФЗ, ПП № 127, приказов № 235, № 239 и иных НПА из перечня, утверждённого приказом № 135.

Вид 1
Плановые проверки
По утверждённому плану. Документарная и выездная части. Уведомление субъекта заранее.
Вид 2
Внеплановые проверки
По обращениям, по фактам нарушений, после инцидентов. Срок и порядок — короче.
—Документы по итогам
  • Акт проверки — форма по приказу ФСТЭК № 229.
  • Предписание об устранении нарушений.
  • При выявлении админ. правонарушений — материалы для составления протокола (КоАП РФ).
Блок 2 · КИИ49 / 103
2.8 · УП № 166, УП № 250

Технологическая независимость КИИ

С 2022 года введён системный курс на технологическую независимость КИИ. Два ключевых указа задают рамку:

УП № 166 от 30.03.2022
Запреты на иностранное ПО
  • С 31.03.2022 — запрет закупки иностранного ПО для ЗОКИИ без согласования.
  • С 01.01.2025 — запрет использования иностранного ПО на ЗОКИИ.

С учётом изм. УП № 887 (2023) и УП № 214 (07.04.2025).

УП № 250 от 01.05.2022
Зам. руководителя по ИБ
  • Назначение зам. руководителя по ИБ.
  • Передача функций по ИБ внутрь организации.
  • Меры по реагированию на компьютерные атаки.

С учётом изм. УП № 500 (13.06.2024). Переходный период — приказ ФСБ № 543 (с изм. № 282 от 21.07.2025).

Блок 2 · КИИ50 / 103
2.8 · ПП № 1478 и ПП № 1912

Российское ПО и доверенные ПАК

ПП № 1478 от 22.08.2022
Требования к ПО на ЗОКИИ
  • Детальные требования к ПО (в т.ч. в составе ПАК) на ЗОКИИ.
  • Правила согласования закупок иностранного ПО.
  • Правила перехода на российское ПО.
  • Реестр российского ПО — единый реестр программ для ЭВМ и БД Минцифры.

С учётом изм. ПП № 1716 (17.10.2023).

ПП № 1912 от 14.11.2023
Переход на доверенные ПАК
  • Порядок перехода субъектов КИИ на доверенные ПАК на ЗОКИИ.
  • Критерии доверенного ПАК (см. ПНСТ 905—2023).
  • Сроки перехода — поэтапные, привязаны к категории значимости.
Блок 2 · КИИ51 / 103
2.8 · ПНСТ 905, ПП 1912 — доверенные ПАК

Анатомия доверенного ПАК

—Три критерия доверенного ПАК
1
Реестр радиоэлектроники
Сведения о ПАК содержатся в едином реестре российской радиоэлектронной продукции.
2
Требования к ПО
ПАК соответствует предъявленному комплексу требований к ПО.
3
Требования к ЗИ
При реализации функций ЗИ — соответствует требованиям ФСТЭК и/или ФСБ (подтверждается сертификатом).
—Архитектура (по материалам В. Карантаева, НЭК.ТЕХ)
УРОВЕНЬ 5Прикладное ПО + ПО СКЗИ Защищённая встраиваемая ОС Средства доверенной загрузки — Secure Boot, Encrypted Boot ОСНОВАНИЕДоверенная аппаратная база — SoC + аппаратный корень доверия / СКЗИ
Блок 2 · КИИ52 / 103
2.10 — 2.12 · Завершение блока 2

Эксплуатация на практике и контрольные вопросы

2.108 задач эксплуатации
  1. Сопровождение системы безопасности — обновление СЗИ, реакция на сбои.
  2. Управление конфигурацией — эталоны, контроль изменений.
  3. Управление обновлениями — патч-менеджмент по методике ФСТЭК 28.10.2022.
  4. Мониторинг событий ИБ — SIEM, SOC, ГосСОПКА.
  5. Реагирование на инциденты — по плану; информирование ФСБ через НКЦКИ.
  6. Обучение и осведомлённость — администраторов и пользователей.
  7. Внутренние проверки и аудит — самоаудит, внешний аудит, пентест.
  8. Подготовка к проверкам ФСТЭК и ФСБ.
2.11Типовые сложности
  • Расхождение «как написано» и «как работает».
  • Импортозамещение в процессе — зоопарк решений.
  • Вендоры выпускают патчи быстрее, чем сертификаты совместимости обновляются.
  • ГосСОПКА требует зрелого инцидент-процесса.
  • Аттестация ЗОКИИ — гибче, но требует постоянного поддержания.
  • Кадровый дефицит специалистов по защите КИИ.
2.12Контрольные вопросы блока 2
  1. Перечислите сферы КИИ по 187-ФЗ.
  2. Какие изменения внесли ФЗ-58 (с 01.09.2025) и ФЗ-325 (с 01.03.2026)?
  3. Кто такой субъект КИИ после 01.03.2026?
  4. Что входит в систему безопасности ЗОКИИ по приказу № 235?
  1. Назовите основные группы мер по приказу № 239.
  2. Что такое доверенный ПАК и какие 3 критерия он соблюдает?
  3. Документы по итогам государственного контроля по ПП № 162?
  4. Чем отличается ЗОКИИ от объекта КИИ без категории значимости?
Блок 2 · КИИ53 / 103
Блок 3·13:30 — 15:00·20 слайдов
03

Планирование работ по обеспечению ИБ

КСЗИ как зонтичная система. Принципы планирования, цикл PDCA, восемь этапов планирования по ТЗИ, разработка-согласование-утверждение, типовой план СЗПДн. Особый акцент — связь с бюджетным циклом и кейс приказа № 117.

—Цели блока
  • Дать рамку КСЗИ, в которую вписываются ГИС, ИСПДн, ЗОКИИ.
  • Раскрыть планирование как процесс, а не «составление списка».
  • Связать план ТЗИ с бюджетом и нормативкой 2025 — 2026 годов.
—После блока вы умеете
  • Сформировать перспективный и текущий план мероприятий по ТЗИ.
  • Обосновать перед руководством сроки и ресурсы.
  • Готовиться к приказу № 117 — пилот SIEM/SOC заранее.
Блок 3 · Планирование54 / 103
3.1 · Комплексная система защиты информации

КСЗИ — зонтичная система защиты «всего»

КСЗИ — комплекс организационных и технических мер защиты информации, обеспечивающий безопасность всей совокупности информации, подлежащей защите, независимо от:

Независимо от
Категории
ПДн, ДСП, коммерческая тайна, гостайна, ИОД, информация на КИИ.
Независимо от
Формы существования
Электронная, бумажная, речевая.
Независимо от
Технологии обработки
ИС, ИТКС, АСУ, безмашинная обработка.
Независимо от
Типа объектов
Помещения, технические средства, носители, люди.
Этапы защитыЗащита нужна на всех этапах: сбор, передача, хранение, использование, уничтожение.
Блок 3 · Планирование55 / 103
3.1 · Объекты защиты КСЗИ

Четыре типа защищаемой информации

1
Речевая информация
Переговоры, выступления, телефонные разговоры. Защита от утечки по техническим каналам, от подслушивания.
2
Информация в ИС
БД, файлы, журналы, отчёты. СЗИ от НСД, СКЗИ, аутентификация, журналирование.
3
Информация в каналах связи
Сетевой трафик, обмен с внешними системами. МСЭ, СКЗИ, ВЧС, SIEM.
4
Документированная (бумажная)
Документы на бумажных и иных машиночитаемых носителях. Учёт, хранение, уничтожение.
Блок 3 · Планирование56 / 103
3.1 · Категории защищаемой информации

Что именно мы защищаем

КатегорияРегуляторная базаГлавный регулятор
ПДн152-ФЗ «О персональных данных»; приказ ФСТЭК № 21; ПП № 1119 (уровни защищённости).Роскомнадзор, ФСТЭК, ФСБ
ДСППостановления, нормативные акты ФОИВ; режим конфиденциальности.Орган-источник
Коммерческая тайна98-ФЗ «О коммерческой тайне».Сама организация
Информация на ЗОКИИ187-ФЗ; приказы ФСТЭК № 235 и № 239; приказы ФСБ № 367, № 282.ФСТЭК, ФСБ (через НКЦКИ)
Гостайна5485-1 «О государственной тайне».ФСБ (8 ЦБИ), Минобороны

Одна организация может одновременно обрабатывать информацию нескольких категорий — например, банк: ПДн клиентов + коммерческая тайна + ЗОКИИ + (для отдельных подразделений) гостайна. КСЗИ должна покрывать всё.

Блок 3 · Планирование57 / 103
3.2 · Принципы построения КСЗИ

Десять принципов построения КСЗИ

1
Обоснованность
Целесообразность ограничения доступа и защиты с учётом экономических и правовых последствий.
2
Законность
Соответствие действующему законодательству и законным требованиям обладателя.
3
Системность
Учёт всех взаимосвязанных элементов, условий и факторов.
4
Эшелонированность
Defense in depth — последовательные рубежи защиты.
5
Превентивность
Своевременное выявление угроз и выработка мер по их недопущению.
6
Непрерывность
Применение мер в каждый момент времени.
7
Централизация
Единая политика обеспечения безопасности.
8
Обязательность контроля
Периодическая проверка соответствия, привлечение к ответственности.
9
Преемственность
Постоянное улучшение мер и СЗИ.
10
Персональная ответственность
Каждый сотрудник отвечает за вверенную ему защищаемую информацию.

Подсвечены три ключевых принципа, особенно часто проверяемых при аудите: эшелонированность, непрерывность, персональная ответственность.

Блок 3 · Планирование58 / 103
3.3 · Сущность и понятие планирования

Цикл Шухарта — Деминга

Планирование — разработка комплекса мероприятий и последовательности их выполнения для достижения конкретных целей при условии эффективного использования ресурсов. План — заранее намеченная система деятельности (С.И. Ожегов).

P · PLANПланированиеОпределение целейи процессов D · DOВыполнениеВнедрение,выполнение действий C · CHECKПроверкаКонтроль и измерениепроцессов и результатов A · ACTУлучшениеИзменение процессаили новый цикл

PDCA лежит в основе СУИБ (ISO/IEC 27001) и подходов к управлению рисками (ISO 31000, ISO 27005), а также инцидент-менеджмента (ГОСТ Р 59710—59712).

Блок 3 · Планирование59 / 103
3.4 · Исходные данные для планирования по ТЗИ

Шесть источников исходных данных

1
Требования НПА по ЗИ
152-ФЗ, 187-ФЗ, приказы ФСТЭК № 17/117/21/235/239, постановления Правительства.
2
Положения собственных ОРД
Политики, положения, инструкции организации.
3
Текущее состояние ТЗИ
Результаты предыдущих обследований, аудитов, аттестаций.
4
Располагаемые ресурсы
Бюджет, кадры, время.
5
Контроль и надзор
Предписания ФСТЭК / ФСБ / РКН, протоколы и решения по итогам проверок.
6
План вышестоящей организации
Для холдингов, групп компаний, госорганов.
Блок 3 · Планирование60 / 103
3.5 · Принципы планирования

Семь принципов планирования

1
Директивность
Обязательный характер планов.
2
Преемственность
Сочетание перспективного и текущего планирования; учёт достигнутого и недостатков.
3
Конкретность
Чёткие цели и задачи, рациональные методы, ответственные, реальные сроки.
4
Проблемность
Нацеленность на решение значимых проблем ЗИ, а не «галочка».
5
Комплексность
Вся система мер на разных направлениях, согласование на разных уровнях.
6
Экономичность
Максимальные результаты при наименьших затратах.
7
Гибкость
Возможность манёвра ресурсами; корректировка плана при изменении обстановки.
Блок 3 · Планирование61 / 103
3.6 · Цели планирования

Шесть целей планирования по ТЗИ

  1. Определение комплекса мероприятий по защите информации — направленных на исключение (нейтрализацию) возможных каналов утечки и угроз БИ.
  2. Установление персональной ответственности должностных лиц.
  3. Определение сроков (периодов) проведения мероприятий.
  4. Систематизация (объединение) планируемых мероприятий по различным направлениям ЗИ.
  5. Установление системы контроля и системы отчётности.
  6. Конкретизация функций и задач, решаемых должностными лицами и подразделениями.
Блок 3 · Планирование62 / 103
3.7 · Требования к результатам планирования

Пять требований к плановым результатам

1
Реальные и достижимые
Не теоретически возможные, а исполнимые при имеющихся ресурсах.
2
Детализированные
По подразделениям, технологическому циклу, видам защищаемой информации.
3
Измеримые
Однозначные, чёткие для понимания. Можно проверить факт выполнения.
4
Не противоречащие
Объективным законам и общим принципам управления.
5
Понятные исполнителям
Без жаргона, без размытых формулировок, со ссылками на регламенты.
Блок 3 · Планирование63 / 103
3.8 · Перспективное и текущее планирование

Два горизонта планирования

АспектПерспективное планированиеТекущее планирование
Горизонт3 — 5 лет (или дольше для стратегических документов)Год, квартал, месяц
ЦельСтратегические цели и направления развития системы ЗИФактическое достижение частных целей ЗИ с учётом текущих условий
ДокументыКонцепция ЗИ, планы развития подсистем, программы управления ЗИПланы мероприятий по ТЗИ; дополняют и уточняют перспективный план
Связь с бюджетомСвязь с долгосрочным бюджетом и стратегическим планированием организацииПривязка к годовому бюджетному циклу
Блок 3 · Планирование64 / 103
3.9 · Восемь этапов планирования мероприятий по ТЗИ

Восемь этапов планирования

1
Обоснование целей и критериев ЗИ
Соответствие общим целям; критерии оценки качества.
2
Анализ условий деятельности
Внешние и внутренние условия, структура, процессы, персонал.
3
Формулировка задач ЗИ
Задачи, методы, процедуры.
4
Анализ ресурсов
Финансовые, МТ, временные, организационные, кадровые.
5
Согласование
Цели, задачи, условия, ресурсы; распределение и исполнители.
6
Последовательность задач
Порядок и сроки выполнения.
7
Методы контроля
Под цели и критерии. Оценка качества.
8
Порядок корректировки
Корректировка — в необходимой мере.
Блок 3 · Планирование65 / 103
3.10 · Документация планирования по ТЗИ

Разработка, согласование, утверждение

РАЗРАБОТКАСлужба безопасности(подразделение ТЗИ) СОГЛАСОВАНИЕКадровый орган СОГЛАСОВАНИЕСлужба режима (ПДИТР) СОГЛАСОВАНИЕСлужба ИТ СОГЛАСОВАНИЕФинансовый орган УТВЕРЖДЕНИЕРуководительпредприятия (организации) РЕЗУЛЬТАТПлан —обязательный для всех

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

Блок 3 · Планирование66 / 103
3.11 · Пример. План разработки СЗПДн — часть 1

Основание, цели, ответственные

Формальное основаниеПриказ руководителя организации «О реализации требований Федерального закона от 27.07.2006 № 152-ФЗ "О персональных данных"».
—Цель плана

Разработать и ввести в эксплуатацию систему защиты ПДн (СЗПДн), соответствующую требованиям 152-ФЗ, приказа ФСТЭК № 21, ПП № 1119, нормативных актов ФСБ по СКЗИ — для каждой ИСПДн организации.

—Ответственные роли
  • Руководитель проекта по защите ПДн — назначается приказом.
  • Ответственный за обеспечение безопасности ПДн — функция по 152-ФЗ.
  • Сотрудники СБ, ИТ, кадров, юридического подразделения — соответствующие действия.
  • Руководитель организации — утверждает результаты ввода в эксплуатацию.

Аналогичный план разрабатывается для ГИС (по приказу № 17 / № 117 с 01.03.2026), для ЗОКИИ (приказы № 235 и № 239), для систем обработки коммерческой тайны.

Блок 3 · Планирование67 / 103
3.11 · Пример. План СЗПДн — часть 2

Мероприятия 1 — 5: обследование, угрозы, СЗИ

№МероприятиеЦельСрокОтветственный
0Изучение НПА в области защиты ПДнПонимание требованийдо началаОтв. за ПДн
1Обследование информационных ресурсов ИСПДнСбор исходных данных01.06 — 03.06Иванов И.И.
2Разработка модели угроз безопасности ПДнОпределение актуальных угроз07.06Петров П.П.
3Определение уровня защищённости ПДнОпределить УЗ ПДн07.06Петров П.П.
4Определение состава орг.-техн. мер защиты ПДнАдаптированный уточнённый базовый набор08.06Сидоров С.С.
5Выбор и закупка СЗИПриобретение сертифицированных СЗИ15.06Иванов И.И.
Блок 3 · Планирование68 / 103
3.11 · Пример. План СЗПДн — часть 3

Мероприятия 6 — 10: настройка, испытания, ввод

№МероприятиеЦельСрокОтветственный
6Выполнение организационных мероприятий по защите ПДн (КЗ, физ. охрана, ПРД, перечень лиц с доступом, отв. за ПДн, учёт СМНИ, помещения для СКЗИ по инструкции ФАПСИ № 152)Реализация орг. мер по 152-ФЗ20.06Иванов И.И.
7Настройка СЗИ в соответствии с приказом ФСТЭК № 21Выполнение мер защиты22.06Петров П.П.
8Разработка/доработка эксплуатационной документации, обучение пользователей ИСПДнИнформирование и обучение25.06Сидоров С.С.
9Испытания системы защиты ПДн, устранение недостатковОценка работоспособности и эффективности28.06Петров П.П.
10Ввод системы защиты ПДн в эксплуатацию (приказ о вводе)Юридическое оформление29.06Руководитель
Блок 3 · Планирование69 / 103
3.12 · Связь планирования с бюджетным процессом

Если упустить осенний цикл — проект уехал на год

ОСЕНЬ NБюджетные заявкина год N+1 ДЕКАБРЬ NУтверждениебюджета на N+1 ЯНВ — ФЕВ N+1Закупочныепроцедуры МАРТ — ОКТ N+1Реализация НОЯБРЬ N+1Итоги, заявкина год N+2
ГлавноеЕсли ИБ-проект не попал в бюджетную заявку осенью, он автоматически смещается на год. Перспективное планирование обязано учитывать этот цикл.
Блок 3 · Планирование70 / 103
3.12 · Кейс из практики

Приказ ФСТЭК № 117 — пилот SIEM нужно запускать в 2025

Приказ ФСТЭК от 11.04.2025 № 117 вступает в силу 01 марта 2026 года и заменяет приказ № 17. Расширяет действие требований на ИС ГУП и госучреждений.

2025 Q1—Q2Выбор SIEM, RFI 2025 Q3Закупка, пилот 2025 Q4Внедрение, обучение 2026 Q1Тонкая настройка DEADLINE01.03.2026
ЛогикаВнедрение SIEM «под ключ» занимает 8 — 12 месяцев. Если организация не запустила подготовку и пилот SIEM/SOC в 2025 году, к 01.03.2026 готовности не будет. Ранний старт — фактор успеха.
Блок 3 · Планирование71 / 103
3.13 · Типовые ошибки планирования ТЗИ

Семь грабель в планах ТЗИ

«Для проверки»План написан под аудит, а не для работы. Мероприятия не подкреплены ресурсами.
Нереальные сроки«Внедрить SIEM за 1 месяц», «провести аттестацию за неделю». Срывы — гарантированы.
Бюджетный цикл не учтёнМероприятия на январь, а бюджет не утверждён.
ФИО вместо должностейСотрудник уволился — мероприятие зависло.
Не связан с общим планомКонфликт с модернизацией ИС, переездом, реструктуризацией.
Не пересматриваетсяПри изменении нормативки или инфраструктуры план не обновляется.
Нет показателей результатаТолько «выполнено / не выполнено», без качественной оценки эффективности.
Документация ≠ реальностьНа бумаге — есть, в реальности — нет. Самая распространённая болезнь.
Блок 3 · Планирование72 / 103
3.14 · Контрольные вопросы блока 3

Проверка усвоения

  1. Дайте определение КСЗИ. Что включается в объекты защиты?
  2. Перечислите 10 принципов построения КСЗИ.
  3. Что такое цикл PDCA и где он применяется в ИБ?
  4. Перечислите 7 принципов планирования и 8 этапов планирования по ТЗИ.
  5. Кто разрабатывает, согласует и утверждает планы по ТЗИ?
  6. Чем отличается перспективное планирование от текущего?
  7. Как связаны планирование по ТЗИ и бюджетный цикл организации?
Блок 3 · Планирование73 / 103
Блок 4·15:10 — 16:40·17 слайдов
04

Управление компьютерными инцидентами. Часть 1

187-ФЗ, ГосСОПКА и НКЦКИ. ГОСТы серии 597XX. Жизненный цикл инцидента — все 7 этапов. Регистрация событий безопасности по ГОСТ Р 59548 — 2022. SIEM / SOC / NOC и роли команды реагирования.

—Цели блока
  • Развести понятия «компьютерный инцидент» и «компьютерная атака» по 187-ФЗ.
  • Дать рабочую модель жизненного цикла инцидента.
  • Объяснить, кто, куда и в какие сроки информирует.
—После блока вы умеете
  • Спроектировать минимальную команду реагирования.
  • Связать SIEM, SOC, ГосСОПКА в один процесс.
  • Готовить отчёт об инциденте по приказу ФСБ № 367.
Блок 4 · Инциденты ч.174 / 103
4.1 · 187-ФЗ, статья 2; ГОСТ Р 59709 — 2022

Компьютерный инцидент vs компьютерная атака

Инцидентфакт последствий

Компьютерный инцидент — факт нарушения и/или прекращения функционирования объекта КИИ, сети электросвязи, и/или нарушения безопасности обрабатываемой информации, в т.ч. произошедший в результате компьютерной атаки.

Инцидент может возникнуть и без атаки — отказ оборудования, ошибка администратора, природная катастрофа.

Атакадействие нарушителя

Компьютерная атака — целенаправленное воздействие программных и/или программно-аппаратных средств на объекты КИИ, сети электросвязи, в целях нарушения и/или прекращения их функционирования и/или создания угрозы безопасности информации.

Атака может быть отбита — тогда инцидента не возникает.

ГлавноеАтака — это действие. Инцидент — это факт. Соотношение «много к многим»: одна атака → много инцидентов; один инцидент может быть результатом серии атак или вообще не быть связан с атакой.
Блок 4 · Инциденты ч.175 / 103
4.2 · Цели управления инцидентами

Зачем нужен процесс инцидент-менеджмента

  1. Минимизация последствий инцидента — ущерб для бизнеса, утечка, простой, репутация.
  2. Быстрое восстановление функционирования.
  3. Локализация атакующего — для расследования и недопущения повторного входа.
  4. Накопление знаний об угрозах — обратная связь к моделированию угроз и оценке рисков.
  5. Выполнение требований регуляторов — информирование ФСБ через НКЦКИ.
  6. Снижение вероятности повторения — за счёт уроков предыдущих инцидентов.
Без процессаорганизация реагирует «как умеет», без приоритизации, без фиксации, без выводов. Каждый следующий инцидент похож на первый — и команда раз за разом изобретает велосипед.
Блок 4 · Инциденты ч.176 / 103
4.3 · ГосСОПКА

Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак

—Основание создания
2013
УП № 31с
Создание ГосСОПКА (15.01.2013).
2014
Концепция К 1274
Концепция ГосСОПКА (12.12.2014).
2015
План № 9397
План развёртывания ведомственных сегментов (21.08.2015).
2017
УП № 620
Совершенствование ГосСОПКА (22.12.2017).
Уполномоченный органФедеральная служба безопасности (ФСБ). Координационный центр — НКЦКИ (Национальный координационный центр по компьютерным инцидентам), создан приказом ФСБ № 366 от 24.07.2018.
Блок 4 · Инциденты ч.177 / 103
4.3 · Структура и функции ГосСОПКА

Трёхуровневая архитектура

ЦЕНТРНКЦКИ (ФСБ) УРОВЕНЬ 2Ведомственные центрысоздаются ФОИВ УРОВЕНЬ 2Корпоративные центрыкрупные субъекты КИИ УРОВЕНЬ 3Субъекты КИИпрямое подключение
—Функции ГосСОПКА
  • Сбор и анализ информации о компьютерных инцидентах от субъектов КИИ.
  • Предоставление субъектам КИИ информации о признаках компьютерных атак, методах их предупреждения и обнаружения.
  • Координация действий при крупных инцидентах.
  • Проведение мероприятий по оценке защищённости.
Блок 4 · Инциденты ч.178 / 103
4.4 · Информирование о компьютерных инцидентах

Кто, куда, в какие сроки

СубъектКудаОснование
Субъекты КИИ — обо всех инцидентах на объектах КИИНКЦКИ — через систему ГосСОПКА (техн. каналы)Приказ ФСБ № 367
Субъекты КИИ — об инцидентах на ЗОКИИФСБПриказ ФСБ № 282 (с изм. № 348 от 07.07.2022)
Кредитные и финансовые организацииБанк России (FinCERT)Методические рекомендации Банка России № 14-МР и № 15-МР от 26.10.2023
—Сроки информирования (зависят от категории инцидента)
Критические
В течение нескольких часов
Критические инциденты на ЗОКИИ. Уведомление по горячим каналам.
Средние
В течение суток
Инциденты средней значимости.
Прочее
См. приказ ФСБ № 367
Полный перечень — в приказе и методических рекомендациях НКЦКИ.

Порядок обмена с иностранными организациями — приказ ФСБ № 368.

Блок 4 · Инциденты ч.179 / 103
4.4 · Приказ ФСБ № 367 — состав уведомления

Что входит в уведомление об инциденте

1
Идентификация объекта КИИ
Реквизиты объекта, владельца, реестровый номер ЗОКИИ.
2
Описание инцидента
Тип, время обнаружения, последствия.
3
Предпринятые меры
Сдерживание, ликвидация, восстановление.
4
Сведения об атаке
Если установлены: вектор, инструменты, MITRE ATT&CK.
5
Индикаторы компрометации (IoC)
Хэши, IP, домены, имена файлов, регулярные выражения для детекта.
Блок 4 · Инциденты ч.180 / 103
4.5 · ГОСТы серии 597XX — карта стандартов

Единая методическая база инцидент-менеджмента в РФ

СтандартНазваниеСодержание
ГОСТ Р 59709 — 2022Термины и определенияБазовый язык: инцидент, атака, событие, активы, угрозы, IoC, IoA, реагирование, восстановление, форензика, постмортем.
ГОСТ Р 59710 — 2022Общие положенияКонцепция: цели и задачи, принципы, основные процессы, роли и ответственность, связь с риск-менеджментом и СУИБ.
ГОСТ Р 59711 — 2022Организация деятельностиСоздание структуры (CSIRT/SOC), ОРД, обучение, инструментарий, формирование команды.
ГОСТ Р 59712 — 2022Руководство по реагированиюЭтапы жизненного цикла: обнаружение и регистрация, реагирование, анализ результатов деятельности.
Блок 4 · Инциденты ч.181 / 103
4.6 · Жизненный цикл инцидента — обзор

Семь этапов жизненного цикла

Универсальная модель — объединяет ГОСТ Р 59712, NIST SP 800-61, SANS. Замыкается в цикл: уроки этапа 7 возвращаются в подготовку этапа 1.

1
Подготовка
SIEM, плейбуки, контакты, обучение, процессы.
2
Обнаружение
Сигнал, триаж, регистрация, первичная классификация.
3
Анализ
Хронология, форензика, MITRE ATT&CK, скоуп.
4
Сдерживание
Изоляция, блокировка, сохранение доказательств.
5
Ликвидация
Удаление ВПО, патчинг, смена учётных данных.
6
Восстановление
Возврат сервисов, бэкапы, усиленный мониторинг.
7
Уроки
Постмортем blameless, обновление модели угроз.
Блок 4 · Инциденты ч.182 / 103
4.6 · Этап 1 · Подготовка (preparation)

Что должно быть готово до первого инцидента

1
Средства мониторинга
SIEM, EDR, NDR, AV, IDS/IPS. Подключение к ГосСОПКА.
2
Плейбуки реагирования
Типовые сценарии: ransomware, утечка ПДн, фишинг, AD-компрометация, DDoS, инсайдер.
3
Контакты внешних сторон
НКЦКИ, ФСБ, отраслевой CERT, юристы, вендоры. С круглосуточной доступностью.
4
Обучение команды
Регулярные TTX, технические учения, ротация ролей.
5
Процессный фундамент
Приказы, инструкции, журналы регистрации, шаблоны уведомлений.
6
Дежурный график
L1 — круглосуточно. L2/L3 — по эскалации. SLA на ответ.
Блок 4 · Инциденты ч.183 / 103
4.6 · Этапы 2 — 3 · Обнаружение и анализ

От сигнала до полной картины

Этап 2
Обнаружение и регистрация
  • Источники сигналов: мониторинг (SIEM, EDR), пользователи, внешние источники — НКЦКИ, отраслевые CERT, Threat Intelligence, вендоры.
  • Триаж — отделение реальных инцидентов от ложных срабатываний.
  • Регистрация в IRP / SOAR / тикет-системе.
  • Первичная классификация: тип, серьёзность, затронутые активы.
  • Уведомление руководителя инцидента (incident handler).
Этап 3
Анализ
  • Подробное исследование: что произошло, как, через что, кто.
  • Сбор форензики — образы дисков, дампы памяти, сетевые логи, журналы.
  • Хронология инцидента (timeline).
  • Определение полного скоупа затронутых активов.
  • Индикаторы компрометации и тактики/техники атакующего по MITRE ATT&CK.
Блок 4 · Инциденты ч.184 / 103
4.6 · Этапы 4 — 5 · Сдерживание и ликвидация

От «прекратить распространение» до «удалить присутствие»

Этап 4
Сдерживание (containment)
  • Изоляция заражённых хостов, блокировка сетевых соединений, отключение скомпрометированных учётных записей.
  • Сохранение доказательств (форензики) до удаления вредоносной активности.
  • Краткосрочное сдерживание — быстро остановить.
  • Долгосрочное — наблюдать за атакующим, собирать данные (там, где безопасно).
Этап 5
Ликвидация (eradication)
  • Удаление вредоносных артефактов: ВПО, бэкдоры, изменённые конфигурации.
  • Закрытие эксплуатированных уязвимостей: патчинг, изменение конфигов.
  • Смена учётных данных, сертификатов, ключей.
  • Удаление присутствия атакующего во всех затронутых системах.
Опасность«Очистили сервер, перезагрузили» — частая иллюзия. Если не закрыли эксплуатируемую уязвимость и не сменили учётные данные, атакующий вернётся через тот же вектор.
Блок 4 · Инциденты ч.185 / 103
4.6 · Этапы 6 — 7 · Восстановление и уроки

Возврат в эксплуатацию и обратная связь

Этап 6
Восстановление (recovery)
  • Возвращение систем в нормальный режим работы.
  • Восстановление данных из резервных копий (если требуется).
  • Поэтапное снятие изоляций с верификацией отсутствия повторной компрометации.
  • Усиленный мониторинг в течение периода после восстановления.
Этап 7
Извлечение уроков (lessons learned)
  • Постмортем без поиска виноватых (blameless).
  • Документирование: что случилось, что сработало, что нет.
  • Обновление модели угроз, оценки рисков, реестра уязвимостей.
  • Корректировка плейбуков, политик, регламентов.
  • Информирование причастных сторон. Возврат знаний в этап «подготовка» — следующий цикл.
Блок 4 · Инциденты ч.186 / 103
4.7 · Классификация компьютерных инцидентов

По влиянию и по типу

—По степени влияния на бизнес
Низкая
Без существенного влияния
Одиночный фишинг, блокировка AV, единичная подозрительная активность.
Средняя
Частичное нарушение
Компрометация рабочей станции, локальная вспышка ВПО.
Высокая
Существенное нарушение
Утечка значимых данных, частичная остановка сервиса.
Критическая
Полная остановка / утечка масштаба
Компрометация ЗОКИИ, цепочка поставок, утечка ПДн массового масштаба.
—По типу
ВПО
Вирусы, шифровальщики, RAT, кейлоггеры.
DDoS / DoS
НСД / компрометация УЗ
Утечки данных
APT
Целевые атаки.
Социальная инженерия
Фишинг, vishing, smishing, BEC.
Supply chain
Атаки на AD / Federation
Веб-приложения
OWASP top 10.
АСУ ТП / SCADA
Внутренние угрозы
Облачные сервисы
Блок 4 · Инциденты ч.187 / 103
4.8 · ГОСТ Р 59548 — 2022

Регистрация событий безопасности

Без качественной регистрации обнаружение и расследование инцидентов невозможны. ГОСТ устанавливает что регистрировать, в каком составе, с какой полнотой, как обеспечивать целостность.

—Минимальный набор событий
  • События аутентификации (успешные и неуспешные).
  • События авторизации (выдача / отзыв прав).
  • Доступ к чувствительным ресурсам.
  • Системные события (запуск/остановка сервисов, перезагрузки).
  • Административные действия (изменение конфигурации, пользователей).
  • Сетевые события (соединения, подозрительный трафик).
  • События СЗИ (AV/EDR, SIEM, IDS).
—Состав записи
  • Дата и время.
  • Субъект (кто).
  • Объект (что).
  • Результат (успех / неудача).
  • Источник (с какого устройства / IP).
  • Описание события.
—Требования к хранению
  • Защита от несанкционированного изменения (целостность, неотказуемость).
  • Сроки хранения зависят от категории. Для ЗОКИИ — не менее 3 лет.
  • Централизованный сбор — как правило, в SIEM.
Блок 4 · Инциденты ч.188 / 103
4.9 · SIEM, SOC, NOC

Что есть что

SIEM
Security Information and Event Management
Техническая платформа: сбор, нормализация, хранение, корреляция и анализ событий безопасности.
SOC
Security Operations Center
Организационная структура: команда + процессы + инструменты. Эксплуатирует SIEM, обеспечивает круглосуточный мониторинг и реагирование.
NOC
Network Operations Center
Операционный центр сети — мониторинг доступности и производительности. Не безопасности.
—Зрелый SOC включает
  • L1 — мониторинг и триаж.
  • L2 — углублённое расследование, реагирование.
  • L3 — форензика, threat hunting, разработка правил.
  • Threat Intelligence — анализ угроз.
  • IRP / SOAR — автоматизация реагирования.
  • Red Team / Purple Team — имитация атак, проверка детектирования.
—Модели SOC
In-house
Внутренний. Контроль и компетенция остаются в организации.
MSSP
Managed Security Service Provider — сервисный SOC у внешнего поставщика.
Гибридный
Часть функций — внутри, часть — на аутсорсе.
Блок 4 · Инциденты ч.189 / 103
4.11 — 4.12 · Завершение блока 4

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

4.11Семь ролей команды реагирования
1
Incident Manager
Координирует ход инцидента, принимает решения, общается с руководством и регуляторами.
2
Incident Handler / Analyst
Техническая работа: анализ, сдерживание, ликвидация.
3
Forensic Analyst
Собирает и анализирует артефакты, готовит материалы для расследования.
4
Threat Intelligence
Атрибутирует атаку, ищет индикаторы по внешним источникам.
5
Communications
Коммуникации: внутренние, с регуляторами, при необходимости с публикой.
6
Legal
Правовая оценка, взаимодействие с правоохранительными органами.
7
Business Liaison
Представитель бизнеса. Обеспечивает понимание операционных приоритетов.
CSIRT
Если масштаб большой
В крупных организациях — отдельная команда CSIRT. В малых — один-два человека на все роли.
4.12Контрольные вопросы блока 4
  1. Чем отличается компьютерный инцидент от компьютерной атаки по 187-ФЗ?
  2. Опишите структуру ГосСОПКА и роль НКЦКИ.
  3. Кто и в какие сроки обязан информировать о компьютерных инцидентах?
  4. 4 ГОСТ серии 597XX и кратко о назначении каждого.
  1. Опишите жизненный цикл инцидента (7 этапов).
  2. Какие события безопасности регистрируются по ГОСТ 59548 — 2022?
  3. Чем SIEM отличается от SOC?
Блок 4 · Инциденты ч.190 / 103
Блок 5·16:50 — 18:20·12 слайдов
05

Управление компьютерными инцидентами. Часть 2

План реагирования, плейбуки, учения, управление уязвимостями. Новая методика критичности уязвимостей ФСТЭК от 30.06.2025. Threat Intelligence, метрики, связь с процессами. Зрелость vs «иллюзия устойчивости» — и новые подходы: deception, MTD, entropy injection.

—Цели блока
  • Дать каркас плана реагирования и плейбука.
  • Раскрыть новую методику критичности уязвимостей ФСТЭК (30.06.2025).
  • Связать инцидент-менеджмент с риском, VM, BCM, обучением, СУИБ.
—После блока вы умеете
  • Спланировать первый плейбук и table-top exercise.
  • Считать MTTD / MTTR / MTTC и операционные KRI.
  • Отличать зрелую функцию от «иллюзии устойчивости».
Блок 5 · Инциденты ч.291 / 103
5.1 · Incident Response Plan

План реагирования — структура из 13 разделов

Типовой состав по методическим рекомендациям ФСТЭК (для ЗОКИИ) и ГОСТ Р 59712 — 2022. Испытывается минимум ежегодно, пересматривается после крупных инцидентов и при изменении инфраструктуры.

1
Назначение и область
На какие объекты, для кого.
2
Термины
С привязкой к ГОСТ Р 59709.
3
Нормативные ссылки
187-ФЗ, ФСБ, ФСТЭК, внутренние ОРД.
4
Классификация инцидентов
Типы, уровни критичности, шкала ущерба.
5
Структура реагирования
Роли, ответственность, контакты, дежурство.
6
Этапы реагирования
Детализация 7 этапов жизненного цикла.
7
Плейбуки
Ransomware, утечка, AD, DDoS, инсайдер.
8
Информирование
Внутреннее и внешнее: НКЦКИ, ФСБ, БР, РКН.
9
Обмен с ГосСОПКА
Каналы, форматы, ответственные.
10
Взаимодействие с правоохранителями
Когда, как, через кого.
11
Документирование
Журналы, отчёты, материалы постмортема.
12
Учения и тренировки
TTX, технические, киберучения.
13
Метрики
KPI и KRI по инцидент-менеджменту.
Блок 5 · Инциденты ч.292 / 103
5.2 · Плейбук как инструмент

Плейбук — пошаговый сценарий по типу инцидента

—Типовая структура
  1. Условия активации (триггер).
  2. Уровень критичности по умолчанию.
  3. Команда и роли.
  4. Обнаружение: индикаторы, проверочные действия.
  5. Анализ: что собрать, источники.
  6. Сдерживание: изоляция, блокировка.
  7. Ликвидация: процедуры очистки.
  8. Восстановление: критерии возврата.
  9. Постмортем: что зафиксировать.
  10. Шаблоны коммуникаций (внутренних, регуляторам).
  11. Чек-листы.
—Первоочередные сценарии
Top 1
Ransomware
Шифровальщик. Изоляция, восстановление из бэкапов, информирование регуляторов.
Top 2
Утечка ПДн
Уведомление РКН в течение 24 часов с момента обнаружения (152-ФЗ).
Top 3
Фишинг
BEC, кража учётных данных. Сбор IoC, блокировка.
Top 4
AD-компрометация
Привилегированные УЗ, Golden Ticket, Kerberoasting. Сложно сдерживать.

Плейбуки могут быть автоматизированы в SOAR-платформах.

Блок 5 · Инциденты ч.293 / 103
5.3 · Учения и тренировки

Три типа — три глубины

TTX
Table-top exercise
«За столом». Участники проговаривают действия по плейбуку, без технического выполнения. Проверка процесса.
Частота: 1 раз в год по основным сценариям
Tech
Технические учения
Выполнение действий на тестовой или эталонной среде: изоляция хоста, восстановление из бэкапа.
Частота: 1 раз в полгода по 2 — 3 сценариям
Cyber
Киберучения
Комплексное мероприятие с Red Team / Blue Team. На киберполигоне (ПП № 1320 от 12.10.2019).
Частота: 1 раз в год — раз в 2 года
Минимум, который реально начатьОдин table-top exercise — 2 часа в переговорной, без бюджета. Это уже даст полезный взгляд на пробелы в плане и команде.
Блок 5 · Инциденты ч.294 / 103
5.4 · Vulnerability Management

Процесс VM — восемь шагов

Регламентируется руководством ФСТЭК от 17.05.2023, методиками от 30.06.2025 и 28.10.2022. Без полного перечня активов VM не работает.

1
Инвентаризация активов
Полный перечень ПО и ПАК.
2
Сбор информации
БДУ ФСТЭК, NVD, бюллетени, TI.
3
Сканирование
Регулярное, внутри и снаружи.
4
Оценка критичности
По методике ФСТЭК от 30.06.2025.
5
Приоритизация
Что закрывать в первую очередь.
6
Устранение
Патчинг, конфиги, компенсирующие меры.
7
Тестирование обновлений
По методике ФСТЭК от 28.10.2022.
8
Проверка результата
Повторное сканирование, верификация.
Блок 5 · Инциденты ч.295 / 103
5.5 · Методика ФСТЭК от 30.06.2025

Новая методика критичности уязвимостей

Заменяет редакцию от 28.10.2022. Расширен скоуп (+ ГУП / госучреждения), учитываются результаты пентестов и эксперимента по повышению защищённости ГИС ФОИВ. Если ИС в ЦОД — оценка с учётом инфраструктуры ЦОД.

—Новые показатели в формуле
Iat — возможность эксплуатации уязвимости Iimp — последствия эксплуатации

Изменены значения весовых коэффициентов и пороги критичности. Пересчёт — на постоянной основе, по возможности автоматизированно: при выпуске обновлений, появлении эксплойтов в открытом доступе.

—Пороги критичности — старая vs новая
Уровень2025 (новая)2022 (старая)
КритическийV > 8,07,0 < V < 10,0
Высокий5,0 < V < 8,04,5 < V < 7,0
Средний2,0 < V < 5,01,5 < V < 4,5
НизкийV < 2,0V < 1,5
Важное правилоУязвимостям в сертифицированных программных и программно-аппаратных средствах защиты автоматически присваивается критический уровень (V > 8,0).
Блок 5 · Инциденты ч.296 / 103
5.6 · Методика ФСТЭК от 28.10.2022

Тестирование обновлений безопасности

Цель — исключить ситуации, когда обновление само становится источником инцидента (компрометация цепочки поставки, отказ совместимости).

1
Проверка целостности и подлинности
Подписи, контрольные суммы вендора.
2
Статический анализ
Что входит в обновление; нет ли подозрительного кода.
3
Динамический анализ
Поведение при работе. Сетевые соединения, поведение в памяти.
4
Совместимость со СЗИ
Не блокируется ли антивирусом, EDR, IDS.
5
Тестовый стенд
Установка в эталонной среде с типовой нагрузкой.
6
Мониторинг после развёртывания
Наблюдение в течение SLA-периода.
Блок 5 · Инциденты ч.297 / 103
5.9 · Threat Intelligence и обмен IoC

Источники, форматы, применение

—Источники TI для РФ
  • НКЦКИ и ГосСОПКА — приказ ФСБ № 367.
  • БДУ ФСТЭК.
  • Отраслевые CERT: FinCERT, RU-CERT.
  • Коммерческие платформы: Kaspersky, Group-IB, Positive Technologies.
  • OSINT.
—Форматы обмена
  • STIX / TAXII — международные стандарты.
  • MISP — Malware Information Sharing Platform.
  • Ведомственные форматы НКЦКИ.
—Применение
  • Проактивная блокировка по индикаторам (IP, домены, хэши).
  • Настройка правил детектирования в SIEM/EDR.
  • Threat hunting — целенаправленный поиск признаков заранее известных угроз.
  • Стратегическое планирование — актуальная картина угроз.
Блок 5 · Инциденты ч.298 / 103
5.10 · Метрики инцидент-менеджмента

MTTD, MTTR, MTTC + операционные KRI

—Три ключевые метрики
MTTDMean Time to DetectСреднее время до обнаружения инцидента.
MTTRMean Time to Respond / RecoverСреднее время до реагирования / восстановления.
MTTCMean Time to ContainСреднее время до сдерживания.
—Операционные метрики
4
Количество инцидентов по типам
5
Доля обнаруженных собственными средствами
vs внешние сообщения. Норма — >70%.
6
Доля уведомлений НКЦКИ в SLA
7
% закрытия критических уязвимостей в SLA
Например, 7 дней для критических.
8
% персонала, прошедшего обучение по реагированию
9
Покрытие учениями
Раз в год — все ключевые сценарии.
Блок 5 · Инциденты ч.299 / 103
5.11 · Связь инцидент-менеджмента с другими процессами

Звезда взаимосвязей

ЦЕНТРИнцидент-менеджмент 1Риск-менеджментИнциденты → модель угроз 2Управление уязвимостямиРеактивная + превентивная 3Change managementИзменения → инциденты 4BCM / DRPТяжёлые инциденты → BCP 5Обучение и осведомлённостьПользователи — первый рубеж 6СУИБ (ISO 27001)Обязательный домен
Блок 5 · Инциденты ч.2100 / 103
5.12 · По мотивам Н. Нашивочникова, «Information Security» №4, 2025

Зрелость ИБ vs «иллюзия устойчивости»

Зрелая ИБ-функция
  • Документация = реальная практика, без разрыва.
  • Метрики собираются, анализируются, влияют на решения.
  • Учения проводятся регулярно, выявляют проблемы — и они закрываются.
  • Бюджет ИБ обоснован риск-моделью, а не запросом «нам нужны новые железки».
  • Руководство понимает, какие риски приняты осознанно, а какие устранены.
Иллюзия устойчивости
  • «У нас всё аттестовано» — без понимания, что аттестовано в момент X.
  • «Мы купили <решение>» — без интеграции в процесс.
  • «У нас есть SOC» — но MTTD больше суток, MTTR — недель.
  • «Регуляторы нас никогда не штрафовали» — но проверок не было.
  • Метрики ИБ декларируются, но никто не анализирует тенденции.
Главная цель курсаОтличать зрелость от иллюзии и строить именно зрелые процессы — а не закрывать чек-листы для проверки.
Блок 5 · Инциденты ч.2101 / 103
5.13 — 5.16 · Завершение блока 5

Новые подходы, практические рекомендации, контрольные вопросы

5.13Новые подходы (А. Хафизов, «Information Security» №4, 2025)
Deception
Расстановка ловушек
Honeypot, honeyfile, honeytoken на всех уровнях. Атакующий тратит время, защитник — получает индикаторы.
MTD
Moving Target Defense
Постоянное изменение параметров инфраструктуры (адреса, маршруты, протоколы). Атакующий не успевает зафиксировать цель.
Entropy
Entropy injection
Внесение случайности (рандомизация памяти, конфигов). В лабораторных условиях — снижение вероятности успешной атаки >90%.

На практике для ЗОКИИ применяются ограниченно — требования к стабильности и документируемости конфигураций.

5.158 практических рекомендаций
  • Начните с малого: пилот SIEM на 6 — 12 источников, один-два плейбука, базовая регистрация инцидентов.
  • Подключитесь к ГосСОПКА — даже если до сих пор «информировали только по факту».
  • Запустите программу осведомлённости: фишинг-симуляции, обучение пользователей.
  • Проведите первый table-top exercise — даже без бюджета: 2 часа в переговорной с командой.
  • Считайте метрики хотя бы по 2 — 3 показателям, ведите тренд.
  • Документируйте каждый инцидент, даже мелкий — это база знаний.
  • Делайте постмортемы blameless: цель — научиться, а не наказать.
  • Учитывайте бюджетный цикл: приказ № 117 вступает в силу 01.03.2026; пилоты SIEM — в 2025.
5.16Контрольные вопросы блока 5
  1. Что входит в типовой план реагирования на компьютерные инциденты?
  2. Что такое плейбук? Какие сценарии должны быть покрыты в первую очередь?
  3. Какие виды учений по реагированию применяются?
  4. Опишите процесс управления уязвимостями.
  1. Отличия методики критичности уязвимостей ФСТЭК от 30.06.2025.
  2. Что такое MTTD, MTTR, MTTC?
  3. Как инцидент-менеджмент связан с риск-менеджментом и СУИБ?
  4. Признаки зрелой ИБ-функции и признаки «иллюзии устойчивости».
Блок 5 · Инциденты ч.2102 / 103
Закрытие · резюме дня и контакты

Спасибо.

День I пройден. Впереди — следующие лекции авторского курса. Если возникнут вопросы по материалу — пишите.

📖 Материалы лекции для прочтения
Полные раздаточные материалы в формате Markdown — все 5 блоков, нормативка, контрольные вопросы, глоссарий. Откроется в новой вкладке.
—Что прошли за день
  1. Блок 1 · Риск-менеджмент ИБ — ГОСТ 31000 и 27005, СУРИБ, NIST SP 800-30, OCTAVE, РС БР ИББС.
  2. Блок 2 · КИИ — 187-ФЗ с учётом ФЗ-58 и ФЗ-325; приказы № 235 и № 239; доверенные ПАК.
  3. Блок 3 · Планирование — КСЗИ, PDCA, 8 этапов планирования, связь с бюджетом, кейс приказа № 117.
  4. Блок 4 · Инциденты ч.1 — ГосСОПКА, ГОСТы 597XX, жизненный цикл, SIEM/SOC, команда реагирования.
  5. Блок 5 · Инциденты ч.2 — план, плейбуки, учения, VM, методика 30.06.2025, метрики, зрелость vs иллюзия.
—Что вы теперь умеете
  • Установить контекст оценки рисков ИБ и выбрать подход по критичности систем.
  • Адаптировать базовый набор мер приказа № 239 под актуальные угрозы.
  • Составить план мероприятий по ТЗИ с привязкой к бюджетному циклу.
  • Спроектировать минимальный процесс реагирования: SIEM → плейбуки → команда.
  • Считать MTTD / MTTR / MTTC и отличать зрелую функцию от «иллюзии устойчивости».

Связь с днями II — N курса: риск-методология этого дня станет «языком» для всех последующих тем — от моделирования угроз до сертификации СрЗИ.

—Автор курса

Виталий Александрович Пиков

Преподаватель НОУ ДПО «УЦБИ "МАСКОМ"»

—Учебный центр
Логотип УЦ МАСКОМ

НОУ ДПО «Учебный Центр Безопасности Информации "МАСКОМ"» — программы профессиональной переподготовки и повышения квалификации в области информационной безопасности.

mascom-uc.ru

Закрытие103 / 103