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

Авторская лекция В.А. Пикова, преподавателя НОУ ДПО «УЦБИ «МАСКОМ» (УЦ МАСКОМ).

Полный учебный день — 5 лекций (~7,5 академических часов): риск-менеджмент ИБ → эксплуатация защищённых ИС и объектов КИИ → планирование работ по обеспечению ИБ → управление компьютерными инцидентами (часть 1 и часть 2). Документ объединяет два назначения: **раздаточные материалы для слушателей** и **исходник для подготовки презентации** (~100 слайдов).

---

## Расписание дня (вторник 26.05)

| Блок | Время | Длит. | Тема | Слайды |
|------|-------|-------|------|--------|
| **1** | 09:30 — 11:00 | 1 ч 30 мин | Основы управления рисками ИБ | 4 — 28 |
| ☕ Перерыв | 11:00 — 11:10 | 10 мин | Кофе-брейк | — |
| **2** | 11:10 — 12:40 | 1 ч 30 мин | Эксплуатация защищённых ИС и объектов КИИ | 29 — 53 |
| 🍽 Обед | 12:40 — 13:30 | 50 мин | Обеденный перерыв | — |
| **3** | 13:30 — 15:00 | 1 ч 30 мин | Планирование работ по обеспечению ИБ | 54 — 73 |
| ☕ Перерыв | 15:00 — 15:10 | 10 мин | Кофе-брейк | — |
| **4** | 15:10 — 16:40 | 1 ч 30 мин | Управление компьютерными инцидентами (ч. 1) | 74 — 90 |
| ☕ Перерыв | 16:40 — 16:50 | 10 мин | Кофе-брейк | — |
| **5** | 16:50 — 18:20 | 1 ч 30 мин | Управление компьютерными инцидентами (ч. 2) | 91 — 102 |

**Итого:** 7 ч 30 мин лекционного времени + 50 мин обеда + 3 × 10 мин кофе-перерывов = **8 ч 50 мин**. ~100 слайдов / 103 экрана презентации.

---

## Актуальность нормативки

Документ подготовлен по состоянию на **май 2026 года**. В перечне нормативных правовых актов учтены ключевые изменения 2025–2026 годов, в том числе:

**2025 год:**

- Федеральный закон от 07.04.2025 № 58-ФЗ «О внесении изменений в Федеральный закон „О безопасности критической информационной инфраструктуры Российской Федерации“» (вступил в силу 01.09.2025).
- Федеральный закон от 31.07.2025 № 325-ФЗ (вступает в силу 01.03.2026).
- Приказ ФСТЭК от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу 01.03.2026, заменяет приказ ФСТЭК от 11.02.2013 № 17).
- Методический документ ФСТЭК от 30.06.2025 «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (заменяет редакцию от 28.10.2022).
- Приказ ФСТЭК от 17.07.2025 № 254 (изменения в порядок ведения реестра ЗОКИИ — приказ ФСТЭК № 227; с 01.09.2025).
- Приказ ФСТЭК от 11.07.2025 № 247 (изменения формы направления сведений о категорировании — приказ ФСТЭК № 236).
- Приказы ФСТЭК от 12.05.2025 № 163 и № 164 (лицензионный контроль).
- Приказ ФСБ от 21.07.2025 № 282 (изменения в приказ № 543 о переходном периоде УП-250).

**2026 год (свежие изменения по состоянию на май 2026):**

- **Постановление Правительства от 13.04.2026 № 402** «Об утверждении отраслевых особенностей категорирования объектов критической информационной инфраструктуры в сфере связи» (вступает в силу 01.09.2026). Первый отраслевой подзаконный акт, развивающий ФЗ-58. Вводит расчётный метод и метод моделирования атак; ключевой показатель — количество абонентов.
- **Методический документ ФСТЭК от 12.04.2026** — методические рекомендации к ПП-402 (отраслевая методика категорирования объектов связи).
- **Проект изменений в приказы ФСТЭК № 235 и № 239** (опубликован 07.04.2026, планируемая дата вступления — 01.09.2026). Вводятся два новых показателя: **Кзи** (защищённость значимых объектов КИИ, оценка не реже 1 раза в 6 месяцев) и **Пзи** (уровень зрелости мер безопасности, не реже 1 раза в 2 года). При несоответствии нормированным значениям — уведомление руководителя субъекта в течение 3 календарных дней и направление результатов оценки во ФСТЭК в течение 5 рабочих дней.

Источник базового перечня — «Действующая система НПА по КИИ» по состоянию на 21.08.2025 (Telegram-канал «Бюрократическая безопасность»: t.me/bureaucraticsecurity). Свежие документы 2026 г. — сайт ФСТЭК России (fstec.ru) и КонсультантПлюс.

> **Внимание лектора.** Проект 235/239 на момент дня лекции находится на стадии «принят, не вступил в силу». Слушателям обозначить как **«готовится с 01.09.2026»** — это даёт горизонт планирования на текущий год.

---

# Блок 1. Основы управления рисками ИБ (09:30 — 11:00)

## 1.1. Зачем риск-менеджмент в ИБ

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

Современные методики риск-менеджмента ИБ дают возможность:

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

Без оценки рисков любая ПолИБ — гадание; с оценкой — управляемое решение.

## 1.2. Нормативная база риск-менеджмента

**Общая методология риск-менеджмента:**

- **ГОСТ Р ИСО 31000—2019** «Менеджмент риска. Принципы и руководство» (идентичен ISO 31000:2018). Утверждён приказом Росстандарта от 10.12.2019 № 1379-ст. Действует с 01.03.2020. Заменил ГОСТ Р ИСО 31000—2010.
- **IEC 31010** «Risk management — Risk assessment techniques» (методики оценки риска).
- **ГОСТ Р ИСО 19011—2021** «Руководящие указания по аудиту систем менеджмента».
- **ГОСТ Р 51897—2002** «Менеджмент риска. Термины и определения» (на основе ISO Guide 73:2002; в редакции 2011 г. — ГОСТ Р 51897—2011).
- **ГОСТ Р 51898—2002** «Аспекты безопасности. Правила включения в стандарты».

**Риск-менеджмент в ИБ:**

- **ГОСТ Р ИСО/МЭК 27005—2010** «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности» (идентичен ISO/IEC 27005:2008/2011). Утверждён приказом Росстандарта от 30.11.2010 № 632-ст. Действует с 01.12.2011. Заменил ГОСТ Р ИСО/МЭК ТО 13335-3—2007 и ГОСТ Р ИСО/МЭК ТО 13335-4—2007. **Важно:** Россия пока не приняла переработанную версию ISO/IEC 27005:2018/2022; международный стандарт обновлён, российский ГОСТ остаётся в редакции 2008/2010/2011.
- **ISO/IEC 27001** — Системы менеджмента информационной безопасности. Требования (рамка для СМИБ).
- **ISO/IEC 27002** — Свод правил по менеджменту ИБ (каталог мер).
- **NIST SP 800-30 Rev. 1** «Guide for Conducting Risk Assessments» (NIST RMF, ориентир по детальной методике стадийной оценки рисков, см. п. 1.8.4).
- **BS 7799-3:2006** «Information security management systems. Guidelines for information security risk management» — британский стандарт, послуживший основой ISO/IEC 27005. Содержит четыре фазы непрерывного управления: оценка → обработка → контроль → оптимизация рисков ИБ.

**Российская отраслевая база (банковский сектор):**

- **СТО БР ИББС-1.0-2010** «Обеспечение ИБ организаций банковской системы РФ. Общие положения».
- **РС БР ИББС-2.2-2009** «Методика оценки рисков нарушения ИБ» (для финансовых организаций; использует комбинированную шкалу «СВР — степень возможности реализации» × «СТП — степень тяжести последствий»; даёт количественную форму в процентах от капитала).

**Отраслевая методическая база (РФ):**

- Методические документы ФСТЭК по моделированию угроз (ред. 2021 года, обновляются).
- Руководство ФСТЭК по управлению уязвимостями (от 17.05.2023).
- Методика оценки уровня критичности уязвимостей ПО/ПАК ФСТЭК (от 30.06.2025).
- Методика тестирования обновлений безопасности ФСТЭК (от 28.10.2022).

## 1.3. Термины (ГОСТ Р ИСО 31000—2019 и ГОСТ Р ИСО/МЭК 27005—2010)

**Риск** — следствие влияния неопределённости на достижение поставленных целей. Часто характеризуется парой «событие — последствие» или произведением «вероятность × ущерб».

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

**Менеджмент риска** — скоординированные действия по руководству и управлению организацией в области риска.

**Источник риска** — объект или деятельность, которые самостоятельно или в комбинации с другими обладают возможностью вызывать повышение риска.

**Событие** — возникновение или изменение специфического набора условий (может быть инцидентом, аварией, угрозой).

**Последствие** — результат воздействия события на объект (может быть ранжировано от позитивного до негативного; первоначальные последствия могут эскалироваться по «принципу домино»).

**Правдоподобность (likelihood)** — характеристика возможности и частоты появления события. В контексте ИБ часто используется как «вероятность».

**Влияние (impact)** — неблагоприятное изменение уровня достигнутых бизнес-целей.

**Идентификация риска** — процесс нахождения, составления перечня и описания элементов риска.

**Количественная оценка риска (risk estimation)** — процесс присвоения значений вероятности и последствий риска.

**Сравнительная оценка риска** — сравнение результатов анализа риска с критериями риска для определения приемлемости риска.

**Управление (риском)** — меры, направленные на изменение риска (политика, процессы, устройства, методы).

**Остаточный риск** — риск, оставшийся после обработки риска.

**Принятие риска** — однозначное принятие риска руководством с фиксацией ответственности.

## 1.4. Восемь принципов менеджмента риска (ГОСТ Р ИСО 31000—2019, раздел 4)

1. **Интегрированность** — менеджмент риска неотделим от деятельности организации.
2. **Структурированность и комплексность** — единый подход даёт согласованные и сопоставимые результаты.
3. **Адаптированность** — структура и процесс настраиваются под внешнюю и внутреннюю среду.
4. **Вовлечённость** — надлежащее и своевременное участие причастных сторон.
5. **Динамичность** — риски возникают, меняются и исчезают; реакция должна быть своевременной.
6. **Базирование на наилучшей доступной информации** — исторические, текущие данные и прогнозы.
7. **Учёт поведенческих и культурных факторов** — человек и культура существенно влияют на каждый этап.
8. **Непрерывное улучшение** — обучение и накопление опыта.

## 1.5. Структура менеджмента риска (ГОСТ Р ИСО 31000—2019, раздел 5)

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

Компоненты структуры:

- **Лидерство и приверженность** — высшее руководство выпускает политику, выделяет ресурсы, устанавливает полномочия.
- **Адаптация** — настройка под цели, размер, сложность организации.
- **Проектирование и разработка** — понимание среды, демонстрация приверженности, определение ролей и ответственности, распределение ресурсов, установление механизмов обмена информацией.
- **Внедрение** — разработка плана, определение точек принятия решений, изменение процессов.
- **Оценка эффективности** — периодическая оценка работы структуры.
- **Улучшение** — обновление и постоянное улучшение.

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

## 1.6. Процесс менеджмента риска ИБ (ГОСТ Р ИСО/МЭК 27005—2010, раздел 6)

Полный цикл — итеративный, состоит из следующих этапов:

1. **Установление контекста** (раздел 7 ГОСТ).
2. **Оценка риска** (раздел 8): идентификация → анализ → сравнительная оценка.
3. **Обработка риска** (раздел 9).
4. **Принятие риска** (раздел 10).
5. **Коммуникация риска** (раздел 11) — сквозной этап, проводится на всех остальных.
6. **Мониторинг и переоценка риска** (раздел 12) — сквозной этап.

В фазе **«Планирование»** СМИБ выполняются: установление контекста, оценка риска, планирование обработки, принятие риска. В фазе **«Осуществление»** — реализация плана обработки. В фазе **«Проверка»** — мониторинг и переоценка. В фазе **«Действие»** — улучшение.

## 1.7. Установление контекста менеджмента риска ИБ (раздел 7)

**Цель этапа** может быть:

