# День II. Объекты КИИ: угрозы, меры, уязвимости Авторская лекция В.А. Пикова, преподавателя НОУ ДПО «УЦБИ «МАСКОМ» (УЦ МАСКОМ). Полный учебный день — 5 лекций (~7,5 академических часов): оценка угроз безопасности объектов КИИ → структура модели угроз и определение актуальных угроз → меры обеспечения безопасности ЗО КИИ (требования) → порядок выбора мер → уязвимости и оценка их критичности. Документ объединяет два назначения: **раздаточные материалы для слушателей** и **исходник для подготовки презентации** (~100 слайдов). ## Связь с днём I День II опирается на риск-методологию и базовую нормативку КИИ из дня I [risk.pikov.expert](https://risk.pikov.expert/). Кратко: процесс **«контекст → оценка → обработка → принятие → коммуникация → мониторинг»**, четыре варианта обработки риска (снижение / сохранение / избежание / передача), приказы ФСТЭК № 235 и № 239 как базис требований к ЗОКИИ, ГосСОПКА и инцидент-менеджмент. Если не были на дне I — пройдите хотя бы по слайдам, иначе блок 2 («модель угроз») будет идти через раз. --- ## Расписание дня (четверг 28.05) | Блок | Время | Длит. | Тема | Слайды | |------|-------|-------|------|--------| | **1** | 09:30 — 11:00 | 1 ч 30 мин | Оценка угроз безопасности объектов КИИ | 4 — 28 | | ☕ Перерыв | 11:00 — 11:10 | 10 мин | Кофе-брейк | — | | **2** | 11:10 — 12:40 | 1 ч 30 мин | Структура модели угроз. Определение актуальных угроз и их сценариев | 29 — 55 | | 🍽 Обед | 12:40 — 13:30 | 50 мин | Обеденный перерыв | — | | **3** | 13:30 — 15:00 | 1 ч 30 мин | Меры обеспечения безопасности ЗО КИИ. Требования к мерам и их реализация | 56 — 82 | | ☕ Перерыв | 15:00 — 15:10 | 10 мин | Кофе-брейк | — | | **4** | 15:10 — 16:40 | 1 ч 30 мин | Меры обеспечения безопасности ЗО КИИ. Порядок выбора мер. **+ Практическое задание** | 83 — 99 | | ☕ Перерыв | 16:40 — 16:50 | 10 мин | Кофе-брейк | — | | **5** | 16:50 — 18:20 | 1 ч 30 мин | Уязвимости объектов КИИ. Классификация и оценка критичности уязвимостей | 100 — 115 | **Итого:** 7 ч 30 мин лекций + 50 мин обеда + 3 × 10 мин кофе = **8 ч 50 мин**. --- ## Актуальность нормативки Документ подготовлен **по состоянию на май 2026 года**. Базовый источник — «Система нормативных правовых, методических и информационных документов по проблематике обеспечения безопасности КИИ» на 18.05.2026 (Telegram-канал «Бюрократическая безопасность», t.me/bureaucraticsecurity). **Ключевые свежие документы 2025–2026 годов, использованные в этом дне:** - ФЗ от 07.04.2025 № 58-ФЗ + ФЗ от 31.07.2025 № 325-ФЗ — изменения в 187-ФЗ. - **Новый пакет приказов ФСБ от декабря 2025 года** (заменили ранее действовавшие № 196, 281, 282, 368): - № 539 от 23.12.2025 — порядок получения информации о КА от ФСБ; - № 546 от 25.12.2025 — порядок обмена информацией о КА и КИ; - № 547 от 25.12.2025 — порядок информирования ФСБ о КА и КИ (заменил № 282); - № 548 от 25.12.2025 — порядок непрерывного взаимодействия субъектов КИИ с ГосСОПКА; - № 553 от 26.12.2025 — порядок и техусловия установки и эксплуатации средств обнаружения КА (заменил № 281); - № 554 от 26.12.2025 — требования к средствам обнаружения КА (заменил № 196). - **Отраслевые особенности категорирования (6 ПП за 2026 г.):** - ПП от 16.01.2026 № 4 — атомная энергия; - ПП от 06.02.2026 № 92 — банковская и финансовая сфера; - ПП от 07.03.2026 № 246 — наука; - ПП от 23.03.2026 № 303 — государственная регистрация прав на недвижимость; - ПП от 31.03.2026 № 356 — ракетно-космическая промышленность; - ПП от 13.04.2026 № 402 — связь. - Распоряжение Правительства от 26.02.2026 № 360-р — перечень типовых отраслевых объектов КИИ. - Приказ ФСТЭК от 11.04.2025 № 117 (с 01.03.2026) — заменил приказ ФСТЭК № 17 для ГИС. - Методический документ ФСТЭК от 30.06.2025 — методика оценки уровня критичности уязвимостей ПО/ПАК. - Методический документ ФСТЭК от **11.11.2025** — методика оценки показателя состояния защиты информации в ИС и обеспечения безопасности ЗОКИИ (заменил версию от 02.05.2024). - Проект изменений в приказы № 235 и № 239 от 07.04.2026 — показатели Кзи и Пзи (планируется с 01.09.2026). - Методический документ ФСТЭК от 12.04.2026 — рекомендации по категорированию объектов связи (к ПП-402). - ПНСТ 1046-2026 — искусственный интеллект в КИИ. Общие положения. - ГОСТ Р 72507-2026 — микросхемы интегральные. Общие требования к производству. > **Замечание для лектора.** За первую половину 2026 года ФСТЭК и ФСБ выпустили больше нормативки, чем за весь 2024-й. Это, по сути, тихая революция: отраслевые перечни КИИ становятся реальностью, приказы ФСБ декабря 2025 заменили всю «старую гвардию» (196/281/282/368), и впервые появился ГОСТ по ИИ в КИИ. Слушателю важно показать **направление движения**, а не зазубривать номера. --- # Блок 1. Оценка угроз безопасности объектов КИИ (09:30 — 11:00) ## 1.1. Зачем оценивать угрозы Все требования по обеспечению безопасности ЗОКИИ (приказы ФСТЭК № 235 и № 239) построены вокруг ключевой связки: > **Актив → Угроза → Уязвимость → Последствие → Мера защиты** Без актуальной и обоснованной модели угроз весь приказ № 239 превращается в формальный чек-лист, по которому невозможно ни внедрить меры, ни обосновать их выбор перед ФСТЭК на проверке. Поэтому оценка угроз — это не «бумажка для пакета документов», а **производственный документ**, из которого вытекают: 1. **Перечень актуальных угроз** для каждого объекта КИИ. 2. **Перечень способов и сценариев** их реализации (для проектирования контрмер). 3. **Перечень классов нарушителей** (Н1–Н4 по методике ФСТЭК). 4. **Перечень критических процессов**, на которые угрозы воздействуют. 5. **Базис для адаптации мер** приказа 239 (день II, блок 4) и для оценки уязвимостей (день II, блок 5). ## 1.2. Терминология: угроза, атака, инцидент Три понятия, которые на практике постоянно путают. | Понятие | Источник | Определение | |---------|----------|-------------| | **Угроза безопасности информации** | ГОСТ Р 50922—2006 | Совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации | | **Компьютерная атака** | 187-ФЗ, статья 2 | Целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации | | **Компьютерный инцидент** | ГОСТ Р 59709—2022, 187-ФЗ ст. 2 | Факт нарушения и (или) прекращения функционирования объекта КИИ, и (или) нарушения безопасности обрабатываемой такой объектом информации, в т.ч. произошедший в результате компьютерной атаки | **Логика связи:** - **Угроза** — это **потенциальная возможность**. Угроза существует до и после любого инцидента, как факт того, что условия для нарушения есть. «Угроза несанкционированного копирования информации» существует, даже если никто никогда её не пытался реализовать. - **Атака** — это **действие**, реализующее угрозу. Атака может быть успешной или неуспешной. Атака может быть отбита — тогда инцидента нет. - **Инцидент** — это **факт последствий**. Инцидент возникает после атаки, которая прошла рубежи защиты, либо без атаки (отказ оборудования, ошибка администратора, природное явление). Не каждая угроза реализуется → не каждая атака приводит к инциденту → не каждый инцидент следствие атаки. ## 1.3. Триада CIA: К-Ц-Д Базовые свойства информации, нарушение которых составляет суть угроз ИБ: - **Конфиденциальность (Confidentiality)** — состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на него право. - **Целостность (Integrity)** — состояние информации, при котором отсутствуют любые её изменения, либо они осуществляются только преднамеренно уполномоченными субъектами. - **Доступность (Availability)** — состояние информации, при котором имеющие на это право субъекты могут реализовывать его беспрепятственно. **В АСУ ТП и на объектах КИИ** триада CIA часто переставляется в **AIC** или **A-I-C**: 1. **Доступность** — главное. Прекращение технологического процесса критично. 2. **Целостность** — критично для безопасности процесса (например, фальсифицированное значение датчика → авария). 3. **Конфиденциальность** — важна, но не главная. Это важно учитывать при формировании модели угроз для АСУ ТП КВО. ## 1.4. БДУ ФСТЭК — Банк данных угроз **bdu.fstec.ru** — государственный банк данных угроз безопасности информации, размещён на сайте ФСТЭК России. Содержит: - **Перечень угроз безопасности информации** (УБИ-1, УБИ-2, …, насчитывается несколько сотен записей). Каждая запись содержит: - идентификатор (УБИ-N); - наименование угрозы; - описание; - объекты воздействия (категории: системное ПО, прикладное ПО, сетевое оборудование, объекты файловой системы, метаданные и т.д.); - источник угрозы (категория нарушителя); - последствия (нарушение К/Ц/Д). - **Перечень уязвимостей** (БДУ-уязвимости, отдельный раздел). Используется в блоке 5 этого дня. **Применение БДУ при моделировании угроз:** 1. Берётся **полный перечень угроз** из БДУ. 2. Из него исключаются угрозы, **нереализуемые** в условиях данного объекта (например, угрозы виртуализации — если виртуализации нет; угрозы облака — если облака нет). 3. Из оставшихся отбираются угрозы, **источник которых актуален** (есть нарушитель уровня Н1+). 4. Из оставшихся отбираются угрозы, **объект воздействия которых присутствует** в системе. 5. Полученный перечень — **актуальные угрозы** для этого объекта. Подробный алгоритм — в блоке 2. ## 1.5. Источники угроз и виды нарушителей **Источники угроз** (классификация по методике ФСТЭК): - **Антропогенные** — действия людей (умышленные и неумышленные). - **Природные** — стихийные бедствия (землетрясение, наводнение, пожар). - **Техногенные** — отказы и сбои оборудования, ошибки в ПО. В моделях угроз для ИБ традиционно главное внимание уделяется **антропогенным источникам**. **Виды нарушителей** (по методике оценки угроз ФСТЭК от 05.02.2021): ### Внутренние нарушители 1. **Пользователи** (привилегированные и непривилегированные). 2. **Лица, обеспечивающие функционирование систем и сетей** (администрация, охрана, уборщики и т.п.). 3. **Лица, привлекаемые для установки, настройки, испытаний, пусконаладочных и иных видов работ** (подрядчики, интеграторы). 4. **Системные администраторы и администраторы безопасности.** 5. **Авторизованные пользователи систем и сетей.** ### Внешние нарушители 6. **Специальные службы иностранных государств.** 7. **Террористические, экстремистские группировки.** 8. **Преступные группы (криминальные структуры).** 9. **Отдельные физические лица (хакеры).** 10. **Конкурирующие организации.** 11. **Разработчики программных, программно-аппаратных средств.** 12. **Лица, обеспечивающие поставку программных, программно-аппаратных средств, обеспечивающих систем.** 13. **Поставщики услуг связи, вычислительных услуг.** 14. **Бывшие (уволенные) работники.** ## 1.6. Уровни возможностей нарушителей: Н1, Н2, Н3, Н4 Методика ФСТЭК от 05.02.2021 устанавливает четыре уровня возможностей нарушителей: | Уровень | Название | Возможности | |---------|----------|-------------| | **Н1** | **Базовые** | Использует только известные уязвимости, скрипты, инструменты. Может применять средства, свободно распространяемые в Интернете и разработанные другими лицами; имеет минимальные знания механизмов их работы. Обладает базовыми компьютерными знаниями. | | **Н2** | **Базовые повышенные** | Обладает всеми возможностями Н1. Хорошо владеет известными инструментами, понимает как они работают, может вносить изменения для повышения эффективности. Оснащён фреймворками и наборами средств для реализации угроз и использования уязвимостей. | | **Н3** | **Средние** | Способен самостоятельно разрабатывать средства реализации угроз. Имеет ресурсы и возможности группы лиц (например, преступная группа). Может проводить целевые атаки (APT-уровень). | | **Н4** | **Высокие** | Возможности государственных служб и национальных кибер-команд. Способен создавать сложные многоступенчатые атаки с использованием уникальных эксплойтов 0-day, физических устройств, агентов внутри. Имеет неограниченные финансовые и временные ресурсы. | **Привязка нарушителей к уровням** (типичная, оценивается индивидуально): - Н1: непривилегированные пользователи, обслуживающий персонал, бывшие сотрудники, отдельные хакеры. - Н2: подрядчики, конкуренты, разработчики ПО. - Н3: преступные группы, террористические/экстремистские группировки, организованные хакерские группы. - Н4: спецслужбы иностранных государств. ## 1.7. Мотивация нарушителей Понимание мотивации помогает оценить **вероятность** угрозы для конкретного объекта. Типичные мотивы (по методике ФСТЭК): - **Получение финансовой или иной материальной выгоды.** - **Любопытство или желание самореализации** (подтверждение статуса). - **Месть за ранее совершённые действия.** - **Непреднамеренные, неосторожные или неквалифицированные действия.** - **Получение конкурентных преимуществ.** - **Идеологические мотивы** (политические, религиозные). - **Получение разведывательной информации** (для спецслужб). - **Дискредитация организации, государства.** ## 1.8. Классификация угроз Угрозы можно классифицировать по нескольким признакам. ### По свойству, которому угрожает - Угрозы **конфиденциальности** (НСД, утечка, перехват, копирование). - Угрозы **целостности** (модификация, подмена, повреждение). - Угрозы **доступности** (DoS/DDoS, отказ оборудования, разрушение). ### По типу воздействия - **Угрозы НСД** — несанкционированный доступ. - **Угрозы перехвата** — пассивный или активный. - **Угрозы модификации.** - **Угрозы уничтожения.** - **Угрозы блокирования** (DoS). - **Угрозы внедрения** (закладок, кода). ### По способу реализации - **Через сетевой трафик.** - **Через программное обеспечение.** - **Через аппаратное обеспечение.** - **Через физический доступ.** - **Через социальную инженерию.** - **Через цепочку поставок.** ### По цели - **Несанкционированный доступ к информации.** - **Нарушение функционирования системы.** - **Внедрение скрытых функций (закладок).** ## 1.9. Объекты воздействия угроз (по БДУ ФСТЭК) В БДУ ФСТЭК для каждой угрозы указаны объекты воздействия. Полный перечень категорий: - Аппаратное обеспечение; - Системное программное обеспечение (ОС, гипервизоры); - Прикладное программное обеспечение; - Сетевое программное обеспечение; - Микропрограммное обеспечение (firmware, BIOS/UEFI); - Сетевое оборудование (маршрутизаторы, коммутаторы, МСЭ); - Сетевой трафик; - Сетевой узел (хост); - Объекты файловой системы; - Реестр (Windows Registry или аналоги); - Метаданные; - Машинные носители информации (диски, флешки, оптические носители); - Учётные данные пользователя; - Виртуальная машина, гипервизор, виртуальные устройства; - Облачная инфраструктура и облачный сервер; - Хранилище больших данных; - Грид-система; - Защищаемые данные; - Средства защиты информации. ## 1.10. Цели атак на объекты КИИ (По материалам ТБ-Форум 2025, доклад В. Карантаева о доверенных ПАК.) Применительно к объектам КИИ (особенно АСУ ТП) типичные цели атак: - Несанкционированное изменение **уставок / конфигурации / проекта ПЛК**. - **Подмена контрольно-измерительной информации**, собираемой ПЛК. - Исполнение **ложных команд** на ПЛК. - Создание **временной недоступности** ПЛК. - **Вывод из строя** ПЛК. - Создание устойчивого **бэкдора** из ПЛК. В корпоративных ИС цели схожие, но в терминах ИТ: - Утечка персональных данных; - Доступ к учётным записям (компрометация AD/IAM); - Установление контроля над инфраструктурой (Domain Admin); - Шифрование данных (ransomware); - Финансовое мошенничество; - Получение конкурентной информации. ## 1.11. Связь с риск-менеджментом (день I) В дне I (risk.pikov.expert) мы изучили цикл управления рисками ИБ по ГОСТ Р ИСО/МЭК 27005—2010: ``` Контекст → Оценка риска → Обработка → Принятие → Коммуникация → Мониторинг ``` Где в этом цикле модель угроз? **Внутри этапа «Оценка риска», в составе подэтапа «Идентификация»:** ``` Активы → УГРОЗЫ → Существующие меры → Уязвимости → Последствия ``` Сегодняшний день II — это **расширение и детализация работы с угрозами** в применении к объектам КИИ. Модель угроз — это документально оформленный результат идентификации угроз; на его основе оценивается риск и выбираются меры. Аналогично работа с уязвимостями (блок 5 сегодняшнего дня) — это конкретизация ещё одного элемента «Идентификации» из дня I. ## 1.12. Что должна содержать модель угроз: предварительно Согласно приказу ФСТЭК № 236 (форма направления сведений о категорировании), при категорировании ЗОКИИ субъект КИИ обязан включить в сведения, направляемые во ФСТЭК: - **п. 6.1.** Категорию нарушителя (внешний или внутренний), краткую характеристику его возможностей, оснащённости, знаний, мотивации; либо обоснование невозможности нарушителем реализовать угрозы безопасности информации. - **п. 6.2.** Основные угрозы безопасности информации или обоснование их неактуальности. - **п. 7.1.** Типы компьютерных инцидентов, которые могут произойти в результате реализации угроз, в том числе вследствие целенаправленных компьютерных атак, или обоснование невозможности наступления компьютерных инцидентов. То есть **модель угроз — это не отдельный документ для шкафа, а основа для официальной отчётности во ФСТЭК**. Если модель плохая, ФСТЭК увидит это на проверке. ## 1.13. Типовые ошибки на этапе оценки угроз - **«Берём все угрозы из БДУ как актуальные»** — нелогично; половина может быть нерелевантна. - **«Угроза есть, но без обоснования вероятности»** — в модели должно быть описано, почему угроза актуальна. - **«Нарушитель Н1»** — не глядя на отрасль и привлекательность объекта. Для ЗОКИИ часто реалистичен Н3. - **Модель угроз не обновляется** при изменении инфраструктуры или появлении новых типов атак. - **Модель угроз = копия модели соседа** — без адаптации под свои бизнес-процессы. - Отсутствует **обоснование исключённых угроз** — ФСТЭК на проверке требует объяснений по каждой. - **Модель угроз отделена от модели нарушителя** — должны быть согласованы. ## 1.14. Контрольные вопросы блока 1 1. В чём разница между «угрозой», «атакой» и «инцидентом» по нормативке РФ? 2. Где находится БДУ ФСТЭК и что в нём? 3. Что такое триада CIA и почему в АСУ ТП она преобразуется в AIC? 4. Перечислите 4 уровня возможностей нарушителей (Н1–Н4). 5. Назовите типовые виды внутренних и внешних нарушителей. 6. Каковы 6 типичных целей атак на объекты КИИ? 7. Где модель угроз встраивается в цикл риск-менеджмента из дня I? 8. Что должна содержать модель угроз с точки зрения приказа ФСТЭК № 236? --- > ### 🏁 Конец блока 1 — 11:00 > > Блок «Оценка угроз безопасности объектов КИИ» завершён. Введена терминология, классификация нарушителей (Н1–Н4) и принцип работы с БДУ ФСТЭК. > > ### ☕ Перерыв: 11:00 — 11:10 (10 минут) > > Кофе-брейк перед блоком 2 «Структура модели угроз». --- # Блок 2. Структура модели угроз. Определение актуальных угроз и их сценариев (11:10 — 12:40) > ### ▶ Начало блока 2 — 11:10 > > Тема: построение модели угроз по методике ФСТЭК от 05.02.2021, алгоритм выявления актуальных угроз и их сценариев. На примере Яндекс.Такси разберём весь цикл от выявления критических процессов до определения категории значимости. ## 2.1. Методический документ ФСТЭК «Методика оценки угроз безопасности информации» от 05.02.2021 **Главный методический документ** ФСТЭК для всех видов информационных систем и объектов КИИ. **Утверждён:** ФСТЭК России 05.02.2021. **Действует** на момент мая 2026 г. **Заменил:** - Методику определения актуальных угроз безопасности персональных данных (от 14.02.2008). - Методику определения актуальных угроз безопасности информации в КСИИ (от 18.05.2007). **Область применения** методики: - Информационные системы (ИС); - Автоматизированные системы управления (АСУ); - Информационно-телекоммуникационные сети (ИТКС); - Инфраструктуры центров обработки данных (ЦОД); - Облачные инфраструктуры. **Назначение методики:** - Определить **порядок и содержание работ** по выявлению угроз безопасности информации. - Установить требования к **разработке моделей угроз**. - Обеспечить **единообразие** подходов в РФ. ## 2.2. Структура модели угроз Согласно методике ФСТЭК, модель угроз должна содержать: | Раздел | Содержание | |--------|------------| | **1. Общие положения** | Назначение, область применения модели, нормативные ссылки | | **2. Описание объекта защиты** | Состав системы, технологические процессы, информационные потоки | | **3. Защищаемые активы** | Перечень активов, классификация по К/Ц/Д, ценность для бизнеса | | **4. Источники угроз** | Природные, техногенные, антропогенные. Для антропогенных — модель нарушителя | | **5. Возможные угрозы** | Идентификация угроз из БДУ ФСТЭК, обоснование исключений | | **6. Способы реализации угроз** | Каналы, методы, инструменты | | **7. Сценарии реализации** | Цепочки действий нарушителя (kill chain) | | **8. Возможные последствия** | По К/Ц/Д, по бизнес-процессам, по комплаенсу | | **9. Актуальность угроз** | Итоговый перечень с обоснованием | | **Приложения** | Таблица БДУ-угроз с пометками «актуальна / не актуальна / обоснование» | ## 2.3. Алгоритм формирования перечня актуальных угроз (по В.А. Пикову) Авторская методика, отработанная на десятках реальных моделей угроз. Применима к любому объекту защиты — от ИСПДн до ЗОКИИ. ``` Шаг 1: Описание объекта защиты ↓ Шаг 2: Определение защищаемых активов и их свойств (К/Ц/Д) ↓ Шаг 3: Загрузка полного перечня угроз из БДУ ФСТЭК ↓ Шаг 4: Исключение угроз, нерелевантных архитектуре системы ↓ Шаг 5: Исключение угроз, нерелевантных среде функционирования ↓ Шаг 6: Определение источников и характеристик нарушителей (Н1–Н4) ↓ Шаг 7: Привязка оставшихся угроз к нарушителям ↓ Шаг 8: Оценка возможности реализации угрозы для данной системы ↓ Шаг 9: Оценка последствий реализации ↓ Шаг 10: Формирование перечня АКТУАЛЬНЫХ угроз ↓ Шаг 11: Описание способов и сценариев реализации ↓ Шаг 12: Привязка контрмер (для блока 4) ``` ## 2.4. Шаг 1. Описание объекта защиты Минимальный состав описания: - **Назначение и функции** системы; - **Тип** (ИС, ИСПДн, ГИС, ЗОКИИ, АСУ ТП и т.д.); - **Категория значимости** (для ЗОКИИ); - **Архитектура**: компоненты, схема сетевого взаимодействия; - **Программное обеспечение**: ОС, СУБД, прикладное, сетевое; - **Аппаратное обеспечение**: серверы, рабочие станции, сетевое оборудование, ПЛК и т.д.; - **Технологии**: виртуализация, контейнеризация, облака, беспроводные сети, мобильные устройства, грид-системы, ХBig Data, XML, ЧПУ, ЭП и т.д. — это важный список, так как угрозы из БДУ для несуществующих технологий будут исключены; - **Информационные потоки**: откуда и куда движутся данные; - **Защищаемая информация**: категории, объёмы, формы; - **Пользователи**: типы, роли, число; - **Местоположение**: контролируемые зоны, удалённые сегменты; - **Подключения к сетям общего пользования** (Интернет): есть или нет, как организованы; - **Информационное взаимодействие** с другими ИС. Это описание — фундамент. Чем подробнее, тем точнее модель угроз. ## 2.5. Шаги 4–5. Исключение нерелевантных угроз **Шаг 4 — нерелевантные АРХИТЕКТУРЕ системы.** Примеры (по алгоритму Пикова, на примере беспилотных летательных аппаратов): | Технология | Если не используется в системе — исключаем угрозы, связанные с… | |------------|----------------------------------------------------------------| | АСУ ТП | угрозами для промышленного оборудования (нет ПЛК) | | Интернет | угрозами через глобальную сеть (нет подключения) | | Мобильные устройства | угрозами для мобильных платформ | | Облачные технологии | облачные угрозы | | Wi-Fi | беспроводные угрозы | | Виртуализация | угрозы для гипервизоров и ВМ | | Грид-системы | угрозы для распределённых вычислений | | XML | угрозы XML-schema, XXE | | ЧПУ | угрозы для CNC-оборудования | | Электронная подпись | угрозы криптографии ЭП | | Big Data | угрозы для хранилищ больших данных | **Шаг 5 — нерелевантные СРЕДЕ.** Примеры: - Если объект **изолирован физически** (нет внешних подключений) — исключаются угрозы через каналы связи. - Если в системе **отсутствуют пользователи** (полностью автоматизированный процесс) — исключаются угрозы социальной инженерии. - Если ПЭВМ **не имеет режима гибернации** — исключаются связанные с ней угрозы. - Если **отсутствуют инструменты разработчика** — исключаются угрозы их использования. **Каждое исключение обосновывается** в модели угроз — с указанием конкретных причин. Без обоснования ФСТЭК на проверке отклонит модель. ## 2.6. Шаги 6–7. Модель нарушителя Модель нарушителя — обязательное приложение к модели угроз. Согласно методике ФСТЭК от 05.02.2021 модель нарушителя для каждого объекта должна содержать: ### Для каждого вида нарушителя: | Вид нарушителя | Категория (внеш./внутр.) | Уровень (Н1–Н4) | Мотивация | Возможности | |----------------|-------------------------|-----------------|-----------|-------------| | (название) | внешний / внутренний | Н1 / Н2 / Н3 / Н4 | … | … | Пример таблицы для типовой коммерческой ИС: | Вид | Тип | Уровень | Мотивация | Возможности | |-----|-----|---------|-----------|-------------| | Непривилегированный пользователь | Внутренний | **Н1** | Финансовая выгода, любопытство, месть, неосторожность | Известные уязвимости, скрипты, инструменты из Интернета, базовые компьютерные знания | | Обслуживающий персонал | Внутренний | **Н1** | Финансовая выгода, неосторожность | То же | | Подрядчик (установка/настройка) | Внутренний | **Н2** | Финансовая выгода, конкуренция, неосторожность | + Фреймворки и наборы инструментов, понимание их работы, модификация средств | | Системный администратор | Внутренний | **Н2** | Финансовая выгода, месть | + Привилегированный доступ | | Бывший работник | Внешний | **Н1** | Финансовая выгода, месть | Базовые знания + знание внутренней инфраструктуры | | Конкурирующая организация | Внешний | **Н2** | Конкурентные преимущества, финансовая выгода | + Целенаправленный сбор информации | | Отдельный хакер | Внешний | **Н1** | Любопытство, самореализация, выгода | Базовые инструменты | | Преступная группа | Внешний | **Н3** | Финансовая выгода (большие суммы) | Целевые атаки, разработка собственных средств, ресурсы группы | | Спецслужбы иностранных государств | Внешний | **Н4** | Разведывательная информация | Уникальные эксплойты 0-day, физические закладки, агенты | Для ЗОКИИ практически всегда актуальны нарушители Н3 (преступные группы) и в ряде случаев Н4 (для критичных отраслей — энергетика, оборонка, банки). ## 2.7. Шаги 8–10. Оценка возможности и последствий, формирование итогового перечня Для каждой угрозы, оставшейся после фильтрации, оценивается: - **Возможность реализации** — есть ли в системе условия для реализации (нарушитель + уязвимость + способ + объект воздействия). - **Последствия реализации** — что нарушится (К/Ц/Д), какой ущерб. - **Актуальность** — итоговый бинарный вывод: «актуальна» / «не актуальна». Формируется итоговая таблица **Перечень актуальных угроз**: | № | УБИ из БДУ | Наименование угрозы | Объект воздействия | Способ реализации | Возможные последствия | Меры защиты | |---|------------|--------------------|--------------------|--------------------|----------------------|-------------| | 1 | УБИ-N | … | … | … | … | (отсылка к мерам приказа 239) | Пример (фрагмент из модели угроз для БПЛА, по алгоритму Пикова): | УБИ | Наименование | Объект | Меры защиты | |-----|-------------|--------|-------------| | УБИ-3 | Угроза анализа криптографических алгоритмов и их реализации | Метаданные, системное ПО | Сертифицированное криптооборудование; орг.-техн. меры | | УБИ-4 | Угроза аппаратного сброса пароля BIOS | Микропрограммное и аппаратное обеспечение BIOS/UEFI | Средства доверенной загрузки; орг.-техн. меры | | УБИ-5 | Угроза внедрения вредоносного кода в BIOS | BIOS/UEFI | СДЗ; орг.-техн. меры | | УБИ-6 | Угроза внедрения кода или данных | Системное и прикладное ПО, сетевое ПО | АВЗ, сертифицированное ПО, СЗИ от НСД, контроль целостности | | УБИ-7 | Угроза воздействия на программы с высокими привилегиями | ИС, ВМ, сетевое ПО | АВЗ, СЗИ от НСД, контроль целостности | | УБИ-30 | Угроза использования информации идентификации/аутентификации по умолчанию | СрЗИ, ОС, сетевое ПО | Смена паролей по умолчанию; орг.-техн. меры | ## 2.8. Шаги 11–12. Способы и сценарии реализации Методика ФСТЭК особо подчёркивает: **актуальная угроза описывается через способ и сценарий**. **Способ реализации** — это «как» угроза превращается в атаку. Категории: - Эксплуатация технических уязвимостей (через CVE); - Эксплуатация уязвимостей конфигурации; - Эксплуатация уязвимостей архитектуры; - Использование легитимного функционала; - Социальная инженерия (фишинг, BEC, vishing); - Физический доступ; - Цепочка поставок (supply chain); - Инсайдер. **Сценарий реализации** — это последовательность шагов (kill chain). Типовая структура: 1. **Разведка (Reconnaissance)** — сбор информации об объекте. 2. **Вооружение (Weaponization)** — подготовка инструментов. 3. **Доставка (Delivery)** — доставка вредоносного объекта. 4. **Эксплуатация (Exploitation)** — использование уязвимости. 5. **Установка (Installation)** — закрепление в системе (бэкдор). 6. **Управление (Command & Control)** — связь с управляющим сервером. 7. **Действия (Actions on Objectives)** — достижение цели атаки. (Модель **Cyber Kill Chain** Lockheed Martin; для целей ФСТЭК — допустимая модель.) **Альтернативная модель** — **MITRE ATT&CK** — матрица тактик (14 категорий) и техник (сотни конкретных). Применима как для ИТ-систем, так и для АСУ ТП (MITRE ATT&CK for ICS). Тактики MITRE ATT&CK: 1. Reconnaissance (разведка); 2. Resource Development (подготовка ресурсов); 3. Initial Access (первичный доступ); 4. Execution (выполнение кода); 5. Persistence (закрепление); 6. Privilege Escalation (повышение привилегий); 7. Defense Evasion (уклонение от обнаружения); 8. Credential Access (доступ к учётным данным); 9. Discovery (исследование среды); 10. Lateral Movement (перемещение по сети); 11. Collection (сбор информации); 12. Command and Control (управление); 13. Exfiltration (вывод информации); 14. Impact (воздействие). Для модели угроз ЗОКИИ полезно указать **типовые техники MITRE ATT&CK**, которые могут применить нарушители Н2–Н4 против данного объекта. ## 2.9. Пример: модель угроз для Яндекс.Такси (Учебный пример из материалов УЦ МАСКОМ.) **Шаг 1 — определяем, является ли организация субъектом КИИ.** ООО «ЯНДЕКС.ТАКСИ» зарегистрировано 21.12.2015. Основной вид деятельности по ОКВЭД — **62.01 «Разработка компьютерного программного обеспечения»**. Однако компания имеет дополнительные виды: - 61.10 — Деятельность в области связи на базе проводных технологий; - 61.10.9 — Связь прочая; - 62.02 — Консультативная и работы в области компьютерных технологий; - 62.09 — Деятельность, связанная с использованием вычислительной техники; - 63.11 — Обработка данных, услуги по размещению информации; - 63.11.1 — Создание и использование баз данных; - и т.д. Кроме того, в группе «Яндекс» лицензии в области связи имеют ООО «Яндекс.ОФД» (Л030-00114-77) и ООО «Яндекс.Телеком». **Вывод:** Яндекс.Такси — субъект КИИ в сфере **связи** (плюс возможно — в сфере транспорта, через категорию транспортных услуг). **Шаг 2 — критические процессы:** 1. Управление работой компании. 2. Обеспечение возможности использования сервиса (регистрация, скачивание приложений, личный кабинет). 3. Обработка информации по заказам такси (заявки на поездки). 4. Разработка и поддержка ПО сервиса. 5. Администрирование сайта и сервиса. 6. Ведение финансового и налогового учёта. **Шаг 3 — объекты КИИ:** - Приложение для пассажира (мобильное, тип ИС); - Приложение для водителя (мобильное, тип ИС); - Корпоративная («офисная») сеть компании; - ЦОД, в котором развёрнуты веб-приложения, СУБД, СХД, средства администрирования. **Шаг 4 — категория значимости.** Оценка по 5 группам показателей значимости (ПП-127): ### Экономическая значимость - Выручка ООО «Яндекс.Такси» за 2023 год: 165 800 млн руб. (+43% за год). - Чистая прибыль 2022: 31 900 млн руб. (+250%). - При размере налога 27% и одном дне простоя сервиса — недоплата налогов **122,6 млн руб.** - Доходная часть федерального бюджета РФ (усреднено за 2024–2026): 34 222 млрд руб. - Порог категории III: **0,0003%** от усреднённого дохода = **102,67 млн руб.** - Порог категории II: **0,001%** = **342,22 млн руб.** **Вывод по экономической значимости:** объект подходит под **III категорию** (122,6 млн руб. > 102,67 млн руб., но меньше 342,22 млн руб.). ### Социальная значимость - Сеть связи — Яндекс.Такси оказывает услуги связи (по дополнительному ОКВЭД и через лицензии группы); - Количество пользователей: **более 36 000 000**. - Порог III категории по абонентам: **≥3 000 человек**; - Порог II категории: ≥1 000 000; - Порог I категории: ≥5 000 000. **Вывод по социальной значимости:** объект подходит под **I категорию** по количеству абонентов сети связи. ### Итог категорирования Категория определяется по **максимальному** из достигнутых показателей. Так как по социальной значимости — I категория, **объект КИИ Яндекс.Такси относится к I категории значимости**. **Что дальше?** Субъект КИИ направляет во ФСТЭК сведения о результатах категорирования (приказ № 236, с изм. № 247 от 11.07.2025), в т.ч. категорию и характеристики нарушителей. **Замечание для лектора.** Этот учебный пример иллюстрирует, что даже «обычная» IT-компания может оказаться субъектом КИИ I категории при правильной идентификации сферы деятельности. Аналогично рассмотреть на занятии могут учреждения здравоохранения, банки, операторы связи, транспортные предприятия. ## 2.10. Когда обновлять модель угроз Модель угроз — **живой документ**. Обновляется при: - Изменении инфраструктуры (новые компоненты, изменения архитектуры); - Изменении технологий (внедрение виртуализации, миграция в облако); - Появлении новых типов атак (новые УБИ в БДУ); - Изменении бизнес-процессов; - Изменении нормативки; - После значимых инцидентов (своих или отраслевых); - Не реже **1 раза в год** — плановое обновление. С введением показателей **Кзи** (раз в 6 месяцев) и **Пзи** (раз в 2 года) из готовящегося обновления приказов 235/239 — модель угроз станет основой регулярной самооценки защищённости. ## 2.11. Связь модели угроз с другими документами Модель угроз — **базовый документ** в пакете обеспечения безопасности ЗОКИИ: ``` ┌──────────────────────────────┐ │ МОДЕЛЬ УГРОЗ │ │ + МОДЕЛЬ НАРУШИТЕЛЯ │ └──────────────┬───────────────┘ │ ┌────────────────────┼────────────────────┐ ↓ ↓ ↓ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Акт │ │ Технический │ │ Перечень мер │ │ категориро- │ │ проект СОИБ │ │ ИБ │ │ вания │ │ │ │ (адаптация │ │ │ │ │ │ приказа 239)│ └──────────────┘ └──────────────┘ └──────────────┘ │ ↓ ┌──────────────────────┐ │ Программа испытаний │ │ Эксплуатационная │ │ документация │ └──────────────────────┘ ``` ## 2.12. Контрольные вопросы блока 2 1. Каков статус и область применения методики ФСТЭК от 05.02.2021? 2. Перечислите 9 разделов модели угроз. 3. Опишите 12 шагов алгоритма формирования перечня актуальных угроз. 4. Какие технологии в системе автоматически снимают значительную часть угроз из БДУ при их отсутствии? 5. Каковы 4 уровня возможностей нарушителей по методике ФСТЭК? 6. Что такое способ реализации угрозы и сценарий реализации? 7. Как модель угроз связана с актом категорирования и тех. проектом СОИБ? 8. Когда модель угроз обязательно обновляется? --- > ### 🏁 Конец блока 2 — 12:40 > > Утренняя часть позади. Разобрали методику ФСТЭК от 05.02.2021, 12-шаговый алгоритм формирования модели угроз и кейс с Яндекс.Такси (I категория значимости КИИ). > > ### 🍽 Обеденный перерыв: 12:40 — 13:30 (50 минут) > > После обеда — два блока подряд по мерам обеспечения безопасности ЗОКИИ. Сначала требования (блок 3), затем порядок выбора с практическим заданием (блок 4). --- # Блок 3. Меры обеспечения безопасности ЗО КИИ. Требования к мерам и их реализация (13:30 — 15:00) > ### ▶ Начало блока 3 — 13:30 > > Тема: систематический разбор требований к мерам ИБ — приказы ФСТЭК № 235 (систему безопасности) и № 239 (по обеспечению безопасности), уровни доверия СрЗИ, требования к СУБД, виртуализации, контейнеризации, ОС, доверенным ПАК и криптографии. ## 3.1. Двухуровневая нормативная база требований к ЗОКИИ Требования к мерам защиты ЗОКИИ построены на двух связанных приказах: | Приказ | Что регулирует | Глубина | |--------|---------------|---------| | **ФСТЭК № 235** (от 21.12.2017) | **Систему безопасности** ЗОКИИ — что она должна делать, какие документы вести, какие подразделения иметь | Высокий уровень: ОРД, оргструктура, процессы | | **ФСТЭК № 239** (от 25.12.2017) | **Требования к мерам** обеспечения безопасности — конкретные 18 групп мер | Низкий уровень: технические и организационные функции | Также действуют: - **Приказ ФСТЭК № 76** (от 02.06.2020) — Уровни доверия к СрЗИ. - **Приказ ФСТЭК № 64** (от 14.04.2023) — Требования к СУБД. - **Приказ ФСТЭК № 187** (от 27.10.2022) — Требования к средствам виртуализации. - **Приказ ФСТЭК № 118** (от 04.07.2022) — Требования к средствам контейнеризации. - **Профили защиты ОС** ФСТЭК (от 08.02.2017 — тип А; от 11.05.2017 — типы Б и В). - **Указ Президента № 250** (от 01.05.2022) — запрет на СрЗИ из недружественных стран. ## 3.2. Приказ ФСТЭК № 235 — система безопасности ЗОКИИ **Что должна обеспечивать система безопасности ЗОКИИ** (п. 4 приказа): 1. **Предотвращение** неправомерного доступа, уничтожения, модификации, блокирования, копирования, предоставления и распространения информации. 2. **Недопущение** воздействия на технические средства обработки информации, в результате которого может быть нарушено и (или) прекращено функционирование ЗОКИИ. 3. **Восстановление** функционирования ЗОКИИ. 4. **Непрерывное взаимодействие** с ГосСОПКА (новая редакция — приказ ФСБ № 548 от 25.12.2025). **Состав системы безопасности:** | Компонент | Описание | |-----------|----------| | **ОРД** | Политики, регламенты, инструкции по обеспечению безопасности; должны быть утверждены и доведены до персонала | | **Структурные подразделения / лица** | Ответственные за обеспечение безопасности; численность зависит от категории и масштаба | | **Технические меры** | СрЗИ, средства обнаружения и реагирования, средства ГосСОПКА — должны быть установлены, настроены, эксплуатироваться | **Документация системы безопасности** (минимум, по приказу 235): - Документы целей и задач обеспечения безопасности; - Документы по категорированию (акт + сведения по ф. 236); - **Модель угроз** и модель нарушителя (это блок 1–2 сегодняшнего дня); - Проектная документация на систему безопасности (тех. проект СОИБ); - Эксплуатационная документация на СрЗИ; - ОРД по реагированию на инциденты; - ОРД по взаимодействию с ГосСОПКА; - План реагирования на компьютерные инциденты (срок разработки — **90 дней** с момента включения в реестр ЗОКИИ; штраф 100–500 тыс. руб. по ст. 13.12.1 КоАП РФ). ## 3.3. Приказ ФСТЭК № 239 — 18 групп мер защиты **Действующая редакция** — от 28.08.2024 (изм. приказа № 159). Меры защиты группируются в **18 подсистем**: | № | Аббр. | Группа мер | Что обеспечивает | |---|-------|-----------|------------------| | 1 | **ИАФ** | Идентификация и аутентификация | Проверка субъектов перед доступом | | 2 | **УПД** | Управление доступом | Разграничение прав на ресурсы | | 3 | **ОПС** | Ограничение программной среды | «Замкнутая программная среда» | | 4 | **ЗНИ** | Защита машинных носителей информации | СМНИ, флешки, диски | | 5 | **АУД** | Аудит безопасности | Регистрация событий безопасности | | 6 | **АВЗ** | Антивирусная защита | Защита от вредоносного ПО | | 7 | **СОВ** | Предотвращение вторжений (IPS/IDS) | Обнаружение сетевых атак | | 8 | **АНЗ** | Контроль (анализ) защищённости | Регулярное сканирование | | 9 | **ОЦЛ** | Обеспечение целостности | Контроль изменений | | 10 | **ОДТ** | Обеспечение доступности | Резервирование, бэкап | | 11 | **ЗТС** | Защита технических средств | Физическая и аппаратная защита | | 12 | **ЗИС** | Защита ИС и её компонентов | Архитектурные меры | | 13 | **УКФ** | Управление конфигурацией | Эталоны, контроль изменений | | 14 | **ОПО** | Управление обновлениями | Патч-менеджмент | | 15 | **ИНЦ** | Реагирование на инциденты | План реагирования | | 16 | **ОНРБ** | Управление непрерывностью | BCM/DRP | | 17 | **ДНС** | Обеспечение действий в нештатных ситуациях | Аварийные процедуры | | 18 | **ИПО** | Информирование и обучение персонала | Awareness-программы | **Структура требований:** для каждой меры в приказе 239 указано, в каких категориях значимости она входит в базовый набор: - «**+**» — мера обязательна для данной категории. - Пустое поле — мера применяется при адаптации (если актуальна). Для **категории 1** базовый набор самый широкий, для **категории 3** — самый компактный. ## 3.4. Уровни доверия СрЗИ — приказ ФСТЭК № 76 от 02.06.2020 Все СрЗИ, применяемые на ЗОКИИ, должны иметь **сертификат соответствия** требованиям по безопасности и **уровень доверия**. **Шесть уровней доверия:** | Уровень доверия | Применение | |-----------------|------------| | **1** (высший) | ЗОКИИ, обрабатывающие сведения, составляющие государственную тайну особой важности | | **2** | Гостайна совершенно секретно | | **3** | Гостайна секретно | | **4** | ЗОКИИ I категории, не содержащие гостайны | | **5** | ЗОКИИ II категории (типичный уровень для коммерческих ЗОКИИ) | | **6** (низший) | ЗОКИИ III категории | **Связь с категорией значимости (правило):** - ЗОКИИ **1 категории**: СрЗИ **не ниже 4 уровня доверия**. - ЗОКИИ **2 категории**: СрЗИ **не ниже 5 уровня доверия**. - ЗОКИИ **3 категории**: СрЗИ **не ниже 6 уровня доверия**. **Важное правило 5+ уровня:** для получения оценки соответствия 5 уровню доверия и выше **аппаратная платформа СрЗИ** (процессоры, микроконтроллеры, элементы памяти, сетевые карты, графические адаптеры) **должна быть включена в единый реестр российской радиоэлектронной продукции**. Это де-факто означает использование отечественных платформ для ЗОКИИ 1 и 2 категорий. **Практическое следствие:** МСЭ ПАК Check Point **не может** быть использован как СрЗИ объектов КИИ 1 и 2 категорий (не в реестре российской РЭП). Но **может** быть использован для защиты «общей» ИТ-инфраструктуры субъекта КИИ, в т.ч. для объектов КИИ без присвоенной категории значимости. ## 3.5. Требования к СУБД — приказ ФСТЭК № 64 от 14.04.2023 Если на ЗОКИИ применяется СУБД, она должна соответствовать требованиям к **СУБД** (приказ № 64). Пункт 13 требований обязывает реализовать функцию **гарантированного уничтожения** структурированных данных. **Важное правило:** сертифицированная СУБД должна эксплуатироваться **в среде сертифицированной ОС** (пункт 6 требований). Это означает: если у вас СУБД PostgreSQL Pro Certified, под ней должна быть ОС с сертификатом — например, Astra Linux Special Edition 1.8. ## 3.6. Требования к средствам виртуализации — приказ ФСТЭК № 187 от 27.10.2022 Аналогично СУБД, если на ЗОКИИ используется виртуализация, средства виртуализации (гипервизоры) должны быть сертифицированы и эксплуатироваться **в среде сертифицированной хостовой ОС** (пункт 7 требований). Сертифицированные средства виртуализации в России: ROSA Virtualization, Брест, zVirt и др. ## 3.7. Требования к средствам контейнеризации — приказ ФСТЭК № 118 от 04.07.2022 Если на ЗОКИИ используются контейнеры (Docker, Kubernetes-подобные платформы), средства контейнеризации должны быть сертифицированы и эксплуатироваться в **сертифицированной хостовой ОС** (пункт 7 требований). ## 3.8. Профили защиты ОС ФСТЭК утвердила профили защиты для трёх типов ОС: - **Тип А** (профили защиты от 08.02.2017) — ОС многопользовательских систем общего назначения. - **Тип Б** (профили защиты от 11.05.2017) — серверные ОС. - **Тип В** (профили защиты от 11.05.2017) — встраиваемые ОС, ОС для специальных систем. Сертификация ОС идёт по этим профилям. **Сертифицированные ОС обязаны реализовать функцию гарантированного уничтожения неструктурированных данных** (отдельные файлы). Примеры сертифицированных ОС: Astra Linux Special Edition 1.8 (тип Б), РОСА «Кобальт», МСВС, ОС Эльбрус и др. ## 3.9. Запрет на СрЗИ из недружественных стран Согласно **пункту 6 Указа Президента № 250** от 01.05.2022, субъектам КИИ **запрещено** использовать средства защиты информации, страны происхождения которых являются недружественными иностранными государствами. **Перечень недружественных стран** утверждён распоряжением Правительства РФ. На 2026 год в перечень входят страны ЕС, США, Великобритания, Канада, Австралия, Япония, ряд других. **Не входят** в перечень: Израиль, Китай, Индия, ОАЭ, Турция и ряд других. **Практический пример из FAQ КИИ** (ноябрь 2024): - Check Point (Израиль) — **допустим** для общей ИТ-инфраструктуры, но **не как СрЗИ объектов КИИ 1 и 2 категорий** (не в реестре российской РЭП). - Microsoft Windows / встроенные функции защиты — **запрещены** на ЗОКИИ для реализации функций безопасности. Можно использовать встроенные функции защиты от НСД, либо сертифицированные наложенные СЗИ. ## 3.10. Доверенные ПАК (Углубление по сравнению с днём I — раздел 2.8.) **Доверенный ПАК** (по ПНСТ 905—2023 и ПП № 1912) — программно-аппаратный комплекс, соответствующий **одновременно** трём критериям: 1. Сведения о ПАК **содержатся в едином реестре российской радиоэлектронной продукции**. 2. ПАК **соответствует** установленному комплексу требований к ПО (Приказ ФСТЭК). 3. При реализации функций ЗИ — соответствует **требованиям ФСТЭК и/или ФСБ** (подтверждается сертификатом). **Архитектура доверенного ПАК** (по материалам В.Г. Карантаева, НЭК.ТЕХ): - **Аппаратная база** (SoC + аппаратный корень доверия / СКЗИ); - **Средства доверенной загрузки** (Secure Boot, Encrypted Boot); - **Защищённая встраиваемая ОС** (типа В); - **Прикладное ПО** с реализованными функциями безопасности; - **ПО СКЗИ** (по приказам ФСБ); - **СрЗИ от НСД**; - **Контроль целостности** на всех уровнях. **Переход на доверенные ПАК** регулируется **ПП № 1912** от 14.11.2023. **Реестр ПАК** ведётся в рамках единого реестра российских программ для ЭВМ и БД (ПП-1236 от 16.11.2015). Критерии включения ПАК в реестр частично совпадают с критериями отнесения к доверенным. ## 3.11. Криптографическая защита информации При использовании СКЗИ на объектах КИИ применяются требования **ФСБ России**, а не ФСТЭК. Базовые документы: - ФЗ от 06.04.2011 № 63-ФЗ «Об электронной подписи». - Постановление Правительства от 16.04.2012 № 313 — лицензирование деятельности в области криптографии. - Приказ ФСБ от 09.02.2005 № 66 — Положение по разработке СКЗИ. - ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015, ГОСТ Р 34.13-2015 — российские криптоалгоритмы (Стрибог, Магма, Кузнечик). **Особенность:** для использования СКЗИ требуется лицензия ФСБ на работу со средствами криптографической защиты (для разработки и эксплуатации). Для эксплуатации в собственных целях — лицензия не нужна (за определёнными исключениями). В составе технического проекта СОИБ ЗОКИИ при использовании ЭП или иных типов шифрования должны быть указаны: - Криптопровайдеры и носители ключевой информации (токены); - Для защиты каких компонентов и для реализации каких мер ИБ они применяются; - Номера мер из приказа № 239 (например, ИАФ.4 — защита аутентификационной информации, ОЦЛ.2 — целостность с использованием ЭП). ## 3.12. Проект изменений в приказы 235/239 (2026) (Опубликован 07.04.2026, планируемое вступление в силу — **01.09.2026**.) Вводит для ЗОКИИ два новых показателя: - **Кзи** — показатель защищённости значимого объекта КИИ; - Оценивается не реже **1 раза в 6 месяцев**; - Рассчитывается на основе модели угроз и фактического состояния защиты. - **Пзи** — показатель уровня зрелости мер безопасности; - Оценивается не реже **1 раза в 2 года**; - Учитывает не только наличие мер, но и качество их реализации, эксплуатации, мониторинга. **При несоответствии нормированным значениям:** - Уведомление руководителя субъекта в течение **3 календарных дней**. - Направление результатов оценки во ФСТЭК в течение **5 рабочих дней**. Это объективное закрепление перехода от «однажды аттестовали — забыли» к **непрерывному самомониторингу защищённости**, что согласуется с приказом ФСТЭК № 117 для ГИС (с 01.03.2026). ## 3.13. Контрольные вопросы блока 3 1. Чем отличаются приказы ФСТЭК № 235 и № 239? 2. Перечислите 18 групп мер защиты по приказу № 239. 3. Что такое уровни доверия СрЗИ? Какой уровень требуется для ЗОКИИ 1, 2, 3 категорий? 4. Что обязательно для аппаратной платформы СрЗИ 5+ уровня доверия? 5. Какие требования установлены к СУБД, средствам виртуализации, контейнеризации? 6. Какие три типа профилей защиты ОС утверждены ФСТЭК? 7. Что запрещает пункт 6 УП-250 и какие страны входят в перечень недружественных? 8. Какие три критерия должен соблюдать доверенный ПАК? 9. Что вводят показатели Кзи и Пзи (проект изменений 235/239)? --- > ### 🏁 Конец блока 3 — 15:00 > > Все 18 групп мер защиты разобраны на уровне требований. Введены приказы 76, 64, 187, 118, профили защиты ОС, доверенные ПАК. > > ### ☕ Перерыв: 15:00 — 15:10 (10 минут) > > Кофе-брейк перед блоком 4 «Порядок выбора мер» — там будет практическое задание. --- # Блок 4. Меры обеспечения безопасности ЗО КИИ. Порядок выбора мер (15:10 — 16:40) > ### ▶ Начало блока 4 — 15:10 > > Тема: алгоритм выбора, адаптации и обоснования мер из приказа № 239 для конкретного ЗОКИИ. В середине блока — **практическое задание**: адаптировать базовый набор мер приказа № 239 под условный ЗОКИИ категории 2. ## 4.1. Логика выбора мер по приказу № 239 Процесс выбора мер ИБ для ЗОКИИ — **трёхшаговый**: ``` ┌─────────────────────────┐ ┌───────────────────────┐ ┌────────────────────────┐ │ ШАГ 1 │ │ ШАГ 2 │ │ ШАГ 3 │ │ Применение БАЗОВОГО │───→│ ИСКЛЮЧЕНИЕ │───→│ ВКЛЮЧЕНИЕ │ │ НАБОРА мер │ │ неактуальных мер │ │ компенсирующих мер │ │ по категории значимости │ │ (по модели угроз) │ │ + защита от иных угроз │ └─────────────────────────┘ └───────────────────────┘ └────────────────────────┘ ``` ## 4.2. Шаг 1. Базовый набор мер В приказе № 239 для каждой меры указаны категории, для которых она обязательна: | Категория значимости | Базовый набор мер | |----------------------|-------------------| | **1 категория** | Самый широкий — практически все меры | | **2 категория** | Средний | | **3 категория** | Самый компактный | Применить базовый набор = **взять все меры, отмеченные «+» для нашей категории**, и считать их обязательными к реализации. **Источник базового набора** — приложения к приказу № 239 (таблицы мер по 18 группам). ## 4.3. Шаг 2. Исключение неактуальных мер Базовый набор — не догма. Из него можно **исключить меру**, если: - В системе **отсутствует объект или процесс**, к которому мера относится. Пример: меры по защите беспроводных сетей не нужны, если Wi-Fi не используется. - Угроза, для нейтрализации которой предназначена мера, **не актуальна** по модели угроз. Пример: меры защиты от утечки по техническим каналам — если в КЗ нет иностранных делегаций. - **Технически невозможна** реализация (но в этом случае нужны компенсирующие меры). **Каждое исключение обосновывается** в техническом проекте СОИБ. Без обоснования ФСТЭК на проверке потребует объяснений или включения меры обратно. ## 4.4. Шаг 3. Компенсирующие меры Если базовая мера исключена, но угроза при этом остаётся актуальной — нужна **компенсирующая мера**. **Принципы выбора компенсирующих:** - **Достижение того же эффекта** другим способом. - **Описание в тех. проекте СОИБ** — что компенсирует, как, насколько эффективно. - **Согласование** с регулятором при существенных отступлениях. Пример: - Базовая мера: «ИАФ.4 — Защита аутентификационной информации» (хеширование паролей). - Технически невозможна (legacy-система не поддерживает). - **Компенсирующая:** усиленная физическая защита помещения с этой системой + ограничение доступа к ней до 2 администраторов с непрерывным логированием действий. ## 4.5. Адаптация под актуальные угрозы Помимо базового набора, выбор мер привязывается к **модели угроз** (см. блок 2 сегодняшнего дня): - Для каждой актуальной угрозы должна быть **хотя бы одна** мера, её нейтрализующая. - Связь «угроза → мера» документируется в техническом проекте СОИБ. **Принцип:** меры приказа № 239 — это **функции**, а не «бумажки». Для каждой меры разрабатываются процедуры, фиксируются ответственные, проверяется эффективность. ## 4.6. Технический проект СОИБ — состав Технический проект подсистемы безопасности (СОИБ) для ЗОКИИ должен содержать: 1. **Назначение и цели** СОИБ. 2. **Описание ЗОКИИ** (краткое, отсылка к подробному описанию). 3. **Модель угроз и модель нарушителя** (приложение или отсылка). 4. **Принципы построения** СОИБ. 5. **Структурная схема** СОИБ. 6. **Перечень мер ИБ** с привязкой к угрозам и группам мер приказа № 239. 7. **Технические средства** (СрЗИ, СКЗИ, средства ГосСОПКА) — производитель, модель, версия, сертификаты, уровни доверия. 8. **Обоснование выбора** каждого средства. 9. **Архитектура размещения** средств в инфраструктуре. 10. **Регламенты** эксплуатации. 11. **Программа испытаний** СОИБ. ## 4.7. Этапы внедрения СОИБ 1. **Проектирование** — разработка тех. проекта СОИБ; согласование с СБ, ИТ, бизнес-подразделениями. 2. **Закупки** — приобретение СрЗИ и СКЗИ; контракты на работы. 3. **Внедрение** — установка, настройка, интеграция. 4. **Предварительные испытания** — проверка работоспособности. 5. **Опытная эксплуатация** — параллельный режим с существующими процессами. 6. **Приёмочные испытания** — комиссионная приёмка. 7. **Ввод в эксплуатацию** — приказ о вводе. 8. **Эксплуатация и сопровождение** — основной режим работы (всё остальное время). ## 4.8. Привлечение сторонних организаций (аутсорсинг) Согласно **пункту 11 приказа № 235**, допускается привлечение сторонних организаций для реализации функций по обеспечению безопасности ЗОКИИ — **передача процессов на аутсорсинг**. **Требования к аутсорсеру:** - Лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации (если объект не работает с гостайной); - Лицензия ФСТЭК на деятельность по технической защите информации, составляющей государственную тайну (если объект работает с гостайной); - Лицензия ФСБ на работу с СКЗИ — если требуется криптография; - Соглашения о конфиденциальности с сотрудниками аутсорсера. **Но!** Согласно **УП-250**, на стороне субъекта КИИ **обязательно** должны быть определены: 1. **Заместитель руководителя** субъекта КИИ, ответственный за ИБ. 2. **Структурное подразделение**, осуществляющее функции по обеспечению ИБ. 3. **Персональная ответственность руководителя** за обеспечение ИБ. То есть **полностью** передать ИБ-функцию на аутсорсинг нельзя — минимально нужен заместитель по ИБ и структурное подразделение по ИБ в штатной численности субъекта КИИ. ## 4.9. ПРАКТИЧЕСКОЕ ЗАДАНИЕ ### Условия задания **Условная организация:** ООО «РегионТранс», субъект КИИ в сфере **транспорта**. **Объект КИИ:** информационная система диспетчерского управления городскими автобусами. **Категория значимости:** **2 категория** (на основании социальной значимости — нарушение работы городского транспорта в городе с населением 1,2 млн чел.). **Архитектура объекта:** - Серверный сегмент в собственном ЦОД: 4 сервера (виртуализация на VMware vSphere — **планируется замена** на отечественное решение к концу 2026 г.), СУБД PostgreSQL Pro Certified, прикладное ПО собственной разработки. - АРМ диспетчеров: 12 рабочих станций под Windows 10, **планируется миграция на Astra Linux SE 1.8**. - АРМ операторов мониторинга: 6 АРМ на Astra Linux SE 1.8. - Сетевая инфраструктура: ЛВС в КЗ, МСЭ (отечественный, сертифицированный), ИБП. - Связь с автобусами: GPS/ГЛОНАСС-модули на бортах + GSM-канал (через российского оператора). - **Подключение к Интернету:** ограниченное, только для обновления карт и обновления ОС — через выделенный шлюз с МСЭ и СОВ. - **Подключение к ГосСОПКА:** есть, через корпоративный центр. **Бизнес-процессы:** - Управление маршрутами и расписаниями; - Диспетчерский контроль (мониторинг движения, GPS-треки); - Связь с водителями; - Передача данных пассажирам (приложение). **Модель нарушителей** (упрощённо): - Внутренние Н1 (диспетчеры, обслуживающий персонал) — актуальны. - Внутренние Н2 (подрядчик-разработчик ПО) — актуальны. - Внешние Н1 (хакеры-одиночки) — актуальны. - Внешние Н3 (преступные группы — попытка вымогательства через ransomware) — актуальны. - Внешние Н4 (спецслужбы) — **не актуальны** по решению комиссии по категорированию (отсутствие признаков национального значения). ### Что требуется сделать 1. **Шаг 1 — базовый набор.** Возьмите 18 групп мер приказа № 239. Выпишите, какие меры обязательны для категории 2 (опираясь на приложения приказа № 239, в учебных целях — на ваш экспертный взгляд по логике). 2. **Шаг 2 — исключение.** Обоснуйте, какие меры **можно исключить** из базового набора с учётом конкретных условий «РегионТранса». Минимум 5 примеров с обоснованием. Например: - Меры по защите от угроз облака — нет облака. - Меры по защите Wi-Fi — Wi-Fi не используется. - И т.д. 3. **Шаг 3 — компенсирующие.** Для двух исключённых или ослабленных мер предложите компенсирующие меры. Опишите, почему компенсирующая мера решает ту же задачу. 4. **Шаг 4 — привязка к угрозам.** Возьмите 5 наиболее актуальных угроз для этого объекта (из БДУ ФСТЭК) и привяжите к каждой минимум одну меру из приказа № 239 (по коду группы мер: ИАФ, УПД, АВЗ, СОВ и т.д.). 5. **Шаг 5 — оформление.** Оформите результат в виде **таблицы**: | № | Группа мер (код) | Базовая (для кат. 2) | Применить? | Обоснование | Угрозы, которые нейтрализует | |---|------------------|----------------------|-----------|-------------|------------------------------| | 1 | ИАФ.1 | да | да | … | УБИ-30, УБИ-86 | | 2 | ИАФ.2 | да | да | … | … | | … | … | … | … | … | … | ### Время на выполнение - **Самостоятельная работа:** 40–50 минут. - **Обсуждение:** 20 минут (фронтально или в группах). - **Разбор слайдов 96–99** — типовые решения и ловушки. ### Критерии оценки - Полнота охвата 18 групп мер; - Корректность обоснований исключений (нет ли преувеличений); - Реалистичность компенсирующих мер; - Связь «мера ↔ угроза» прослеживается логически. ## 4.10. Типовые ошибки выбора мер - **«Применяем всё подряд»** — игнорирование исключений. Дорого и нерационально. - **«Исключаем всё неудобное»** — без обоснования. ФСТЭК на проверке вернёт. - **Компенсирующая мера слабее базовой** — не покрывает угрозу полностью. - **Меры не привязаны к угрозам** — нечем оправдать выбор перед регулятором. - **Документация одна, реальность другая** — на проверке ФСТЭК заметит. - **Не учтены **внешние** требования** (152-ФЗ для ПДн, ГОСТы для гостайны) при их пересечении с приказом 239. - **Игнорирование сертификации сред** — несертифицированная хостовая ОС под сертифицированной СУБД. ## 4.11. Контрольные вопросы блока 4 1. Опишите трёхшаговый алгоритм выбора мер по приказу № 239. 2. На каком основании можно исключить меру из базового набора? 3. Что такое компенсирующая мера и когда она применяется? 4. Какие требования предъявляются к аутсорсеру в области ИБ ЗОКИИ? 5. Что должен содержать технический проект СОИБ? 6. Какие минимальные требования к организационной структуре субъекта КИИ по УП-250? 7. Какие типовые ошибки совершают при выборе мер? --- > ### 🏁 Конец блока 4 — 16:40 > > Базовый набор → исключения → компенсирующие → привязка к угрозам — алгоритм отработан в практическом задании на кейсе ООО «РегионТранс». > > ### ☕ Перерыв: 16:40 — 16:50 (10 минут) > > Последний кофе-брейк перед финальным блоком — про уязвимости. --- # Блок 5. Уязвимости объектов КИИ. Классификация и оценка критичности уязвимостей (16:50 — 18:20) > ### ▶ Начало блока 5 — 16:50 > > Тема: уязвимости — что это, чем отличаются от угроз, как классифицируются, как оцениваются по новой методике ФСТЭК от 30.06.2025 и как организован процесс управления уязвимостями. ## 5.1. Понятие уязвимости и её отличие от угрозы **Уязвимость** (по ГОСТ Р 50922—2006) — недостаток (слабость) объекта или его свойств, который может быть использован для реализации угроз безопасности информации. **Уязвимость — это:** - **Свойство объекта** (системы, ПО, конфигурации), а не действие. - **Существует независимо** от того, есть ли нарушитель. - **Может быть использована** для реализации угрозы. **Связь с угрозой:** ``` УГРОЗА ← (использует) ← УЯЗВИМОСТЬ ← (в составе) ← АКТИВ ``` Угроза существует абстрактно, уязвимость — конкретно в системе. Без уязвимости угроза не реализуется. Без угрозы уязвимость безопасна. ## 5.2. Виды уязвимостей ### По месту возникновения - **Уязвимости кода** (програмные ошибки, CWE). Например: переполнение буфера, SQL-инъекция, XSS, использование уязвимых функций. - **Уязвимости конфигурации** — некорректные настройки. Например: открытые порты, слабые пароли по умолчанию, отключённое логирование. - **Уязвимости архитектуры** — изначально неверные решения. Например: отсутствие сегментации сети, использование plain HTTP вместо HTTPS, доверие всем входящим запросам. - **Уязвимости организации** — слабости процессов и людей. Например: отсутствие процедур, недостаточное обучение, плохое управление учётными записями. ### По типу (классификация CWE — Common Weakness Enumeration) Международная база CWE — каталог уязвимостей по типам (>1000 записей). Примеры: - CWE-79 — Cross-site Scripting (XSS); - CWE-89 — SQL Injection; - CWE-119 — Buffer Overflow; - CWE-287 — Improper Authentication; - CWE-352 — CSRF; - CWE-787 — Out-of-bounds Write; - и т.д. ### По степени критичности (CVSS — Common Vulnerability Scoring System) CVSS — международная шкала оценки уязвимостей. На текущий момент актуальна **CVSS v4.0** (с 2023 г.), также активно используется **CVSS v3.1**. Шкала CVSS — от 0,0 до 10,0: | CVSS | Уровень | |------|---------| | 0.0 | None | | 0.1–3.9 | Low | | 4.0–6.9 | Medium | | 7.0–8.9 | High | | 9.0–10.0 | Critical | В России CVSS используется для предварительной оценки, **но не как обязательная** — для ЗОКИИ и ГИС применяется методика ФСТЭК. ## 5.3. Источники сведений об уязвимостях ### Российские - **БДУ ФСТЭК — bdu.fstec.ru** — Банк данных угроз безопасности информации; раздел «Уязвимости» содержит сотни записей с привязкой к УБИ (угрозам) и мерам защиты. - **Бюллетени НКЦКИ** — оперативные сведения об активно эксплуатируемых уязвимостях. - **Бюллетени отраслевых CERT** (FinCERT, RU-CERT, отраслевые центры компетенций). ### Международные - **NVD — National Vulnerability Database (nvd.nist.gov)** — крупнейшая публичная база CVE. - **CVE — Common Vulnerabilities and Exposures (cve.mitre.org)** — единая система идентификаторов уязвимостей. - **CVSS — Common Vulnerability Scoring System** — система оценки. - **CWE — Common Weakness Enumeration** — классификация слабостей. - **OWASP Top 10** — ТОП уязвимостей веб-приложений. ### Бюллетени вендоров - Microsoft Security Update Guide, Apple Security Advisories, Adobe, Cisco, Oracle и т.д. - Российские: Astra Group, Postgres Professional, Лаборатория Касперского, Positive Technologies. ### Threat Intelligence (TI) - Коммерческие платформы (Group-IB, Kaspersky, Positive Technologies, BI.ZONE); - Open source (MISP, OTX). ## 5.4. Методический документ ФСТЭК «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» от 30.06.2025 (Углубление по сравнению с днём I — раздел 5.5.) **Утверждён:** ФСТЭК России 30.06.2025. **Заменил:** редакцию от 28.10.2022. **Сфера применения** — расширена в 2025 году: - Государственные информационные системы (ГИС); - Значимые объекты КИИ (ЗОКИИ); - Информационные системы государственных унитарных предприятий (новое!); - Информационные системы государственных учреждений (новое!). **Ключевые изменения от версии 2022:** 1. Расширен скоуп применения. 2. При оценке учитываются результаты: - тестирования на проникновение; - учений (тренировок); - мероприятий эксперимента по повышению защищённости ГИС ФОИВ. 3. Если ИС функционирует на базе инфраструктуры ЦОД — оценка проводится с учётом ЦОД. 4. **Новые показатели в формуле:** - **Iat** — возможность эксплуатации уязвимости в условиях ИС; - **Iimp** — последствия эксплуатации уязвимости в условиях ИС. 5. Изменены весовые коэффициенты и пороги критичности. 6. Уязвимостям в **сертифицированных СрЗИ** автоматически присваивается **критический** уровень (V > 8,0). ## 5.5. Формула расчёта V (упрощённо) Итоговая оценка уровня критичности уязвимости (V) рассчитывается с учётом следующих групп показателей: ``` V = f( B, T, X, Iat, Iimp ) где: B — базовая оценка по CVSS (CVSS-base score) T — временные характеристики (наличие эксплойта, активность эксплуатации, статус патча) X — контекстные характеристики окружения (зависят от ИС: критичность ресурса, наличие компенсирующих мер) Iat — возможность эксплуатации в условиях данной ИС (от 0 до 1) Iimp — последствия эксплуатации в условиях данной ИС (от 0 до 1) ``` Конкретные веса и формулы — в самом методическом документе ФСТЭК. **Принцип:** одна и та же уязвимость может иметь **разный** уровень критичности в разных ИС. Пример: уязвимость CVE-2025-XXXXX в библиотеке OpenSSL: - В ЗОКИИ с публичным веб-сервисом: V > 8 (критический); - В изолированном АРМ без сетевого подключения: V может быть низким (Low). ## 5.6. Пороги уровня критичности (методика 30.06.2025) | Уровень критичности | Новая методика (от 30.06.2025) | Старая методика (от 28.10.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.7. Принцип непрерывного пересчёта Согласно методике 30.06.2025, **пересчёт значения уровня критичности должен осуществляться на постоянной основе** (по возможности — автоматизированными средствами) при выявлении новых сведений об уязвимости: - Выпуск разработчиком обновлений, устраняющих уязвимость; - Появление в открытом доступе средств эксплуатации (PoC); - Появление активной эксплуатации в дикой природе (in-the-wild); - Изменение конфигурации защищаемой ИС. Это требует **автоматизированного процесса VM**, интегрированного с источниками TI. ## 5.8. Управление уязвимостями (Vulnerability Management) — Руководство ФСТЭК от 17.05.2023 **Методический документ ФСТЭК «Руководство по организации процесса управления уязвимостями в органе (организации)»** от 17.05.2023. Устанавливает процесс **VM** как обязательную часть ИБ-функции в ГИС и на ЗОКИИ. ### Этапы процесса VM ``` ┌──────────────────────┐ │ 1. Инвентаризация │ ← всё ПО и ПАК в области защиты должны быть известны │ активов │ └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 2. Сбор информации │ ← БДУ ФСТЭК, NVD, CVE, бюллетени вендоров, TI │ об уязвимостях │ └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 3. Сканирование │ ← автоматизированные сканеры │ │ (российские: MaxPatrol VM, ScanOVAL, RedCheck) └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 4. Оценка критичности│ ← методика ФСТЭК от 30.06.2025 │ в контексте ИС │ └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 5. Приоритизация │ ← Critical → High → Medium → Low │ │ + учёт активной эксплуатации └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 6. Устранение │ ← патчинг, изменение конфигурации, │ │ компенсирующие меры, обходные пути └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 7. Тестирование │ ← методика ФСТЭК от 28.10.2022 │ обновлений │ └────────────┬─────────┘ │ ↓ ┌──────────────────────┐ │ 8. Проверка │ ← повторное сканирование │ результата │ └──────────────────────┘ ``` ## 5.9. Методический документ ФСТЭК «Методика тестирования обновлений безопасности» от 28.10.2022 Регламентирует процесс **безопасного развёртывания** обновлений на ЗОКИИ и ГИС. **Этапы тестирования обновлений:** 1. **Проверка целостности и подлинности обновления** — подписи, контрольные суммы, источник. 2. **Статический анализ** — что входит в обновление, нет ли подозрительного кода. 3. **Динамический анализ** — поведение при работе (сетевые соединения, поведение в памяти). 4. **Тестирование совместимости** с эксплуатируемыми СрЗИ и СКЗИ. 5. **Развёртывание на тестовом стенде** — копия продуктивной среды. 6. **Мониторинг после развёртывания** — отслеживание ошибок и аномалий. **Цель** — исключить ситуации, когда обновление **само становится** источником инцидента (компрометация цепочки поставки SolarWinds-style, отказ совместимости). ## 5.10. Скорость закрытия как KPI В современной практике основной KPI VM-процесса — **скорость закрытия уязвимостей по уровням критичности (SLA):** | Уровень | Типовой SLA | |---------|-------------| | Критический | 24–72 часа | | Высокий | 7 дней | | Средний | 30 дней | | Низкий | 90 дней | Для ЗОКИИ 1 категории — могут быть жёстче. Для конкретной организации SLA утверждаются внутренней политикой ИБ. ## 5.11. Метрики VM - **MTTD (Mean Time to Detect)** — среднее время обнаружения уязвимости (с момента публикации CVE до выявления в инфраструктуре); - **MTTR (Mean Time to Remediate)** — среднее время до устранения; - **Coverage** — доля проинвентаризованных активов, охваченных сканированием; - **Backlog** — количество необработанных уязвимостей по уровням критичности; - **Time-to-patch SLA compliance** — процент уязвимостей, закрытых в установленный SLA. ## 5.12. Связь с моделью угроз Уязвимость — это **то, через что реализуется угроза**. Поэтому: - В **модели угроз** для каждой актуальной угрозы должен быть указан класс уязвимостей, которые могут быть использованы для её реализации. - При обнаружении **новой критической уязвимости** в инфраструктуре — нужно пересмотреть актуальность связанных с ней угроз. - **Закрытие уязвимости** = снижение вероятности реализации угрозы (но не всегда исключает её — нарушитель может найти другой путь). ## 5.13. Связь с инцидент-менеджментом (день I, блоки 4–5) Уязвимости и инциденты — две стороны одной медали: - **Уязвимость + угроза + нарушитель = атака** → если успешна, **инцидент**. - После инцидента — **обратная связь** в реестр уязвимостей: какая уязвимость была использована, какие ещё уязвимости могут быть использованы. - Закрытие уязвимости после инцидента = часть фазы «Ликвидация» жизненного цикла инцидента (см. день I). ## 5.14. Уязвимости в сертифицированных СрЗИ Особая категория — **уязвимости в сертифицированных средствах защиты**. По методике ФСТЭК от 30.06.2025 такие уязвимости автоматически получают критический уровень (V > 8,0). Причины такого подхода: - Сертифицированное СрЗИ — **последний рубеж защиты**. Его компрометация делает уязвимыми все защищаемые им объекты. - Сертификат **подтверждает доверие** к производителю и продукту. Уязвимость = подрыв этого доверия. - Требуется **оперативное информирование ФСТЭК** разработчиком при обнаружении уязвимости в сертифицированном продукте. ## 5.15. Типовые ошибки управления уязвимостями - **Сканирование без инвентаризации** — половина активов не охвачена. - **Сканирование «в продакшен»** без согласования — простой сервисов. - **Реакция только на CVSS-Critical** — пропуск Medium с активной эксплуатацией. - **Патчинг без тестирования** — обновление само ломает систему. - **Нет процесса для компенсирующих мер** — если патч недоступен. - **Метрики собираются, но не анализируются** — нет улучшения. - **VM-команда изолирована** от инцидент-команды и от риск-менеджеров. ## 5.16. Контрольные вопросы блока 5 1. Чем уязвимость отличается от угрозы? 2. Назовите 4 вида уязвимостей по месту возникновения. 3. Что такое CWE, CVE, CVSS, NVD, БДУ ФСТЭК? 4. Каковы пороги критичности по методике ФСТЭК от 30.06.2025? 5. Какие два новых показателя введены в формулу V в методике 2025 года? 6. Опишите 8 этапов процесса управления уязвимостями (VM). 7. Какие этапы тестирования обновлений безопасности по методике ФСТЭК от 28.10.2022? 8. Почему уязвимости в сертифицированных СрЗИ получают критический уровень автоматически? 9. Какие типовые SLA по закрытию уязвимостей по уровням? --- > ### 🏁 Конец блока 5 — 18:20 > > Учебный день завершён. Все 5 блоков пройдены. > > ### 🎓 Итог дня > > От оценки угроз и моделирования (с использованием методики ФСТЭК от 05.02.2021 и БДУ ФСТЭК) — к выбору мер по приказам № 235/239 (с учётом приказа 76 о СрЗИ и связанных приказов 64/187/118) — к управлению уязвимостями (методика 30.06.2025, руководство 17.05.2023). Связали с риск-менеджментом и инцидент-менеджментом из дня I. > > Следующие дни программы переподготовки опираются на эти знания: моделирование угроз становится основой для выбора СЗИ, выбора СКЗИ, выстраивания процессов SOC и взаимодействия с регуляторами. --- # Приложения ## Приложение А. Перечень нормативных документов дня (актуально на май 2026) ### Федеральные законы - ФЗ от 26.07.2017 № 187-ФЗ (в действующей редакции с учётом ФЗ-58 от 07.04.2025 и ФЗ-325 от 31.07.2025). - ФЗ от 27.07.2006 № 152-ФЗ «О персональных данных». - ФЗ от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». - ФЗ от 29.07.2004 № 98-ФЗ «О коммерческой тайне». - ФЗ от 21.07.1993 № 5485-1 «О государственной тайне». - ФЗ от 06.04.2011 № 63-ФЗ «Об электронной подписи». - ФЗ от 07.04.2025 № 58-ФЗ (изм. в 187-ФЗ, с 01.09.2025). - ФЗ от 31.07.2025 № 325-ФЗ (изм. в 187-ФЗ, с 01.03.2026). - ФЗ от 10.07.2002 № 86-ФЗ «О Центральном банке Российской Федерации (Банке России)» — для финансовой сферы. - ФЗ от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов деятельности». - Кодекс об административных правонарушениях РФ (ст. 13.12.1). ### Указы Президента РФ - УП от 30.03.2022 № 166 (технологическая независимость КИИ). - УП от 01.05.2022 № 250 (дополнительные меры по обеспечению ИБ). - УП от 14.04.2022 № 203 (Межведомственная комиссия). - УП от 22.12.2017 № 620 (ГосСОПКА). - УП от 15.01.2013 № 31с (создание ГосСОПКА). ### Постановления Правительства РФ - ПП от 08.02.2018 № 127 (категорирование КИИ; последнее изм. ПП № 1281 от 19.09.2024). - ПП от 17.02.2018 № 162 (государственный контроль). - ПП от 14.11.2023 № 1912 (доверенные ПАК). - ПП от 22.08.2022 № 1478 (требования к ПО на ЗОКИИ). - ПП от 15.07.2022 № 1272 (зам. руководителя по ИБ). - ПП от 16.11.2015 № 1236 (реестр российского ПО). - ПП от 01.11.2012 № 1119 (уровни защищённости ПДн). - **ПП от 16.01.2026 № 4** (отраслевые особенности категорирования — атомная энергия; с 01.09.2026). - **ПП от 06.02.2026 № 92** (банковская сфера и финансовый рынок). - **ПП от 07.03.2026 № 246** (наука). - **ПП от 23.03.2026 № 303** (государственная регистрация прав на недвижимость). - **ПП от 31.03.2026 № 356** (ракетно-космическая промышленность). - **ПП от 13.04.2026 № 402** (связь). - **Распоряжение Правительства от 26.02.2026 № 360-р** (перечень типовых отраслевых объектов КИИ). ### Приказы ФСТЭК - Приказ от 11.04.2025 № 117 (требования к защите ГИС, ИС госорганов; с 01.03.2026). - Приказ от 25.12.2017 № 239 (требования по обеспечению безопасности ЗОКИИ; ред. от 28.08.2024). - Приказ от 21.12.2017 № 235 (системы безопасности ЗОКИИ). - Приказ от 22.12.2017 № 236 (форма направления сведений о категорировании; изм. № 247 от 11.07.2025). - Приказ от 06.12.2017 № 227 (реестр ЗОКИИ; изм. № 254 от 17.07.2025). - Приказ от 11.12.2017 № 229 (форма акта проверки). - Приказ от 16.07.2019 № 135 (перечень НПА для государственного контроля). - Приказ от 28.05.2020 № 75 (подключение ЗОКИИ к сетям общего пользования). - Приказ от 18.04.2021 № 77 (аттестация объектов информатизации). - Приказ от 18.02.2013 № 21 (ИСПДн). - Приказ от 14.03.2014 № 31 (АСУ ТП). - **Приказ от 02.06.2020 № 76** (уровни доверия СрЗИ). - **Приказ от 14.04.2023 № 64** (требования к СУБД). - **Приказ от 27.10.2022 № 187** (требования к средствам виртуализации). - **Приказ от 04.07.2022 № 118** (требования к средствам контейнеризации). - Приказы от 12.05.2025 № 163 и № 164 (лицензионный контроль). - **Проект изменений приказов № 235 и № 239** (от 07.04.2026, плановое вступление — 01.09.2026): показатели Кзи и Пзи. ### Приказы ФСБ (актуальные на май 2026 — после декабря 2025) - Приказ от 24.07.2018 № 366 (НКЦКИ). - Приказ от 24.07.2018 № 367 (Перечень информации в ГосСОПКА). - **Приказ от 23.12.2025 № 539** (порядок получения субъектами КИИ информации о КА; заменил часть приказа № 368). - **Приказ от 25.12.2025 № 546** (порядок обмена информацией о КА и КИ; заменил приказ № 368). - **Приказ от 25.12.2025 № 547** (порядок информирования ФСБ о КА и КИ; заменил приказ № 282 от 19.06.2019). - **Приказ от 25.12.2025 № 548** (порядок непрерывного взаимодействия субъектов КИИ с ГосСОПКА). - **Приказ от 26.12.2025 № 553** (порядок и техусловия установки и эксплуатации средств обнаружения КА; заменил приказ № 281 от 19.06.2019). - **Приказ от 26.12.2025 № 554** (требования к средствам обнаружения КА; заменил приказ № 196 от 06.05.2019). - Приказ от 01.11.2022 № 543 (переходный период по УП-250; с изм. № 282 от 21.07.2025). - Приказ от 11.05.2023 № 213 (мониторинг защищённости). ### Методические документы ФСТЭК - **«Методика оценки угроз безопасности информации» от 05.02.2021** — главный документ блока 1–2 сегодняшнего дня. - **«Методика оценки уровня критичности уязвимостей ПО/ПАК» от 30.06.2025** — главный документ блока 5. - **«Руководство по организации процесса управления уязвимостями» от 17.05.2023** — для VM-процесса. - **«Методика тестирования обновлений безопасности» от 28.10.2022** — для патч-менеджмента. - **«Методика оценки критичности ПО/ПАК» от 28.10.2022** — для приоритизации защиты. - **«Методика оценки показателя состояния защиты информации в ИС и обеспечения безопасности ЗОКИИ» от 11.11.2025** — заменила версию от 02.05.2024. - **Методический документ ФСТЭК от 12.04.2026** — рекомендации по категорированию объектов связи (к ПП-402). - «Рекомендации по разработке Плана реагирования на компьютерные инциденты на ЗОКИИ» (для метакурса по инцидентам — день I). - «Рекомендации по подготовке планов мероприятий при уровнях опасности целевых атак» от 09.08.2021. ### ГОСТы и ПНСТ - ГОСТ Р 50922—2006 (терминология ЗИ). - ГОСТ Р 56546—2015 «Защита информации. Уязвимости информационных систем». - ГОСТ Р 56939—2024 (РБПО). - ГОСТ Р 59548—2022 (регистрация событий безопасности). - ГОСТ Р 59709—2022, 59710—2022, 59711—2022, 59712—2022 (управление компьютерными инцидентами). - ГОСТ Р 70732—2023 (АСУ ТП ЖД). - ГОСТы по криптографии: ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015, ГОСТ Р 34.13-2015. - ПНСТ 905-2023 (доверенные ПАК). - ПНСТ 911-2024 (доверенные ИМС). - ПНСТ 1007-2025, ПНСТ 1009-2025 (ПАК и ПО доверенных ПАК). - **ГОСТ Р 72507-2026** «КИИ. Микросхемы интегральные. Общие требования к производству». - **ПНСТ 1046-2026** «Искусственный интеллект в КИИ. Общие положения». ### Профили защиты ФСТЭК - Профили защиты ОС типа А — от 08.02.2017. - Профили защиты ОС типа Б и В — от 11.05.2017. ### Международные стандарты (ориентир) - CVSS v4.0, v3.1 — Common Vulnerability Scoring System. - CVE, CWE, NVD — international vulnerability databases. - MITRE ATT&CK, MITRE ATT&CK for ICS. - Cyber Kill Chain (Lockheed Martin). - OWASP Top 10. - NIST SP 800-30 (Risk Management Guide). ## Приложение Б. Глоссарий (Дополняет глоссарий из дня I — содержит только новые термины блока II.) - **CVE** — Common Vulnerabilities and Exposures, единый идентификатор уязвимости (например, CVE-2025-12345). - **CVSS** — Common Vulnerability Scoring System, шкала оценки критичности уязвимости от 0 до 10. - **CWE** — Common Weakness Enumeration, классификация слабостей по типам. - **NVD** — National Vulnerability Database (США), крупнейшая публичная база CVE. - **БДУ** — Банк данных угроз ФСТЭК (bdu.fstec.ru). - **VM** — Vulnerability Management, управление уязвимостями. - **MTTD / MTTR** — Mean Time to Detect / Remediate, средние времена обнаружения и устранения. - **MITRE ATT&CK** — матрица тактик и техник атакующих (Adversarial Tactics, Techniques, and Common Knowledge). - **Cyber Kill Chain** — модель этапов целевой атаки (Lockheed Martin). - **Н1, Н2, Н3, Н4** — уровни возможностей нарушителей по методике ФСТЭК от 05.02.2021. - **Кзи** — показатель защищённости ЗОКИИ (проект изменений 235/239 от 07.04.2026). - **Пзи** — показатель зрелости мер безопасности (проект изменений 235/239 от 07.04.2026). - **Iat, Iimp** — показатели возможности и последствий эксплуатации уязвимости в условиях конкретной ИС (методика 30.06.2025). - **V** — итоговая оценка уровня критичности уязвимости (методика 30.06.2025). - **OWASP** — Open Worldwide Application Security Project, сообщество по безопасности веб-приложений. - **OWASP Top 10** — топ-10 уязвимостей веб-приложений (обновляется раз в несколько лет). - **ICS / OT** — Industrial Control Systems / Operational Technology, общее обозначение АСУ ТП и промышленных технологий. - **PoC** — Proof of Concept, демонстрационная реализация эксплойта. - **0-day** — уязвимость, ещё не известная вендору и не закрытая патчем. - **TI** — Threat Intelligence, информация о текущих угрозах. ## Приложение В. Источники к материалам лекции ### Базовая методическая документация ФСТЭК ⭐ **Методический документ ФСТЭК России «Методика оценки угроз безопасности информации»** от 05.02.2021. *Главный методический ориентир для всех видов ИС и КИИ.* ⭐ **Методический документ ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств»** от 30.06.2025. *Главный документ блока 5.* ### Подзаконные акты - Действующая система НПА по КИИ — по состоянию на 18.05.2026 (источник: Telegram-канал «Бюрократическая безопасность», t.me/bureaucraticsecurity). - Свежие документы 2026 года — официальный сайт ФСТЭК (fstec.ru), сайт ФСБ, КонсультантПлюс. ### Практические материалы - **FAQ КИИ ноябрь 2024** (УЦСБ, 187.ussc.ru) — практические ответы экспертов. - **Алгоритм актуализации модели угроз** (В.А. Пиков, авторская методика). - **Учебный кейс категорирования Яндекс.Такси** (УЦ МАСКОМ). - **Карантаев В.Г. Технические требования к доверенным ПАК для АСУ ОКИИ** (ТБ-Форум 2025). ### Международные референсы - NIST SP 800-30 «Guide for Conducting Risk Assessments». - CVSS v4.0 specification (first.org). - MITRE ATT&CK framework (attack.mitre.org). - OWASP Top 10 (owasp.org). - ISO/IEC 27005:2022 (для углублённого изучения). ### Авторские курсы В.А. Пикова - **День I. Риски ИБ, безопасность ЗО КИИ, инциденты** — risk.pikov.expert. - Лекции по безопасности ОС, РБПО, регулированию и др. — pikov.expert (главный каталог). --- # Контакты **Виталий Александрович Пиков** Преподаватель НОУ ДПО «УЦБИ «МАСКОМ» Email: vitaly@pikov.expert Telegram: @UnderLineSecurity Сайт: https://pikov.expert/ Сайт УЦ МАСКОМ: https://mascom-uc.ru/ --- *Документ подготовлен по состоянию на май 2026 года. Все нормативные документы указаны в действующих редакциях на момент подготовки. При практической работе рекомендуется проверять актуальность редакций — нормативная база КИИ обновляется регулярно. Особое внимание: пакет приказов ФСБ декабря 2025 года (№ 539, 546, 547, 548, 553, 554) заменил ранее действовавшие приказы ФСБ № 196, 281, 282, 368.*