- поддержка СМИБ (ISO/IEC 27001);
- исполнение законодательно-нормативных требований и проявление «разумной предосторожности»;
- подготовка плана обеспечения непрерывности бизнеса (ОНРБ/BCM);
- подготовка плана реагирования на инциденты;
- описание требований ИБ для продукта/услуги/механизма.

**Основные критерии**, которые должны быть определены ещё до оценки:

- **Критерии оценки рисков** — что считать приоритетом: стратегическая ценность бизнес-информации, критичность затронутых активов, законодательные и договорные обязательства, репутационные риски.
- **Критерии влияния** — степень ущерба или величина расходов: уровень классификации актива, нарушение К/Ц/Д, нарушение оперативной деятельности (своей или третьих сторон), потеря ценности бизнеса, ущерб репутации, нарушение НПА.
- **Критерии принятия риска** — пороги, при которых риск приемлем. Могут включать «целевой уровень + допустимое отклонение», соотношение «выгода / риск», разные шкалы для разных классов риска (нулевая толерантность к нарушению НПА vs допустимые высокие операционные риски при кратковременной активности).

**Область применения и границы** — какие активы, процессы, подразделения, локации, информационные системы попадают в скоп. Границы важны, потому что источники риска могут лежать за ними (поставщик, облако, контрагент).

**Организационная структура** — кто разрабатывает процесс, кто владельцы рисков, как взаимодействуют служба ИБ, ИТ, кадры, СЭБ, юристы, финансы; пути эскалации.

## 1.8. Оценка риска ИБ (раздел 8)

Оценка риска = идентификация + анализ + сравнительная оценка.

### 1.8.1. Идентификация риска

Подэтапы:

1. **Определение активов.** Актив — всё, имеющее ценность для организации. Это не только «железо и софт», но и:
   - информация (БД, файлы, документы, ноу-хау);
   - бизнес-процессы и сервисы;
   - люди (компетенции);
   - репутация и бренд;
   - физическая инфраструктура (помещения, кабели, энергоснабжение).
   У каждого актива должен быть **владелец** — лицо, отвечающее за получение, разработку, поддержку, использование и безопасность актива (см. приложение В ГОСТ 27005).

2. **Определение угроз.** Угроза может быть:
   - природной (пожар, наводнение, землетрясение);
   - техногенной (отказ оборудования, сбой ПО);
   - человеческой случайной (ошибка пользователя/администратора);
   - человеческой умышленной (внутренний нарушитель, внешний атакующий, организованная группа, спецслужбы).
   Источники данных по угрозам: внутренние инциденты, отраслевая статистика, БДУ ФСТЭК, открытые источники, CERT-сообщества (см. приложение С ГОСТ 27005).

3. **Определение существующих мер и средств управления (controls).** Что уже есть, насколько работает, не дублируется ли. Цель — не «открывать заново», а строить от текущего состояния.

4. **Определение уязвимостей.** Уязвимость — свойство актива, делающее возможным реализацию угрозы. Существуют:
   - организационные уязвимости (отсутствие политик, регламентов, обучения);
   - технические (непропатченное ПО, конфигурационные ошибки, слабая аутентификация);
   - физические (отсутствие СКУД, плохая физическая защита помещений);
   - человеческие (низкая осведомлённость, корпоративная культура «безопасность мешает работе»).
   Источники: сканеры (БДУ ФСТЭК, NVD, отраслевые БД), пентесты, аудиты конфигураций (см. приложение D).

5. **Определение последствий.** Что произойдёт, если угроза реализуется через уязвимость? Финансовые потери, штрафы, простой бизнеса, утечка ПДн (последствия по 152-ФЗ), нарушение режима гостайны, репутационный ущерб, угроза жизни/здоровью.

### 1.8.2. Анализ риска

Анализ может быть:

- **Качественным** — описательные шкалы («низкий/средний/высокий»). Применяется на ранних этапах, когда нет данных, или для приоритизации.
- **Количественным** — числовые значения вероятности и ущерба. Требует исторических данных или экспертных оценок. Позволяет считать ALE (Annualized Loss Expectancy) и сравнивать варианты обработки.
- **Полуколичественным** — числовые шкалы поверх качественных категорий.

Подходы (см. приложение Е ГОСТ 27005):

- **Базовый подход** — применение типового набора мер из каталога (например, ISO 27002, Приказ 17/117, Приказ 21, Приказ 239). Быстро, дёшево, не учитывает специфики.
- **Неформальный** — экспертная оценка без формальной методики. Подходит только для малых, не критичных систем.
- **Детальный** — полное моделирование «актив → угроза → уязвимость → последствие → вероятность». Дорого, но даёт обоснованные решения для критичной инфраструктуры.
- **Комбинированный** — высокоуровневая оценка всей организации + детальная оценка приоритетных активов. На практике применяется чаще всего.

### 1.8.3. Сравнительная оценка риска

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

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

Результат сравнительной оценки **документируется** и доводится до причастных сторон.

## 1.9. Обработка риска ИБ (ГОСТ Р ИСО/МЭК 27005—2010, раздел 9; ГОСТ Р ИСО 31000—2019, п. 6.5)

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

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

Дополнительные варианты ГОСТ 31000:

- принятие или увеличение риска для использования благоприятной возможности;
- устранение источника риска;
- изменение вероятности;
- изменение последствий.

**Важно про передачу:** аутсорсинг и страхование переносят финансовый ущерб, но не репутационный и не юридическую ответственность по 152-ФЗ, 187-ФЗ, гостайне. Оператор ПДн отвечает перед субъектом ПДн, даже если обработку ведёт процессор.

**План обработки риска** включает:

- обоснование выбора варианта обработки и ожидаемые выгоды;
- ответственных за утверждение и реализацию;
- предлагаемые действия;
- требуемые ресурсы (включая непредвиденные);
- показатели эффективности;
- ограничения;
- требования к отчётности и мониторингу;
- сроки реализации и завершения.

**Остаточный риск** после обработки должен быть задокументирован и принят руководством.

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

**Принятие риска** — формальное решение уполномоченного лица (как правило, владелец актива или представитель руководства). Без подписи под остаточным риском процесс не закрыт.

**Коммуникация риска** — обмен информацией о риске между владельцем риска, владельцем актива, лицом, принимающим решения, и причастными сторонами. Включает обучение, информирование, отчётность. Без коммуникации сотрудники не понимают, зачем меры — и обходят их.

**Мониторинг и переоценка** — постоянная деятельность, поскольку среда меняется: новые активы, новые угрозы (новый CVE, новая APT, изменение мотивации нарушителя), новые уязвимости, изменение бизнес-целей и законодательства. Переоценка обязательна:

- при существенном изменении инфраструктуры или бизнес-процессов;
- после крупного инцидента (свой или отраслевой);
- при изменении нормативки;
- по плану (например, ежегодно).

## 1.11. Документальное обеспечение СУРИБ

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

- **Политика управления рисками ИБ** — высокоуровневый документ, утверждаемый руководством.
- **Методика оценки и обработки рисков ИБ** — детальный регламент: шкалы, формулы, ответственные.
- **Реестр активов** — с владельцами, ценностью, классификацией.
- **Реестр угроз** — отраслевой и внутренний.
- **Реестр уязвимостей** — с приоритизацией.
- **Карта рисков** — матрица «вероятность × ущерб», с цветовой кодировкой.
- **План обработки рисков** — с действиями, ответственными, сроками.
- **Протоколы принятия остаточных рисков** — подписанные руководством.
- **Отчёты по мониторингу** — периодические.

## 1.12. Инструментальные средства

Российские:

- «Гриф» (Digital Security) — оценка рисков ИБ;
- АванГард (АО «НТЦ Атлас») — анализ защищённости и рисков;
- модули риск-менеджмента в SGRC-платформах (R-Vision, Security Vision).

Международные (для справки, доступность под санкциями ограничена):

- RSA Archer GRC;
- ServiceNow GRC;
- IBM OpenPages.

Также для отдельных шагов используются: сканеры уязвимостей (MaxPatrol VM, ScanOVAL, RedCheck), системы инвентаризации активов, BCM-платформы.

## 1.13. Связь с СУИБ (ISO/IEC 27001, ISO/IEC 27002)

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

- решения о выборе мер защиты (Statement of Applicability — SoA в ISO 27001) принимаются на основе оценки риска;
- цели ИБ, целевые показатели (KPI) и KRI выбираются исходя из приоритетных рисков;
- бюджет на ИБ обосновывается через расчётный ущерб;
- аудит СУИБ (ISO 19011) — это в т.ч. аудит риск-процессов.

## 1.14. СУРИБ — система управления рисками ИБ

(По материалам учебника: Милославская Н.Г., Сенаторов М.Ю., Толстой А.И. «Управление рисками информационной безопасности», 2-е изд., М.: Горячая линия–Телеком, 2014.)

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

**Три составляющие СУРИБ:**

1. **Совокупность формализованных процессов** — от анализа и планирования до проверки и совершенствования (PDCA).
2. **Документальное обеспечение** — политика управления рисками ИБ, методология оценки рисков ИБ, план обработки рисков ИБ, декларация о применимости (SoA), реестр рисков, протоколы принятия остаточных рисков.
3. **Квалифицированные кадры и трёхуровневая организационная структура.**

### Три уровня организационной структуры СУРИБ

| Уровень | Кто | Что делает |
|---------|-----|-----------|
| **Верхний** | Коллегиальный орган (риск-комитет, инвестиционный комитет) | Принимает решения по конкретным рискам ИБ. Утверждает процедуры передачи полномочий вниз. |
| **Средний** | Специальные подразделения контроля | Контролируют исполнение установленных процедур остальными подразделениями. |
| **Нижний** | Подразделения-исполнители | Совершают действия по управлению рисками в рамках своей повседневной деятельности. |

### Четыре режима работы СУРИБ

- **Обычный режим** — действует по умолчанию в нормальных условиях ведения бизнеса.
- **Режим контроля** — применяется к отдельному подразделению при накоплении сигналов о концентрации рисков ИБ, по особым решениям руководства.
- **Чрезвычайный режим** — применяется ко всей организации при сигнале о превышении допустимого уровня концентрации рисков.
- **Режим отладки** — испытание новых продуктов, процедур, элементов СУРИБ; устанавливается решением руководства.

### Ключевые роли в СУРИБ

- **Риск-менеджер** — владелец процесса. Несёт ответственность за формирование и поддержание ключевых документов (реестра рисков, плана их обработки), осуществляет общий контроль, обеспечивает соответствие требованиям стандартов. При отсутствии должности риск-менеджера обязанности возлагают на руководителя службы ИБ (CISO).
- **Эксперт по оценке рисков ИБ** — практик, выполняющий оценку. Должен обладать: пониманием бизнеса и его подверженности рискам; пониманием концепций риска ИБ; пониманием ИТ; пониманием типов защитных мер (МЭ, СОВ, ИАФ, контроль доступа, шифрование, видеонаблюдение, регистрация событий, мониторинг); владением методом оценки и инструментами; аналитическими и коммуникативными способностями.
- **Владельцы активов** — отвечают за конкретные информационные активы, участвуют в оценке их ценности и критичности.
- **Руководители подразделений** — поддержка и непосредственное участие в оценке рисков для активов, владельцами которых они являются.
- **Высшее руководство** (Президент / Генеральный директор / CEO) — координирует корпоративную программу управления рисками ИБ, утверждает план обработки рисков ИБ, принимает решение по допустимому уровню остаточного риска.

## 1.15. Три подхода к управлению рисками в зависимости от критичности систем

Поскольку риски ИБ не во всех организациях рассматриваются как одни из основных, можно условно выделить три подхода к управлению рисками ИБ:

1. **Для некритичных (вспомогательных для бизнеса) систем** — применяются стандартные требования по ОИБ, определяемые законодательством, стандартами, лучшими практиками. По сути, **базовый подход** из ГОСТ 27005 (типовой набор мер из каталога).
2. **Для критичных систем** — особое внимание системам с наибольшими рисками. Требуется **высокоуровневая оценка** рисков с неформальными качественными подходами.
3. **Для особо критичных систем** — необходима **детальная оценка** рисков для всех активов с количественной (или комбинированной) шкалой.

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

## 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.17. Метод OCTAVE (CMU CERT)

**OCTAVE** (Operationally Critical Threat, Asset, and Vulnerability Evaluation) — методология оценки критичных угроз, активов и уязвимостей, разработанная в Software Engineering Institute (SEI) университета Карнеги-Меллона (США), при участии CERT. См. www.cert.org/octave (с поправкой на санкционные ограничения доступа).

**Особенность метода:** оценка проводится не консультантами, а **самой организацией** через серию внутренних семинаров (workshops). Это снижает зависимость от внешних экспертов и повышает «прививаемость» процесса.

### Три этапа OCTAVE

1. **Разработка профилей угроз ИБ** — инвентаризация и оценка ценности активов, идентификация применимых требований законодательства и нормативной базы, идентификация угроз ИБ и оценка их вероятности, определение системы организационных мер по ОИБ.
2. **Технический анализ уязвимостей** — анализ уязвимостей ИС в отношении рассматриваемых угроз с оценкой их величины.
3. **Оценка и обработка рисков ИБ** — определение величины и вероятности ущерба, выбор стратегии ОИБ, принятие решений по обработке. Величина риска ИБ рассчитывается как **усреднённая величина годовых потерь** организации (ALE — Annualized Loss Expectancy) в результате реализации угроз ИБ.

Метод применим к организациям разного размера и сферы деятельности. Существуют варианты OCTAVE-S (для малых организаций), OCTAVE Allegro (упрощённая версия).

## 1.18. РС БР ИББС-2.2-2009 — банковский подход

Стандарт Банка России **СТО БР ИББС-1.0** и рекомендация **РС БР ИББС-2.2-2009** дают развёрнутую методику оценки рисков нарушения ИБ применительно к банкам и иным финансовым организациям. Из учебника Милославской взято следующее обобщение, применимое к организациям любого профиля.

### Базовая модель

Активы рассматриваются совместно с **материальными объектами среды** их использования (объекты хранения, передачи, обработки, уничтожения). Угрозы ИБ реализуются их источниками, воздействующими на объекты среды.

**Риск ИБ = СВР × СТП**, где:

- **СВР** — степень возможности реализации угрозы ИБ;
- **СТП** — степень тяжести последствий нарушения ИБ.

### Качественная шкала СВР

«Нереализуемая — Минимальная — Средняя — Высокая — Критическая».

### Качественная шкала СТП

«Минимальная — Средняя — Высокая — Критическая».

### Таблица допустимости рисков

Сопоставление СВР × СТП даёт оценку «Допустимый / Недопустимый». Например, «Минимальная СВР × Минимальная СТП = Допустимый», а «Критическая СВР × Критическая СТП = Недопустимый».

### Количественная шкала (для оценки в денежной форме)

Для формирования резервов на возможные потери:

**СВРкол** (в процентах):
- Нереализуемая — 0%
- Минимальная — 1–20%
- Средняя — 21–50%
- Высокая — 51–100%
- Критическая — 100%

**СТПкол** (в процентах от величины капитала организации):
- Минимальная — до 0,5%
- Средняя — 0,5–1,5%
- Высокая — 1,5–3%
- Критическая — более 3%

**Количественный риск ИБ** = СВРкол × СТПкол (в денежной форме). Суммарная оценка рисков ИБ организации = сумма по всем отдельным рискам. **Размер резерва на возможные потери** рекомендуется принимать равным суммарной количественной оценке риска ИБ.

### 6 процедур качественной оценки рисков ИБ по РС БР ИББС-2.2-2009

1. Определение и документирование перечня типов активов области оценки.
2. Определение перечня типов объектов среды для каждого типа активов.
3. Определение источников угроз ИБ для каждого типа объектов среды (на основе модели угроз).
4. Оценка СВР угроз ИБ для выделенных типов объектов среды.
5. Оценка СТП нарушения ИБ для типов активов области.
6. Оценка рисков ИБ (Допустимые/Недопустимые) с документальной фиксацией.

Подход РС БР ИББС-2.2-2009 — пример того, как абстрактная методология ISO/IEC 27005 трансформируется в конкретные шкалы и таблицы, понятные владельцу бизнеса. Аналогичный подход применим в любой отрасли.

## 1.19. Шесть типов рисков в проектах разработки ПО

Применительно к проектам разработки ПО учебник Милославской выделяет 6 типов рисков, влияющих в конечном счёте на ИБ:

1. **Технические риски** — разработка новых решений или изменение старых для повышения производительности / новой функциональности.
2. **Программные риски** — приобретение или использование ПО третьих фирм без должного контроля.
3. **Риски сопровождения** — размещение ПО у заказчика, поддержка, обучение.
4. **Стоимостные риски** — превышение затрат, проблемы финансирования.
5. **Риски сроков** — необходимость ускорить разработку из-за внешних причин.
6. **Риски неудовлетворённости заказчика.**

Эти категории особенно важны для процессов РБПО (ГОСТ Р 56939-2024) и при подготовке к сертификации СрЗИ по приказам ФСТЭК.

## 1.20. Четыре метода идентификации рисков

Учебник Милославской выделяет четыре классических метода идентификации рисков ИБ:

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

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

## 1.21. Типовые ошибки на практике

- Оценка рисков «для бумаги», без связи с реальными решениями.
- Карта рисков превращается в «красное всё» — потому что критерии приёмки занижены.
- Отсутствие владельцев рисков: «риск есть, но он ничей».
- Не учитываются риски третьих сторон (поставщики, ЦОД, облака, аутсорсеры).
- Однократная оценка без переоценки: реестр стареет за полгода.
- Передача риска воспринимается как «всё, мы в безопасности» (см. п. 1.9 про репутацию и юридическую ответственность).
- Нет коммуникации: оценка рисков лежит у CISO, а владельцы активов о ней не знают.
- Отсутствует связь риск-менеджмента с инцидент-менеджментом: уроки инцидентов не возвращаются в реестр угроз.

## 1.22. Контрольные вопросы блока 1

1. В чём разница между «риском» по ГОСТ 31000 и «риском ИБ» по ГОСТ 27005?
2. Перечислите 8 принципов менеджмента риска по ГОСТ 31000—2019.
3. Перечислите этапы процесса риск-менеджмента по ГОСТ 27005—2010.
4. Назовите 4 классических варианта обработки риска ИБ.
5. Кто такой «владелец актива» и «владелец риска» — это одно лицо?
6. Что такое остаточный риск и кто его принимает?
7. Каковы три критерия в установлении контекста?
8. Когда применяется качественная оценка, а когда количественная?
9. Из каких трёх составляющих состоит СУРИБ?
10. Назовите три уровня организационной структуры СУРИБ и четыре режима её работы.
11. Кто такой риск-менеджер и какие задачи он решает?
12. Перечислите 9 стадий оценки рисков по NIST SP 800-30.
13. Что такое метод OCTAVE и каковы его три этапа?
14. Как считается риск ИБ по методике РС БР ИББС-2.2-2009? Какие шкалы СВР и СТП используются?
15. Какие три подхода применяются в зависимости от критичности систем?
16. Назовите 4 метода идентификации рисков.

---

> ### 🏁 Конец блока 1 — 11:00
>
> Блок «Основы управления рисками ИБ» завершён.
>
> ### ☕ Перерыв: 11:00 — 11:10 (10 минут)
>
> Кофе-брейк перед блоком 2.

---

# Блок 2. Эксплуатация защищённых ИС и объектов КИИ (11:10 — 12:40)

> ### ▶ Начало блока 2 — 11:10
>
> Тема: эксплуатация защищённых информационных систем и значимых объектов критической информационной инфраструктуры.

## 2.1. Понятие защищённой ИС и КИИ

**Защищённая информационная система** — информационная система, в которой реализован комплекс организационных и технических мер защиты информации в соответствии с её классом защищённости и категорией обрабатываемой информации.

В нашем регуляторном поле «защищённой» становится ИС:

- класса защищённости по приказу ФСТЭК (для ГИС — приказ 17 → с 01.03.2026 приказ 117; для ИСПДн — приказ 21);
- категории значимости значимого объекта КИИ (для ЗОКИИ — приказ ФСТЭК 235 на систему безопасности и приказ 239 на меры);
- класса автоматизированных систем по гостайне (для АС, обрабатывающих сведения, составляющие гостайну, — отдельная база, не входит в этот курс).

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

**Объект КИИ** — информационная система, информационно-телекоммуникационная сеть или автоматизированная система управления, функционирующая в одной из сфер КИИ (см. перечень сфер ниже).

**Субъект КИИ** — юридическое лицо (с 01.09.2025 — только ЮЛ, ИП исключены), которому на законном основании принадлежат или у которого на иных законных основаниях находятся объекты КИИ, функционирующие в сферах КИИ.

**Значимый объект КИИ (ЗОКИИ)** — объект КИИ, которому присвоена одна из категорий значимости (1, 2 или 3).

## 2.2. Сферы функционирования КИИ (187-ФЗ, статья 2)

Объекты КИИ функционируют в следующих сферах:

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

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

## 2.3. Нормативная база КИИ (ключевые документы по состоянию на май 2026)

### 2.3.1. Федеральное законодательство

- **Федеральный закон от 26.07.2017 № 187-ФЗ** «О безопасности критической информационной инфраструктуры Российской Федерации» (в действующей редакции с учётом изменений ФЗ от 10.07.2023 № 312-ФЗ, ФЗ от 07.04.2025 № 58-ФЗ, ФЗ от 31.07.2025 № 325-ФЗ).
- **Федеральный закон от 26.07.2017 № 193-ФЗ** — пакетные изменения в смежное законодательство.
- **Федеральный закон от 26.07.2017 № 194-ФЗ** — изменения в УК РФ и УПК РФ (введена ст. 274.1 УК — атаки на КИИ).

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

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

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

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

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

- **Приказ от 06.12.2017 № 227** — Порядок ведения реестра ЗОКИИ (с учётом изменений приказов ФСТЭК от 10.02.2022 № 26, от 01.09.2023 № 177, от 17.07.2025 № 254).
- **Приказ от 21.12.2017 № 235** — Требования к созданию систем безопасности ЗОКИИ (с учётом приказов от 27.03.2019 № 64 и от 20.04.2023 № 69).
- **Приказ от 22.12.2017 № 236** — Форма направления сведений о категорировании (с учётом приказа от 21.03.2019 № 59 и приказа от 11.07.2025 № 247).
- **Приказ от 25.12.2017 № 239** — Требования по обеспечению безопасности ЗОКИИ (с учётом приказов от 09.08.2018 № 138, от 26.03.2019 № 60, от 20.02.2020 № 35, от 28.08.2024 № 159).
- **Приказ от 11.12.2017 № 229** — Форма акта проверки.
- **Приказ от 16.07.2019 № 135** — Перечень НПА для целей государственного контроля.
- **Приказ от 28.05.2020 № 75** — Порядок согласования подключения ЗОКИИ к сетям общего пользования.
- **Приказ от 18.04.2021 № 77** — Порядок аттестации объектов информатизации.
- **Приказ от 11.04.2025 № 117** — Требования о защите информации в ГИС, иных ИС госорганов, ГУП и госучреждений (вступает в силу 01.03.2026; заменит приказ от 11.02.2013 № 17). По сути расширяет действие требований на МИС и системы ГУП/госучреждений.
- **Приказы от 12.05.2025 № 163 и № 164** — лицензионный контроль ТЗКИ и разработки/производства СЗКИ.
- **Проект изменений в приказы № 235 и № 239** (опубликован 07.04.2026, планируемое вступление в силу — 01.09.2026). Вводит два новых показателя для ЗОКИИ:
  - **Кзи** — показатель защищённости значимого объекта КИИ; оценивается не реже **1 раза в 6 месяцев**;
  - **Пзи** — показатель уровня зрелости мер безопасности; оценивается не реже **1 раза в 2 года**.

  При несоответствии нормированным значениям субъект КИИ обязан в течение **3 календарных дней** проинформировать руководителя организации, а в течение **5 рабочих дней** после расчёта — направить результаты во ФСТЭК. По сути это требование непрерывного самомониторинга защищённости — продолжение линии «непрерывного контроля» из приказа № 117.

### 2.3.5. Приказы ФСБ

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

### 2.3.6. ГОСТы по КИИ и компьютерным инцидентам

- **ГОСТ Р 59548—2022** «Защита информации. Регистрация событий безопасности. Требования к регистрируемой информации».
- **ГОСТ Р 59709—2022** «Защита информации. Управление компьютерными инцидентами. Термины и определения».
- **ГОСТ Р 59710—2022** «Защита информации. Управление компьютерными инцидентами. Общие положения».
- **ГОСТ Р 59711—2022** «Защита информации. Управление компьютерными инцидентами. Организация деятельности по управлению компьютерными инцидентами».
- **ГОСТ Р 59712—2022** «Защита информации. Управление компьютерными инцидентами. Руководство по реагированию на компьютерные инциденты».
- **ГОСТ Р 70732—2023** — функциональная и информационная безопасность ПО АСУ ТП железнодорожного транспорта.
- **ПНСТ 905—2023** «КИИ. Доверенные ПАК. Термины и определения».
- **ПНСТ 911—2024** «КИИ. Доверенные интегральные микросхемы и электронные модули. Общие положения».
- **ПНСТ 1007—2025** «КИИ. ПАК. Классификация по назначению».
- **ПНСТ 1009—2025** «КИИ. ПО для доверенных ПАК. Общие положения».

### 2.3.7. Методические документы ФСТЭК

- Методика оценки уровня критичности уязвимостей ПО/ПАК (от 30.06.2025, заменила версию от 28.10.2022).
- Методика тестирования обновлений безопасности (от 28.10.2022).
- Методика оценки показателя состояния защиты информации и обеспечения безопасности объектов КИИ РФ (от 02.05.2024).
- Руководство по организации процесса управления уязвимостями (от 17.05.2023).
- Рекомендации по подготовке планов мероприятий при установлении уровней опасности целевых атак (от 09.08.2021).
- Рекомендации по разработке Плана реагирования на компьютерные инциденты на ЗОКИИ.

## 2.4. Категорирование объектов КИИ (ПП № 127, с изм.)

**Этапы категорирования:**

1. **Создание комиссии по категорированию** — приказом руководителя субъекта КИИ.
2. **Формирование перечня объектов КИИ**, подлежащих категорированию.
3. **Направление перечня** во ФСТЭК (письмо ФСТЭК уточняет порядок — см. серию инфосообщений 2018–2025 гг.).
4. **Сбор сведений** об объектах: характеристики, состав, технологические процессы, угрозы и нарушители.
5. **Оценка показателей значимости** по 5 группам критериев и определение категории значимости.
6. **Оформление акта категорирования** с обоснованием категории.
7. **Направление сведений** во ФСТЭК (приказ № 236 + приказ от 11.07.2025 № 247).
8. **Внесение в реестр ЗОКИИ** (приказ № 227).

**Группы показателей критериев значимости** (ПП № 127):

- **Социальная значимость** — вред жизни и здоровью людей, прекращение или нарушение функционирования объектов жизнеобеспечения, транспорта, связи, нарушение предоставления государственных услуг.
- **Политическая значимость** — нарушение функционирования госорганов.
- **Экономическая значимость** — прямой и косвенный ущерб бюджету и субъектам КИИ.
- **Экологическая значимость** — вред окружающей среде.
- **Значимость для обороны страны, безопасности и правопорядка.**

**Категории значимости:**

- **Категория 1** — высшая (системы национального значения, наиболее жёсткие требования).
- **Категория 2** — средняя.
- **Категория 3** — низшая.

Объект без присвоенной категории не является ЗОКИИ, но остаётся объектом КИИ и попадает в общую систему ГосСОПКА (информирование о компьютерных инцидентах).

**Отраслевые особенности категорирования** (вводятся с 01.09.2025 на уровне Правительства РФ):

- **Сфера связи — уже принято: ПП от 13.04.2026 № 402** (вступает 01.09.2026). Расчётный метод и метод моделирования атак, ключевой показатель — количество абонентов. Сопровождающая методика ФСТЭК от 12.04.2026.
- сфера ТЭК (Минэнерго);
- сфера химической промышленности (Минпромторг);
- сфера здравоохранения (Минздрав);
- сфера науки (Минобрнауки);
- сфера оборонной, металлургической промышленности (Минпромторг);
- ракетно-космическая (Роскосмос — проект ПП от 02.07.2025);
- транспорт (Минтранс).

После сферы связи ожидаются аналогичные постановления по другим сферам — следует отслеживать публикации.

## 2.5. Требования к системе безопасности ЗОКИИ (Приказ ФСТЭК № 235)

Система безопасности ЗОКИИ должна обеспечивать:

- предотвращение неправомерного доступа, уничтожения, модификации, блокирования, копирования, предоставления и распространения информации;
- недопущение воздействия на технические средства обработки информации, в результате которого может быть нарушено и/или прекращено функционирование ЗОКИИ;
- восстановление функционирования ЗОКИИ;
- непрерывное взаимодействие с ГосСОПКА.

**Состав системы безопасности:**

- организационно-распорядительные документы по обеспечению безопасности (политики, регламенты, инструкции);
- структурные подразделения (или лица), ответственные за обеспечение безопасности;
- технические меры защиты (СЗИ, средства обнаружения и реагирования, средства ГосСОПКА).

**Документация системы безопасности:**

- Документы, определяющие цели и задачи обеспечения безопасности.
- Документы, регламентирующие категорирование.
- Документы по моделированию угроз.
- Проектная документация на систему безопасности.
- Эксплуатационная документация.
- ОРД по реагированию на инциденты и взаимодействию с ГосСОПКА.

## 2.6. Требования по обеспечению безопасности ЗОКИИ (Приказ ФСТЭК № 239)

Меры защиты группируются в подсистемы. Базовые группы мер (упрощённо):

- **Идентификация и аутентификация** (ИАФ).
- **Управление доступом** (УПД).
- **Ограничение программной среды** (ОПС).
- **Защита машинных носителей информации** (ЗНИ).
- **Аудит безопасности** (АУД).
- **Антивирусная защита** (АВЗ).
- **Предотвращение вторжений** (СОВ/IPS).
- **Контроль (анализ) защищённости** (АНЗ).
- **Обеспечение целостности** (ОЦЛ).
- **Обеспечение доступности** (ОДТ).
- **Защита технических средств** (ЗТС).
- **Защита информационной (автоматизированной) системы и её компонентов** (ЗИС).
- **Управление конфигурацией** (УКФ).
- **Управление обновлениями** (ОПО).
- **Реагирование на инциденты** (ИНЦ).
- **Управление непрерывностью** (ОНРБ).
- **Обеспечение действий в нештатных ситуациях** (ДНС).
- **Информирование и обучение персонала** (ИПО).

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

**Принцип:** меры приказа 239 — это не «бумажные» меры, а функции, которые должны быть реально реализованы в системе. Для каждой меры разрабатываются процедуры, фиксируются ответственные, проверяется эффективность.

> **Готовится с 01.09.2026.** Проект изменений в приказы № 235 и № 239 (опубликован 07.04.2026) вводит для ЗОКИИ показатели **Кзи** (защищённости, оценка не реже 1 раза в 6 мес.) и **Пзи** (зрелости мер безопасности, не реже 1 раза в 2 года) с обязательной отчётностью во ФСТЭК в 5-дневный срок при несоответствии нормам. Это закрепляет переход от «однажды аттестовали» к непрерывному самомониторингу.

## 2.7. Государственный контроль ЗОКИИ (ПП № 162, Приказ ФСТЭК № 229, № 135)

Государственный контроль осуществляет ФСТЭК. Виды проверок:

- **Плановые** — по утверждённому плану (включают документарную и выездную часть).
- **Внеплановые** — по обращениям, по фактам нарушений, после инцидентов.

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

**Документы по итогам:**

- Акт проверки (форма — приказ ФСТЭК № 229).
- Предписание об устранении нарушений.
- В случае выявления административных правонарушений — материалы для составления протокола (КоАП РФ).

## 2.8. Технологическая независимость КИИ (Указ № 166, Указ № 250, ПП № 1478, ПП № 1912)

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

- **Указ № 166** — запрет с 31.03.2022 на закупку иностранного ПО для ЗОКИИ без согласования; с 01.01.2025 — запрет использования иностранного ПО на ЗОКИИ.
- **Указ № 250** — назначение зам. руководителя по ИБ; передача функций по ИБ внутрь организации; меры по реагированию на компьютерные атаки.
- **ПП № 1478** — детальные требования к ПО (в т.ч. в составе ПАК) на ЗОКИИ; правила согласования закупок иностранного ПО; правила перехода на российское ПО.
- **ПП № 1912** — переход субъектов КИИ на доверенные ПАК на ЗОКИИ.

**Доверенный ПАК** (по ПНСТ 905—2023, ПП № 1912) — программно-аппаратный комплекс, соответствующий одновременно всем критериям:

1. Сведения о ПАК содержатся в едином реестре российской радиоэлектронной продукции.
2. ПАК соответствует предъявленному комплексу требований к ПО.
3. ПАК в случае реализации функций ЗИ соответствует требованиям ФСТЭК и/или ФСБ (подтверждается сертификатом).

**Архитектура доверенного ПАК** (по материалам В. Карантаева, НЭК.ТЕХ):

- доверенная аппаратная база (SoC + аппаратный корень доверия / СКЗИ);
- средства доверенной загрузки (Secure Boot, Encrypted Boot);
- защищённая встраиваемая ОС;
- прикладное ПО с реализованными функциями безопасности;
- ПО СКЗИ.

## 2.9. ФЗ-58 (с 01.09.2025) и ФЗ-325 (с 01.03.2026) — ключевые изменения

**ФЗ-58 от 07.04.2025 (с 01.09.2025):**

- Индивидуальные предприниматели исключаются из числа субъектов КИИ.
- Правительство уполномочено утверждать перечни типовых отраслевых объектов КИИ и отраслевые особенности категорирования.
- Закреплены требования к применяемому ПО, в т.ч. переход на ПО из российского реестра.

**ФЗ-325 от 31.07.2025 (с 01.03.2026):**

- Субъектами КИИ могут быть только российские юридические лица, находящиеся под контролем граждан РФ, органов государственной власти или муниципальных образований.
- Минцифры формирует и ведёт перечень российских программ для ЭВМ и БД, разработанных и используемых для собственных нужд российскими ЮЛ. Использование такого ПО приравнено к выполнению требования об использовании ПО из единого реестра российских программ.

## 2.10. Реальная эксплуатация защищённого объекта: что меняется на местах

Эксплуатация защищённого объекта — это не «однажды настроили и забыли». Ключевые задачи эксплуатации:

1. **Сопровождение системы безопасности** — обновление СЗИ, проверка работоспособности, реакция на сбои.
2. **Управление конфигурацией** — фиксация эталонных конфигураций, контроль изменений, ревью при изменении инфраструктуры.
3. **Управление обновлениями** — патч-менеджмент с тестированием обновлений (методика ФСТЭК от 28.10.2022). Скорость закрытия критических уязвимостей — KPI для CISO.
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?
5. Назовите основные группы мер по приказу ФСТЭК № 239.
6. Что такое доверенный ПАК и какие 3 критерия должен соблюдать?
7. Какие документы по итогам государственного контроля по ПП № 162?
8. Чем отличается ЗОКИИ от объекта КИИ без категории значимости?

---

> ### 🏁 Конец блока 2 — 12:40
>
> Блок «Эксплуатация защищённых ИС и объектов КИИ» завершён. Утренняя половина дня позади.
>
> ### 🍽 Обеденный перерыв: 12:40 — 13:30 (50 минут)
>
> После обеда — блок «Планирование работ по обеспечению ИБ».

---

# Блок 3. Планирование работ по обеспечению информационной безопасности (13:30 — 15:00)

> ### ▶ Начало блока 3 — 13:30
>
> Тема: комплексная система защиты информации (КСЗИ), цикл PDCA, восемь этапов планирования по ТЗИ, привязка к бюджетному циклу.

## 3.1. Комплексная система защиты информации (КСЗИ)

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

- категории информации (ПДн / ДСП / коммерческая тайна / гостайна / информация ограниченного доступа / информация, размещаемая на объектах КИИ);
- формы существования информации (электронная / бумажная / речевая);
- технологии обработки;
- типа объектов, участвующих в обработке.

**Объекты защиты:**

- речевая информация;
- информация, обрабатываемая в ИС;
- информация, передаваемая в каналах связи;
- документированная (бумажная) информация.

Защита нужна на всех этапах: сбор, передача, хранение, использование, уничтожение.

## 3.2. Принципы построения КСЗИ

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

## 3.3. Сущность и понятие планирования

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

**План** — заранее намеченная система деятельности, предусматривающая порядок, последовательность и сроки выполнения работ (С.И. Ожегов).

**Цикл Шухарта–Деминга (PDCA):**

- **Plan (планирование)** — определение целей деятельности и процессов, требуемых для достижения результатов.
- **Do (выполнение)** — внедрение, выполнение действий.
- **Check (проверка)** — постоянный контроль и измерение процессов и результатов.
- **Act (улучшение)** — изменение процесса или переход на новый уровень (цикл).

PDCA лежит в основе СУИБ (ISO/IEC 27001) и подходов к управлению рисками (ISO 31000, ISO 27005).

## 3.4. Исходные данные для планирования работ по ТЗИ

При составлении плана по ТЗИ учитываются:

- требования НПА по ЗИ (152-ФЗ, 187-ФЗ, приказы ФСТЭК 17/117/21/235/239, постановления Правительства);
- положения ОРД самой организации (политики, положения, инструкции);
- текущее состояние ТЗИ (результаты предыдущих обследований, аудитов, аттестаций);
- располагаемые ресурсы (бюджет, кадры, время);
- результаты контроля и надзора (предписания ФСТЭК/ФСБ/РКН, протоколы и решения по итогам проверок);
- план вышестоящей организации (для холдингов, групп компаний, госорганов).

## 3.5. Принципы планирования

1. **Директивность** — обязательный характер планов.
2. **Преемственность** — сочетание и взаимосвязь перспективного и текущего планирования, учёт достигнутого и допущенных недостатков.
3. **Конкретность** — чёткие цели и задачи, рациональные методы, ответственные, реальные сроки.
4. **Проблемность** — нацеленность мероприятий на решение значимых проблем ЗИ, а не на «галочку».
5. **Комплексность** — использование всей системы мер на различных направлениях, согласование на различных уровнях.
6. **Экономичность** — максимальные результаты при наименьших затратах ресурсов.
7. **Гибкость** — возможность манёвра ресурсами; корректировка плана при изменении обстановки.

## 3.6. Цели планирования

- Определение комплекса мероприятий по защите информации, направленных на исключение (нейтрализацию) возможных каналов утечки и угроз БИ.
- Установление персональной ответственности должностных лиц.
- Определение сроков (периодов) проведения мероприятий.
- Систематизация (объединение) планируемых мероприятий по различным направлениям ЗИ.
- Установление системы контроля и системы отчётности.
- Конкретизация функций и задач, решаемых должностными лицами и подразделениями.

## 3.7. Требования к результатам планирования

Результаты планирования должны быть:

1. **Реальными и достижимыми.**
2. **Детализированными** (по подразделениям, по технологическому циклу, по видам защищаемой информации и т.д.).
3. **Измеримыми и однозначными** (чёткими для понимания).
4. **Не противоречащими** объективным законам и общим принципам управления.
5. **Понятными для исполнителей.**

## 3.8. Перспективное и текущее планирование

**Перспективное планирование:**

- Определяет общие стратегические цели и направления развития системы ЗИ.
- Этапы решения поставленных задач, требуемые ресурсы.
- Разрабатывается концепция защиты информации, формируются планы развития подсистем защиты, программы управления ЗИ.
- Горизонт планирования: 3–5 лет (или дольше для стратегических документов).

**Текущее планирование:**

- Ориентировано на фактическое достижение частных целей ЗИ с учётом текущих условий.
- Текущие планы дополняют и уточняют перспективный план.
- Горизонт планирования: год, квартал, месяц.

## 3.9. Восемь этапов планирования мероприятий по ТЗИ

1. **Обоснование целей и критериев ЗИ.** Цели ЗИ должны соответствовать общим целям организации, критерии — позволять оценить качество достижения.
2. **Анализ условий деятельности по ЗИ.** Внешние и внутренние условия: организационная структура, характеристики объектов информатизации, технологический процесс, персонал.
3. **Формулировка задач ЗИ.** Комплекс задач, решение которых приведёт к достижению плановых показателей. Определение методов и процедур.
4. **Анализ ресурсов.** Финансовые, материально-технические, временные, организационные, кадровые. Прогноз изменений ресурсов.
5. **Согласование целей, задач, условий, ресурсов.** Распределение ресурсов по задачам, закрепление исполнителей.
6. **Определение последовательности выполнения задач.** Порядок и сроки выполнения.
7. **Определение методов контроля.** Зависит от целей и критериев; позволяет оценить качество.
8. **Определение порядка корректировки планов.** Корректировка — в той мере, в какой необходимо.

## 3.10. Документация планирования по ТЗИ: разработка, согласование, утверждение

**Кто разрабатывает:** служба безопасности (подразделение ТЗИ).

**Кто согласует:**

- кадровый орган (вопросы доступа персонала);
- служба режима (ПДИТР — противодействие техническим разведкам);
- служба ИТ (вопросы инфраструктуры);
- финансовый орган (бюджет).

**Кто утверждает:** руководитель предприятия (организации).

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

## 3.11. Пример: План разработки и построения системы защиты ПДн

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

**Типовой состав плана:**

| № | Мероприятие | Цель | Срок | Отв. |
|---|-------------|------|------|------|
| 0 | Изучение НПА в области защиты ПДн | Понимание требований | До начала | Ответственный за ПДн |
| 1 | Проведение обследования информационных ресурсов ИСПДн | Сбор исходных данных | 01.06–03.06 | Иванов И.И. |
| 2 | Разработка модели угроз безопасности ПДн | Определение актуальных угроз | 07.06 | Петров П.П. |
| 3 | Определение уровня защищённости ПДн | Определить УЗ ПДн | 07.06 | Петров П.П. |
| 4 | Определение состава организационно-технических мер защиты ПДн | Определить адаптированный уточнённый базовый набор | 08.06 | Сидоров С.С. |
| 5 | Определение (выбор) необходимых СЗИ и их закупка | Приобретение сертифицированных СЗИ | 15.06 | Иванов И.И. |
| 6 | Выполнение организационных мероприятий по защите ПДн (определение КЗ, физическая охрана, ПРД, перечень лиц с доступом, ответственный за безопасность ПДн, учёт СМНИ, оборудование помещений для СКЗИ по инструкции ФАПСИ № 152) | Реализация орг. мер по 152-ФЗ | 20.06 | Иванов И.И. |
| 7 | Настройка СЗИ в соответствии с приказом ФСТЭК № 21 | Выполнение мер защиты | 22.06 | Петров П.П. |
| 8 | Разработка (доработка) эксплуатационной документации, организация обучения пользователей ИСПДн | Информирование/обучение персонала | 25.06 | Сидоров С.С. |
| 9 | Проведение испытаний системы защиты ПДн, устранение недостатков | Оценка работоспособности и эффективности | 28.06 | Петров П.П. |
| 10 | Ввод системы защиты ПДн в эксплуатацию (приказ о вводе в эксплуатацию) | Юридическое оформление | 29.06 | Руководитель |

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

## 3.12. Связь планирования с бюджетным процессом

В российской практике важна привязка плана ТЗИ к бюджетному циклу:

- **Осень года N**: формирование бюджетных заявок на год N+1.
- **Декабрь года N**: утверждение бюджета на N+1.
- **Январь–февраль года N+1**: проведение закупочных процедур.
- **Март–октябрь года N+1**: реализация.
- **Ноябрь года N+1**: подведение итогов, формирование заявок на N+2.

Если ИБ-проект не попал в бюджетную заявку осенью — он автоматически смещается на год. Этот цикл нужно учитывать при перспективном планировании.

**Из практики приказа 117 (с 01.03.2026):** если организация не запустила подготовку и пилот SIEM/SOC в 2025 году, к 01.03.2026 готовности не будет — внедрение SIEM «под ключ» занимает 8–12 месяцев. Поэтому ранний старт — фактор успеха.

## 3.13. Типовые ошибки в планировании ТЗИ

- План написан «для проверки», а не для реальной работы — мероприятия не подкреплены ресурсами.
- Сроки нереальные («внедрить SIEM за 1 месяц», «провести аттестацию за неделю»).
- Не учтён бюджетный цикл — мероприятия запланированы на январь, бюджет ещё не утверждён.
- Не определены ответственные с привязкой к должностям, фигурируют только ФИО — при увольнении мероприятие зависает.
- Отсутствие связи плана ТЗИ с общим планом организации — конфликт с другими проектами (модернизация ИС, переезд).
- Не пересматривается при изменении нормативки или инфраструктуры.
- Нет показателей результата — только «выполнено / не выполнено», без качественной оценки.

## 3.14. Контрольные вопросы блока 3

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

---

> ### 🏁 Конец блока 3 — 15:00
>
> Блок «Планирование работ по обеспечению ИБ» завершён.
>
> ### ☕ Перерыв: 15:00 — 15:10 (10 минут)
>
> Кофе-брейк перед блоком 4.

---

# Блок 4. Управление компьютерными инцидентами. Часть 1 (15:10 — 16:40)

> ### ▶ Начало блока 4 — 15:10
>
> Тема: компьютерные инциденты и атаки, ГосСОПКА, НКЦКИ, ГОСТы серии 597XX, жизненный цикл реагирования, регистрация событий безопасности, SIEM/SOC.

## 4.1. Понятие компьютерного инцидента и компьютерной атаки

**Компьютерный инцидент** (ГОСТ Р 59709—2022, 187-ФЗ, статья 2) — факт нарушения и (или) прекращения функционирования объекта критической информационной инфраструктуры, сети электросвязи, используемой для организации взаимодействия таких объектов, и (или) нарушения безопасности обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки.

**Компьютерная атака** (187-ФЗ, статья 2) — целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты критической информационной инфраструктуры, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации.

**Различия:**

- Атака — это **действие** нарушителя (внешнего, внутреннего, технического).
- Инцидент — это **факт** наступления последствий (нарушение функционирования или безопасности информации).

Не каждая атака приводит к инциденту (атака может быть отбита); инцидент может возникнуть и без атаки (отказ оборудования, ошибка администратора).

## 4.2. Зачем нужно управление инцидентами

Цели управления компьютерными инцидентами:

- Минимизация последствий инцидента (ущерб для бизнеса, утечка, простой, репутация).
- Быстрое восстановление функционирования.
- Локализация атакующего (для расследования и недопущения повторного входа).
- Накопление знаний об угрозах — обратная связь к моделированию угроз и оценке рисков.
- Выполнение требований регуляторов — информирование ФСБ через НКЦКИ.
- Снижение вероятности повторения инцидента.

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

## 4.3. ГосСОПКА: концепция и роль

**Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА)** на информационные ресурсы Российской Федерации.

**Основание создания:**

- Указ Президента от 15.01.2013 № 31с.
- Концепция ГосСОПКА (утверждена Президентом 12.12.2014 № К 1274).
- План развёртывания ведомственных сегментов (Президент, 21.08.2015 № 9397).
- Указ Президента от 22.12.2017 № 620 — совершенствование ГосСОПКА.

**Уполномоченный орган** — Федеральная служба безопасности Российской Федерации.

**Координационный центр ГосСОПКА** — Национальный координационный центр по компьютерным инцидентам (НКЦКИ), создан приказом ФСБ от 24.07.2018 № 366.

**Структура ГосСОПКА:**

- Центр ГосСОПКА (НКЦКИ).
- Ведомственные центры (создаются ФОИВ).
- Корпоративные центры ГосСОПКА (создаются крупными субъектами КИИ).

**Функции ГосСОПКА:**

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

## 4.4. Информирование о компьютерных инцидентах

**Кто обязан информировать:**

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

**Куда:**

- В НКЦКИ — через систему ГосСОПКА (по техническим каналам).
- ФСБ — по приказу № 282.
- Банк России — для финансовых организаций.

**Сроки информирования** (зависят от категории инцидента):

- Для критических инцидентов на ЗОКИИ — в течение нескольких часов.
- Для инцидентов средней значимости — в течение суток.
- Полный перечень — в приказе ФСБ № 367 и методических рекомендациях НКЦКИ.

**Состав сведений** (приказ ФСБ № 367):

- идентификационные сведения об объекте КИИ;
- описание инцидента (тип, время обнаружения, последствия);
- предпринятые меры;
- сведения о компьютерной атаке (если установлены);
- индикаторы компрометации (IoC).

**Порядок обмена информацией** между субъектами КИИ и с иностранными организациями — приказ ФСБ № 368.

## 4.5. ГОСТы серии 597XX по управлению инцидентами

Эта группа стандартов — единая методическая база для управления компьютерными инцидентами в РФ. Все приняты в 2022 году.

### 4.5.1. ГОСТ Р 59709—2022 «Управление компьютерными инцидентами. Термины и определения»

Устанавливает терминологию: компьютерный инцидент, компьютерная атака, событие безопасности, активы, угрозы, индикаторы компрометации (IoC), индикаторы атаки (IoA), реагирование, восстановление, форензика, постмортем.

### 4.5.2. ГОСТ Р 59710—2022 «Управление компьютерными инцидентами. Общие положения»

Описывает общую концепцию: цели и задачи управления инцидентами, принципы, основные процессы, роли и ответственность, связь с управлением рисками и СУИБ.

### 4.5.3. ГОСТ Р 59711—2022 «Управление компьютерными инцидентами. Организация деятельности»

Описывает этап «организация деятельности по управлению инцидентами»: создание структуры (CSIRT/SOC), разработка ОРД, обучение персонала, подготовка инструментария, формирование команды.

### 4.5.4. ГОСТ Р 59712—2022 «Управление компьютерными инцидентами. Руководство по реагированию»

Покрывает три этапа жизненного цикла инцидента:

1. Обнаружение и регистрация компьютерных инцидентов.
2. Реагирование на компьютерные инциденты.
3. Анализ результатов деятельности по управлению компьютерными инцидентами.

## 4.6. Жизненный цикл управления компьютерным инцидентом

Универсальная модель (объединяет ГОСТ Р 59712, NIST SP 800-61, SANS):

### Этап 1. Подготовка (preparation)

- Развёртывание средств мониторинга (SIEM, EDR, NDR, AV, IDS/IPS).
- Подключение к ГосСОПКА.
- Подготовка плейбуков (playbooks) реагирования.
- Обучение команды.
- Поддержание актуальных контактов внешних сторон (НКЦКИ, ФСБ, отраслевой CERT, юристы, вендоры).
- Подготовка процессного фундамента (приказы, инструкции, журналы регистрации).

### Этап 2. Обнаружение и регистрация (detection and recording)

- Получение события из систем мониторинга, от пользователей, от внешних источников (НКЦКИ, отраслевые CERT, поставщики Threat Intelligence).
- Триаж: отделение реальных инцидентов от ложных срабатываний.
- Регистрация инцидента в системе учёта (IRP/SOAR/тикет-система).
- Первичная классификация: тип, серьёзность, затронутые активы.
- Уведомление руководителя инцидента (incident handler).

### Этап 3. Анализ (analysis)

- Подробное исследование инцидента: что произошло, как, через что, кто.
- Сбор форензики (артефактов): образы дисков, дампы памяти, сетевые логи, журналы.
- Построение хронологии инцидента (timeline).
- Определение полного скоупа затронутых активов.
- Выявление индикаторов компрометации и тактик/техник атакующего (MITRE ATT&CK).

### Этап 4. Сдерживание (containment)

- Остановка распространения атаки: изоляция заражённых хостов, блокировка сетевых соединений, отключение скомпрометированных учётных записей.
- Сохранение доказательств (форензики) до удаления вредоносной активности.
- Принятие решений: краткосрочное сдерживание (быстро остановить) vs долгосрочное (наблюдать за атакующим, собирать данные).

### Этап 5. Ликвидация (eradication)

- Удаление вредоносных артефактов (ВПО, бэкдоры, изменённые конфигурации).
- Закрытие эксплуатированных уязвимостей (патчинг, изменение конфигов).
- Смена учётных данных, сертификатов, ключей.
- Удаление присутствия атакующего во всех затронутых системах.

### Этап 6. Восстановление (recovery)

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

### Этап 7. Извлечение уроков (lessons learned, post-incident)

- Проведение постмортема (без поиска виноватых, blameless).
- Документирование: что и почему случилось, что сработало, что не сработало.
- Обновление модели угроз, оценки рисков, реестра уязвимостей.
- Корректировка плейбуков, политик, регламентов.
- Информирование причастных сторон об уроках (внутри организации и при допустимости — отраслевого сообщества).
- Возврат знаний в этап «подготовка» — следующий цикл.

## 4.7. Классификация компьютерных инцидентов

По степени влияния на бизнес:

- **Низкая** — без существенного влияния на функционирование (одиночный фишинг, заблокированный AV).
- **Средняя** — частичное нарушение функционирования (компрометация рабочей станции, локальная вспышка ВПО).
- **Высокая** — существенное нарушение, утечка значимых данных, частичная остановка сервиса.
- **Критическая** — полная остановка ключевого сервиса, утечка ПДн масштаба, компрометация ЗОКИИ, цепочка поставок.

По типу:

- ВПО (вирусы, шифровальщики, RAT, кейлоггеры);
- DDoS / DoS;
- Несанкционированный доступ (НСД) / компрометация учётных записей;
- Утечки информации;
- Целевые атаки (APT);
- Социальная инженерия (фишинг, vishing, smishing, BEC);
- Атаки на цепочку поставок (supply chain);
- Атаки на цепочку аутентификации (Active Directory, Federation);
- Атаки на веб-приложения (OWASP top 10);
- Атаки на промышленные системы (АСУ ТП, ПЛК, SCADA);
- Внутренние угрозы (умышленные и неумышленные действия персонала);
- Атаки на облачные сервисы;
- Физические инциденты (кража носителей, компрометация физического доступа).

## 4.8. Регистрация событий безопасности (ГОСТ Р 59548—2022)

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

**ГОСТ Р 59548—2022** устанавливает требования к регистрируемой информации: что регистрировать, в каком составе, с какой полнотой, как обеспечивать целостность.

**Минимальный набор регистрируемых событий:**

- события аутентификации (успешные и неуспешные);
- события авторизации (выдача / отзыв прав);
- доступ к чувствительным ресурсам;
- системные события (запуск/остановка сервисов, перезагрузки);
- административные действия (изменения конфигурации, добавление пользователей);
- сетевые события (соединения, подозрительный трафик);
- события СЗИ (срабатывания AV/EDR, SIEM, IDS).

**Требования к составу записи:**

- дата и время;
- субъект (кто);
- объект (что);
- результат (успех/неудача);
- источник (с какого устройства/IP);
- описание события.

**Требования к хранению:**

- защита от несанкционированного изменения (целостность, неотказуемость);
- сроки хранения (зависят от категории информации и требований; для ЗОКИИ — не менее 3 лет);
- централизованный сбор (как правило — в SIEM).

## 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);
- гибридный (часть функций — внутри, часть — на аутсорсе).

## 4.10. Приказ ФСТЭК № 117 (с 01.03.2026) и приказ ФСТЭК № 235 — требования к процессам реагирования

**Приказ ФСТЭК № 235** для ЗОКИИ требует:

- разработать план реагирования на компьютерные инциденты;
- создать структуру реагирования (внутреннюю или с привлечением сторонней организации);
- организовать мониторинг и оперативное реагирование;
- обеспечить взаимодействие с ГосСОПКА.

**Приказ ФСТЭК № 117** (с 01.03.2026) для ГИС и иных систем госорганов / ГУП / госучреждений требует:

- непрерывного контроля состояния защищённости;
- реагирования на компьютерные инциденты;
- информирования НКЦКИ.

Это объективная необходимость: «однажды аттестовали — и забыли» уходит в прошлое. На смену периодической оценке приходит **непрерывный мониторинг и реагирование** как часть эксплуатации.

## 4.11. Команда реагирования: роли

- **Incident Manager** — координирует ход инцидента, принимает решения, общается с руководством и регуляторами.
- **Incident Handler / Analyst** — выполняет техническую работу: анализ, сдерживание, ликвидация.
- **Forensic Analyst** — собирает и анализирует артефакты, готовит материалы для расследования.
- **Threat Intelligence Analyst** — атрибутирует атаку, ищет индикаторы по внешним источникам.
- **Communications Lead** — отвечает за коммуникации (внутренние, с регуляторами, с публикой при необходимости).
- **Legal** — правовая оценка ситуации, взаимодействие с правоохранительными органами.
- **Business Liaison** — представитель бизнеса; обеспечивает понимание операционных приоритетов.

В малых организациях все роли может закрывать один-два человека; в крупных — формируется отдельный CSIRT (Computer Security Incident Response Team).

## 4.12. Контрольные вопросы блока 4

1. Чем отличается компьютерный инцидент от компьютерной атаки по 187-ФЗ?
2. Опишите структуру ГосСОПКА и роль НКЦКИ.
3. Кто и в какие сроки обязан информировать о компьютерных инцидентах?
4. Перечислите 4 ГОСТ серии 597XX и кратко опишите назначение каждого.
5. Опишите жизненный цикл управления компьютерным инцидентом (7 этапов).
6. Какие события безопасности должны регистрироваться по ГОСТ 59548—2022?
7. Чем SIEM отличается от SOC?

---

> ### 🏁 Конец блока 4 — 16:40
>
> Первая часть инцидент-менеджмента пройдена.
>
> ### ☕ Перерыв: 16:40 — 16:50 (10 минут)
>
> Последний кофе-брейк перед финальным блоком.

---

# Блок 5. Управление компьютерными инцидентами. Часть 2 (16:50 — 18:20)

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

## 5.1. План реагирования на компьютерные инциденты (Incident Response Plan)

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

1. **Назначение и область действия** — на какие объекты распространяется план, для кого предназначен.
2. **Термины и определения** — используемая терминология (с привязкой к ГОСТ 59709).
3. **Нормативные ссылки** — 187-ФЗ, приказы ФСБ, приказы ФСТЭК, внутренние ОРД.
4. **Классификация инцидентов** — типы, уровни критичности, шкала ущерба.
5. **Структура реагирования** — роли, ответственность, контакты, дежурный график.
6. **Этапы реагирования** — детализация по 7 этапам жизненного цикла.
7. **Плейбуки** для типовых сценариев (ransomware, утечка ПДн, компрометация AD, DDoS, инсайдер).
8. **Порядок информирования** — внутренний (руководство, заинтересованные подразделения) и внешний (НКЦКИ, ФСБ, Банк России, РКН для ПДн).
9. **Порядок обмена с ГосСОПКА** — технические каналы, форматы, ответственные.
10. **Порядок взаимодействия** с правоохранительными органами.
11. **Порядок документирования** — журналы инцидентов, отчёты, материалы постмортема.
12. **Порядок учений и тренировок** — табл-топы (table-top exercise), технические учения, киберучения.
13. **Метрики** — KPI и KRI по инцидент-менеджменту.

План должен **испытываться** регулярно (минимум ежегодно), пересматриваться после крупных инцидентов и при изменении инфраструктуры/процессов.

## 5.2. Плейбук как инструмент реагирования

**Плейбук (playbook)** — детальный пошаговый сценарий реагирования на конкретный тип инцидента.

**Типовая структура плейбука:**

- Условия активации (триггер).
- Уровень критичности по умолчанию.
- Команда (роли).
- Этап «обнаружение»: индикаторы, проверочные действия.
- Этап «анализ»: что собрать, какие источники проверить.
- Этап «сдерживание»: какие шаги выполнить (изоляция, блокировка).
- Этап «ликвидация»: процедуры очистки.
- Этап «восстановление»: критерии возврата в эксплуатацию.
- Этап «постмортем»: что зафиксировать.
- Шаблоны коммуникаций (внутренних, регуляторам).
- Чек-листы.

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

## 5.3. Учения и тренировки (table-top, технические, киберучения)

**Table-top exercise (TTX)** — обсуждение сценария инцидента «за столом». Участники проговаривают свои действия по плейбуку, не выполняя их технически. Позволяет проверить процесс, найти пробелы.

**Технические учения** — выполнение действий на тестовой или эталонной среде (например, изоляция хоста, восстановление из бэкапа).

**Киберучения** — комплексное мероприятие, имитирующее реальную атаку, с участием Red Team (атакующие), Blue Team (защитники), наблюдателей. Может проводиться на специальной площадке — киберполигоне (ПП от 12.10.2019 № 1320 — субсидии на киберполигоны).

**Покрытие учениями:**

- ежегодно — TTX по основным сценариям;
- раз в полгода — технические учения по 2–3 сценариям;
- ежегодно или раз в два года — комплексные киберучения.

## 5.4. Управление уязвимостями (Vulnerability Management, VM)

Управление уязвимостями — обязательная составляющая ИБ-эксплуатации. Регламентируется:

- **Методический документ ФСТЭК «Руководство по организации процесса управления уязвимостями в органе (организации)»** от 17.05.2023.
- **Методика оценки уровня критичности уязвимостей ПО/ПАК** ФСТЭК от 30.06.2025 (новая).
- **Методика тестирования обновлений безопасности** ФСТЭК от 28.10.2022.

**Процесс VM:**

1. **Инвентаризация активов** (без полного перечня ПО/ПАК VM не работает).
2. **Сбор информации об уязвимостях** — БДУ ФСТЭК, NVD, отраслевые БД, бюллетени вендоров, Threat Intelligence.
3. **Сканирование** — регулярное автоматизированное сканирование (внутри периметра и снаружи).
4. **Оценка критичности уязвимости в контексте организации** — по методике ФСТЭК от 30.06.2025.
5. **Приоритизация** — какие уязвимости закрывать в первую очередь.
6. **Устранение** — патчинг, изменение конфигурации, компенсирующие меры, обходные пути.
7. **Тестирование обновлений** — по методике ФСТЭК (особенно для ЗОКИИ).
8. **Проверка результата** — повторное сканирование, верификация.

## 5.5. Новая методика оценки критичности уязвимостей (ФСТЭК от 30.06.2025)

**Ключевые отличия от версии 28.10.2022:**

- Расширена сфера применения: теперь — ИС государственных унитарных предприятий и государственных учреждений (ранее — только ГИС и ЗОКИИ).
- При определении критичности учитываются результаты тестирования на проникновение, учения, мероприятия эксперимента по повышению защищённости ГИС ФОИВ.
- Если ИС функционирует на базе инфраструктуры ЦОД — оценка проводится с учётом инфраструктуры ЦОД.
- В формулу расчёта добавлены два показателя:
  - **Iat** — возможность эксплуатации уязвимости;
  - **Iimp** — последствия эксплуатации уязвимости.
- Изменены значения весовых коэффициентов и пороги критичности.

**Новые пороги критичности:**

| Уровень критичности | Новая методика (2025) | Старая методика (2022) |
|---------------------|----------------------|------------------------|
| Критический | V > 8,0 | 7,0 < V < 10,0 |
| Высокий | 5,0 < V < 8,0 | 4,5 < V < 7,0 |
| Средний | 2,0 < V < 5,0 | 1,5 < V < 4,5 |
| Низкий | V < 2,0 | V < 1,5 |

**Важно:** уязвимостям в сертифицированных программных и программно-аппаратных средствах защиты автоматически присваивается критический уровень (V > 8,0).

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

## 5.6. Тестирование обновлений безопасности (ФСТЭК от 28.10.2022)

Методика регламентирует процесс безопасного развёртывания обновлений на ЗОКИИ и ГИС:

- проверка целостности и подлинности обновления;
- статический и динамический анализ обновления;
- тестирование совместимости с эксплуатируемыми СЗИ;
- развёртывание на тестовом стенде;
- мониторинг после развёртывания.

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

## 5.7. Методика оценки критичности ПО/ПАК (ФСТЭК от 28.10.2022)

Применяется для оценки критичности конкретного ПО или ПАК в составе ЗОКИИ: насколько критично его компрометация для функционирования объекта. Результат используется для приоритизации обновлений, защитных мер, контроля.

## 5.8. Доверенные ПАК и безопасное реагирование

При построении системы реагирования для ЗОКИИ важно учитывать требования к доверенным ПАК (ПНСТ 905—2023, ПП № 1912). Особенно для АСУ ТП:

- средства реагирования (EDR, IRP) сами должны быть доверенными;
- они не должны нарушать функционирование технологического процесса (принцип Воробьева: «Не навреди, не залечи»);
- их функционирование должно соответствовать жёстким требованиям по доступности (failover, hot-standby).

В АСУ ТП главный приоритет — **непрерывность (доступность)** технологического процесса. Триада CIA в АСУ ТП часто переставляется в AIC (Availability → Integrity → Confidentiality). Средства защиты не могут блокировать легитимную команду оператора, ошибки реакции на этом уровне приводят к авариям (Порт-Лавака 2022 — утечка аммиака на заводе удобрений из-за нарушений в работе АСУ ТП; Deepwater Horizon 2010 — взрыв платформы; ряд химических аварий, при которых неправильная настройка системы контроля давления оказалась несинхронизированной с обновлённой системой).

## 5.9. Threat Intelligence и обмен IoC

**Threat Intelligence (TI)** — информация об актуальных угрозах, тактиках и инструментах атакующих, индикаторах компрометации.

**Источники TI для российских организаций:**

- НКЦКИ и ГосСОПКА (приказ ФСБ № 367 — информация субъектам КИИ).
- БДУ ФСТЭК.
- Отраслевые CERT (FinCERT, RU-CERT и др.).
- Коммерческие платформы российских вендоров (Kaspersky, Group-IB, Positive Technologies).
- Открытые источники (OSINT).

**Форматы обмена:**

- STIX/TAXII (международные стандарты);
- MISP (Malware Information Sharing Platform);
- ведомственные форматы НКЦКИ.

**Применение TI:**

- проактивная блокировка по индикаторам (IP, домены, хэши);
- настройка правил детектирования в SIEM/EDR;
- threat hunting (целенаправленный поиск признаков заранее известных угроз);
- стратегическое планирование (понимание актуальной картины угроз).

## 5.10. Метрики инцидент-менеджмента

**Ключевые метрики (KPI/KRI):**

- **MTTD (Mean Time to Detect)** — среднее время до обнаружения инцидента.
- **MTTR (Mean Time to Respond / Recover)** — среднее время до реагирования / восстановления.
- **MTTC (Mean Time to Contain)** — среднее время до сдерживания.
- Количество инцидентов по типам.
- Доля инцидентов, обнаруженных собственными средствами (vs внешними сообщениями).
- Доля инцидентов с уведомлением НКЦКИ в установленные сроки.
- Процент закрытия критических уязвимостей в SLA (например, 7 дней для критических).
- Доля персонала, прошедшего обучение по реагированию.
- Покрытие учениями (раз в год — все ключевые сценарии).

## 5.11. Связь инцидент-менеджмента с другими процессами

- **С риск-менеджментом:** инциденты — обратная связь к модели угроз и оценке рисков; новые типы атак становятся новыми угрозами.
- **С управлением уязвимостями:** закрытие уязвимостей — превентивная мера, инциденты — реактивная; работают в паре.
- **С управлением изменениями (change management):** многие инциденты возникают после некорректных изменений; ревью изменений снижает риск.
- **С управлением непрерывностью (BCM/DRP):** при тяжёлых инцидентах активируются планы непрерывности.
- **С обучением и осведомлённостью:** пользователи — первый рубеж обнаружения; информированный пользователь сообщит о фишинге.
- **С СУИБ (ISO 27001):** инцидент-менеджмент — обязательный домен СУИБ.

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

(По мотивам интервью Николая Нашивочникова, «Information Security» №4, 2025.)

Признаки **зрелой** ИБ-функции:

- Документация = реальная практика, не разрыв.
- Метрики собираются, анализируются, влияют на решения.
- Учения проводятся регулярно, выявляют проблемы — и они закрываются.
- Бюджет ИБ — обоснован риск-моделью, а не запросом на новые «железки».
- Руководство понимает, какие риски приняты осознанно, а какие — устранены.

Признаки **иллюзии устойчивости**:

- «У нас всё аттестовано» — без понимания, что аттестовано в момент X, и инфраструктура с тех пор изменилась.
- «Мы купили <решение>» — без интеграции в процесс.
- «У нас есть SOC» — но MTTD больше суток, MTTR — недель.
- «Регуляторы нас никогда не штрафовали» — но проверок не было.
- Метрики ИБ декларируются, но никто не анализирует тенденции.

Цель курса — отличать зрелость от иллюзии и строить именно зрелые процессы.

## 5.13. Новые подходы: deception, Moving Target Defense, entropy injection

(По мотивам колонки А. Хафизова, «Information Security» №4, 2025.)

**Deception (обман)** — расстановка ловушек (honeypot, honeyfile, honeytoken) на всех уровнях: сеть, серверы, данные. Атакующий тратит время на изучение приманок, защитник — получает индикаторы.

**Moving Target Defense (MTD)** — постоянное изменение параметров инфраструктуры (адреса, маршруты, протоколы). Атакующий не успевает зафиксировать цель.

**Entropy injection** — внесение случайности в работу систем (рандомизация памяти, конфигурационных параметров). В лабораторных условиях снижает вероятность успешной атаки на >90%.

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

## 5.14. Связь с международным контекстом

- **NIST SP 800-61** (Computer Security Incident Handling Guide) — методический ориентир.
- **MITRE ATT&CK** — матрица тактик и техник атакующих; основа для разработки детектирующих правил и оценки покрытия.
- **MITRE D3FEND** — матрица защитных техник.
- **Cyber Kill Chain (Lockheed Martin)** — модель этапов атаки.
- **Diamond Model** — модель анализа компонентов инцидента (нарушитель — возможности — инфраструктура — жертва).
- **OWASP Top 10** — для веб-приложений.
- **MITRE ATT&CK for ICS** — для промышленных систем.

## 5.15. Практические рекомендации

1. Начните с малого: пилот SIEM на 6–12 источников, один-два плейбука, базовая регистрация в реестре инцидентов.
2. Подключитесь к ГосСОПКА — даже если до сих пор «информировали только по факту».
3. Запустите программу осведомлённости (фишинг-симуляции, обучение пользователей).
4. Проведите первый table-top exercise — даже без бюджета: 2 часа в переговорной с командой.
5. Считайте метрики хотя бы по 2–3 показателям, ведите тренд.
6. Документируйте каждый инцидент, даже мелкий — это база знаний.
7. Делайте постмортемы blameless: цель — научиться, а не наказать.
8. Учитывайте бюджетный цикл: приказ № 117 вступает в силу 01.03.2026; пилоты SIEM нужно запускать в 2025.

## 5.16. Контрольные вопросы блока 5

1. Что входит в типовой план реагирования на компьютерные инциденты?
2. Что такое плейбук? Какие сценарии должны быть покрыты в первую очередь?
3. Какие виды учений по реагированию применяются?
4. Опишите процесс управления уязвимостями.
5. Назовите основные отличия методики критичности уязвимостей ФСТЭК от 30.06.2025.
6. Что такое MTTD, MTTR, MTTC?
7. Как инцидент-менеджмент связан с риск-менеджментом и СУИБ?
8. Перечислите признаки зрелой ИБ-функции и признаки «иллюзии устойчивости».

---

> ### 🏁 Конец блока 5 — 18:20
>
> Учебный день завершён. Все 5 блоков пройдены.
>
> ### 🎓 Итог дня
>
> 7 ч 30 мин лекций + перерывы. ~100 слайдов. От методологии риск-менеджмента ИБ до управления компьютерными инцидентами на ЗОКИИ.
> Следующие дни программы переподготовки опираются на риск-методологию и нормативку КИИ, заложенные сегодня.

---

# Приложения

## Приложение А. Перечень нормативных документов дня (актуально на май 2026)

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

- ФЗ от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (в действующей редакции).
- ФЗ от 27.07.2006 № 152-ФЗ «О персональных данных».
- ФЗ от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
- ФЗ от 29.07.2004 № 98-ФЗ «О коммерческой тайне».
- ФЗ от 21.07.1993 № 5485-1 «О государственной тайне».
- ФЗ от 07.04.2025 № 58-ФЗ (внесение изменений в 187-ФЗ; с 01.09.2025).
- ФЗ от 31.07.2025 № 325-ФЗ (внесение изменений; с 01.03.2026).
- ФЗ от 14.07.2022 № 255-ФЗ «О контроле за деятельностью лиц, находящихся под иностранным влиянием».
- ФЗ от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности».

### Указы Президента РФ

- УП от 15.01.2013 № 31с (ГосСОПКА).
- УП от 22.12.2017 № 620 (совершенствование ГосСОПКА).
- УП от 30.03.2022 № 166 (технологическая независимость КИИ).
- УП от 01.05.2022 № 250 (дополнительные меры по обеспечению ИБ).
- УП от 14.04.2022 № 203 (Межведомственная комиссия).
- УП от 05.01.2016 № 646 (Доктрина ИБ).
- УП от 09.05.2017 № 203 (Стратегия развития информационного общества).

### Постановления Правительства РФ

- ПП от 08.02.2018 № 127 (категорирование КИИ; последнее изм. ПП № 1281 от 19.09.2024).
- ПП от 17.02.2018 № 162 (государственный контроль).
- ПП от 08.06.2019 № 743 (ресурсы ЕСЭ для безопасности ЗОКИИ).
- ПП от 22.08.2022 № 1478 (требования к ПО на ЗОКИИ; изм. ПП № 1716 от 17.10.2023).
- ПП от 14.11.2023 № 1912 (переход на доверенные ПАК).
- ПП от 15.07.2022 № 1272 (типовое положение о заме по ИБ).
- ПП от 12.10.2019 № 1320 (субсидии на киберполигоны).
- ПП от 17.09.2022 № 1636 (отраслевой центр компетенций по ИБ).
- **ПП от 13.04.2026 № 402** «Отраслевые особенности категорирования объектов КИИ в сфере связи» (вступает в силу 01.09.2026; первый отраслевой подзаконный акт ФЗ-58).

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

- Приказ ФСТЭК от 11.02.2013 № 17 (действует до 01.03.2026 для ГИС).
- Приказ ФСТЭК от 11.04.2025 № 117 (с 01.03.2026, заменит № 17).
- Приказ ФСТЭК от 18.02.2013 № 21 (ИСПДн).
- Приказ ФСТЭК от 14.03.2014 № 31 (АСУ ТП).
- Приказы ФСТЭК № 227 (реестр ЗОКИИ; изм. № 254 от 17.07.2025), 229 (форма акта проверки), 235 (системы безопасности ЗОКИИ; изм. № 64 от 27.03.2019 и № 69 от 20.04.2023), 236 (форма направления сведений; изм. № 247 от 11.07.2025), 239 (требования по обеспечению безопасности ЗОКИИ; в действующей ред. от 28.08.2024 № 159).
- Приказ ФСТЭК от 16.07.2019 № 135 (перечень НПА для государственного контроля).
- Приказ ФСТЭК от 28.05.2020 № 75 (согласование подключения ЗОКИИ к сетям общего пользования).
- Приказ ФСТЭК от 18.04.2021 № 77 (аттестация объектов информатизации).
- Приказы ФСТЭК от 12.05.2025 № 163 и № 164 (лицензионный контроль).
- **Проект изменений в приказы № 235 и № 239** (опубликован 07.04.2026, планируемое вступление в силу — 01.09.2026): вводятся показатели **Кзи** (защищённость, оценка ≥1 раза в 6 мес.) и **Пзи** (зрелость мер, ≥1 раза в 2 года); сроки уведомления — 3 календарных дня руководителю, 5 рабочих дней — ФСТЭК.

### Приказы ФСБ

- Приказ ФСБ № 366 (НКЦКИ), № 367 (Перечень информации в ГосСОПКА), № 368 (порядок обмена), № 196 (средства для ГосСОПКА), № 281 (порядок установки), № 282 (информирование ФСБ об инцидентах), № 213 (мониторинг защищённости), № 543 (переходный период УП-250).

### ГОСТы

- ГОСТ Р 50922—2006 (терминология ЗИ).
- ГОСТ Р ИСО 31000—2019.
- ГОСТ Р ИСО/МЭК 27005—2010.
- ГОСТ Р ИСО 19011—2021.
- ГОСТ Р 59548—2022 (регистрация событий безопасности).
- ГОСТ Р 59709-712—2022 (управление компьютерными инцидентами).
- ГОСТ Р 70732—2023 (АСУ ТП ЖД).
- ГОСТ Р 56939—2024 (безопасная разработка ПО).
- ГОСТ Р 71207—2024 (статический анализ).
- ПНСТ 905—2023 (доверенные ПАК).
- ПНСТ 911—2024 (доверенные ИМС).
- ПНСТ 1007—2025, ПНСТ 1009—2025.

### Методические документы ФСТЭК

- Методика оценки уровня критичности уязвимостей ПО/ПАК (от 30.06.2025; заменила версию от 28.10.2022).
- Методика тестирования обновлений безопасности (от 28.10.2022).
- Методика оценки критичности ПО/ПАК (от 28.10.2022).
- Методика оценки показателя состояния защиты информации КИИ (от 02.05.2024).
- Руководство по организации процесса управления уязвимостями (от 17.05.2023).
- Рекомендации по разработке Плана реагирования на компьютерные инциденты на ЗОКИИ.
- Методический документ «Рекомендации по подготовке планов мероприятий при уровнях опасности целевых атак» (от 09.08.2021).
- **Методический документ ФСТЭК от 12.04.2026** — методические рекомендации по категорированию объектов КИИ в сфере связи (приложение к ПП-402; вступление — 01.09.2026).

### Международные стандарты (ориентир)

- ISO/IEC 27001, 27002, 27005, 27035.
- ISO 31000:2018, IEC 31010.
- NIST SP 800-30, SP 800-37, SP 800-53, SP 800-61.
- MITRE ATT&CK, D3FEND.

## Приложение Б. Глоссарий

- **АСУ ТП** — автоматизированная система управления технологическим процессом.
- **БДУ** — Банк данных угроз безопасности информации (ФСТЭК).
- **ВПО** — вредоносное программное обеспечение.
- **ГИС** — государственная информационная система.
- **ГосСОПКА** — государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак.
- **ДПАК** — доверенный программно-аппаратный комплекс.
- **ЕСЭ** — единая сеть электросвязи РФ.
- **ЗИ** — защита информации.
- **ЗОКИИ** — значимый объект КИИ.
- **ИАФ, УПД, АУД, ОПС, ЗНИ, СОВ, ИНЦ** — группы мер защиты по приказам ФСТЭК № 21, № 17/117, № 239.
- **ИСПДн** — информационная система персональных данных.
- **К/Ц/Д** — конфиденциальность, целостность, доступность (CIA).
- **КЗ** — контролируемая зона.
- **КИИ** — критическая информационная инфраструктура.
- **КСЗИ** — комплексная система защиты информации.
- **МКЦ, МРД** — мандатный контроль целостности, мандатное разграничение доступа.
- **МСЭ** — межсетевой экран.
- **НКЦКИ** — Национальный координационный центр по компьютерным инцидентам.
- **НПА** — нормативный правовой акт.
- **ОРД** — организационно-распорядительные документы.
- **ПАК** — программно-аппаратный комплекс.
- **ПДн** — персональные данные.
- **ПЗ** — профиль защиты.
- **ППК / ППП** — программа повышения квалификации / профессиональной переподготовки.
- **РБПО** — разработка безопасного программного обеспечения.
- **РКН** — Роскомнадзор.
- **СВТ** — средство вычислительной техники.
- **СЗИ** — средство защиты информации.
- **СКЗИ** — средство криптографической защиты информации.
- **СМИБ / СУИБ** — система менеджмента / управления информационной безопасностью.
- **СОВ / IDS / IPS** — система обнаружения / предотвращения вторжений.
- **СОИБ** — система обеспечения информационной безопасности.
- **СУРИБ** — система управления рисками информационной безопасности.
- **СВР** — степень возможности реализации угрозы ИБ (шкала РС БР ИББС-2.2-2009).
- **СТП** — степень тяжести последствий нарушения ИБ (шкала РС БР ИББС-2.2-2009).
- **OCTAVE** — Operationally Critical Threat, Asset, and Vulnerability Evaluation (методология SEI/CMU).
- **ALE** — Annualized Loss Expectancy (ожидаемые годовые потери; количественная мера риска).
- **SoA** — Statement of Applicability (Декларация о применимости в ISO/IEC 27001).
- **ПолИБ** — политика информационной безопасности организации.
- **CISO** — Chief Information Security Officer (директор по ИБ).
- **ТЗИ / ТЗКИ** — техническая защита информации / конфиденциальной информации.
- **ФСТЭК** — Федеральная служба по техническому и экспортному контролю.
- **ФСБ** — Федеральная служба безопасности.
- **EDR** — Endpoint Detection and Response.
- **IRP** — Incident Response Platform.
- **NDR / NTA** — Network Detection and Response / Network Traffic Analysis.
- **SIEM** — Security Information and Event Management.
- **SOC** — Security Operations Center.
- **SOAR** — Security Orchestration, Automation and Response.
- **SBOM** — Software Bill of Materials.

## Приложение В. Источники к материалам лекции

### Базовый учебник по рискам ИБ (рекомендуется к самостоятельной проработке)

⭐ **Милославская Н.Г., Сенаторов М.Ю., Толстой А.И. Управление рисками информационной безопасности.** — Учебное пособие для вузов. 2-е изд., испр. — М.: Горячая линия–Телеком, 2014. — 130 с. — Серия «Вопросы управления информационной безопасностью. Выпуск 2». — ISBN 978-5-9912-0362-3. *Главный академический источник для блока 1 «Основы управления рисками ИБ». Содержит детальные приложения с типовыми угрозами и уязвимостями, а также обзор инструментальных средств.*

### Нормативно-правовая база

1. Федеральный закон от 26.07.2017 № 187-ФЗ (в действующей редакции с учётом ФЗ-58 от 07.04.2025 и ФЗ-325 от 31.07.2025).
2. ГОСТ Р ИСО 31000—2019. Менеджмент риска. Принципы и руководство.
3. ГОСТ Р ИСО/МЭК 27005—2010. Менеджмент риска информационной безопасности.
4. ГОСТ Р 51897—2002. Менеджмент риска. Термины и определения.
5. ГОСТ Р 51898—2002. Аспекты безопасности. Правила включения в стандарты.
6. ГОСТ Р 59548—2022. Регистрация событий безопасности.
7. ГОСТ Р 59709-712—2022. Управление компьютерными инцидентами.
8. СТО БР ИББС-1.0-2010. Обеспечение ИБ организаций банковской системы РФ. Общие положения.
9. РС БР ИББС-2.2-2009. Методика оценки рисков нарушения ИБ.
10. Приказ ФСТЭК от 11.04.2025 № 117 (по состоянию на май 2026).
11. Перечень действующей нормативки по КИИ на 21.08.2025 (Telegram-канал «Бюрократическая безопасность», t.me/bureaucraticsecurity).

### Международные стандарты

12. ISO/IEC 27001, 27002, 27005:2018/2022. СМИБ и менеджмент рисков ИБ.
13. ISO 31000:2018 «Risk management — Guidelines». IEC 31010 «Risk management — Risk assessment techniques».
14. BS 7799-3:2006 «Information security management systems. Guidelines for information security risk management».
15. NIST SP 800-30 Rev. 1 «Guide for Conducting Risk Assessments».
16. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) — CERT/SEI, Carnegie Mellon University.

### Отраслевые материалы

17. Карантаев В.Г. Технические требования и их реализация при разработке доверенных ПАК для АСУ ОКИИ. ТБ-Форум 2025.
18. Воробьев С. Не навреди, не залечи — киберэтика в сети АСУ ТП. ТБ-Форум 2025.
19. Журнал «Information Security» №4, сентябрь 2025 (спецпроекты SIEM, SOC, IDM, защита сетей).
20. Учебный материал «Планирование работ по ТЗИ», УЦ МАСКОМ.

---

# Контакты

**Виталий Александрович Пиков**
Преподаватель НОУ ДПО «УЦБИ «МАСКОМ»

Email: vitaly@pikov.expert
Telegram: @UnderLineSecurity
Сайт: https://pikov.expert/

Сайт УЦ МАСКОМ: https://mascom-uc.ru/

---

*Документ подготовлен по состоянию на май 2026 года. Все нормативные документы указаны в действующих редакциях на момент подготовки. При практической работе рекомендуется проверять актуальность редакций — нормативная база КИИ обновляется регулярно.*