📜 НПА: Приказ ФСТЭК № 21 от 18.02.2013
«Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»
Документ определяет набор обязательных мер защиты ПДн, применяемых в зависимости от уровня защищенности ИСПДн.

📚 Общая информация
⇢ Источник: https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21
⇢ Область: ИСПДн

⚖️ Основные положения
⇢ Таблица с организационными и техническими мерами в зависимости от уровня защищенности (УЗ-4, УЗ-3, УЗ-2, УЗ-1 и усиленные).
⇢ Классификация ИСПДн на уровни защищенности (1–4).
⇢ Определение актуальных угроз безопасности персональных данных.
⇢ Использование сертифицированных СрЗИ при необходимости.
⇢ Документирование процедур безопасности и обработки ПДн.
⇢ Оценка эффективности применяемых мер защиты.

🔎 Дополнительная информация
⇢ Уровень защищенности выбирается по ПП № 1119 — это ключевой шаг перед выбором мер по Приказу № 21.
⇢ Требования актуальны для всех операторов ПДн, включая малый бизнес.
⇢ Корректная модель угроз определяет достаточность и обоснованность мер защиты.

🔗 Связанные НПА
⇢ 152-ФЗ «О персональных данных»
⇢ Постановление Правительства РФ № 1119 (уровни защищенности ИСПДн)
⇢ Методика ФСТЭК по моделированию угроз

🛠 Практическая реализация
⇢ Разработка положения о защите ПДн и локальных нормативных актов по основным направлениям ИБ (доменам).
⇢ Создание модели угроз по методике ФСТЭК и акта определения уровня защищенности ИСПДн.
⇢ Применение СЗИ от НСД, антивирусов, МЭ, СКЗИ (при необходимости).
⇢ Обеспечение сегментации сети и сетевой изоляции.
⇢ Управление доступом, разделение ролей и прав в ИСПДн.
⇢ Регистрация и мониторинг событий безопасности, реагирование на инциденты.
⇢ Регулярное резервное копирование и восстановление.

Больше — по тегу #НПА

☰ Все | 🏠 Главная

✅ УПД.10 – Блокирование сеанса доступа в информационную систему после установленного времени бездействия или по запросу пользователя (Приказ ФСТЭК № 21)
Требование обязывает автоматически блокировать активный сеанс пользователя при отсутствии его действий в течение заданного времени, а также обеспечивать возможность ручной блокировки по инициативе самого пользователя.

⏳ Примечания по применимости
Требование распространяется на:
⇢ рабочие станции, терминальные сессии, веб-приложения, ВМ;
⇢ учетные записи сотрудников, администраторов и внешних пользователей/
Не распространяется на:
-

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

🧰 Лучшие практики
⇢ Настройка автоблокировки через 3–15 минут бездействия (по уровню угрозы);
⇢ Возможность мгновенной ручной блокировки (Win+L, кнопка «Выйти»/«Lock»);
⇢ Блокировка не только экрана, но и активных веб-сессий;
⇢ Обязательное повторное прохождение аутентификации после разблокировки;
⇢ Логирование фактов блокировки/разблокировки.

🏷 Примеры
⇢ Пример 1: Рабочая станция блокируется автоматически через 10 минут неактивности, разблокировка требует повторного ввода пароля.
⇢ Пример 2: Веб-система завершает сессию через 15 минут простоя и требует повторного логина.

🧩 Индивидуальный подход
Допускается варьировать:
⇢ время бездействия до блокировки;
⇢ параметры для разных категорий пользователей (администраторы, внешние);
⇢ способы ручной блокировки.
Главное — обеспечение контроля и фиксированный регламент.

📖 Термины
Сеанс доступа | сессия | рабочая станция | терминальный сервер | автоблокировка

🔎 Дополнительная информация
⇢ Оставленные незаблокированными рабочие места — один из самых распространенных векторов внутренних нарушений.
⇢ Автоблокировка повышает уровень защиты даже при дисциплинарных рисках.

🔬 Способы тестирования
⇢ Проверка настроек автоблокировки ОС, приложений и веб-сервисов;
⇢ Тестирование блокировки по истечении времени;
⇢ Проверка журналов событий;
⇢ Интервью с администраторами.

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ УПД.11 – Разрешение (запрет) действий пользователей, доступных до идентификации и аутентификации (Приказ ФСТЭК № 21)
Требование предписывает определить, какие действия допускаются до входа пользователя в систему, а также ограничить или запретить любые операции, способные повлиять на безопасность ИС без прохождения аутентификации.

🚪 Примечания по применимости
Требование распространяется на:
⇢ веб-приложения, личные кабинеты, корпоративные сервисы;
⇢ терминальные и локальные системы с интерфейсом до входа;
⇢ информационные панели, формы запроса, публичные разделы.
Не распространяется на:
-

🎯 Цель
⇢ Исключить выполнение критичных действий до прохождения аутентификации.
⇢ Предотвратить утечки, просмотр данных, изменение настроек или подготовку атаки без входа в систему.
⇢ Создать безопасную границу между «публичной зоной» и защищенной частью ИС.

🧰 Лучшие практики
⇢ Четкое определение минимального набора доступных действий до входа (например, просмотр инструкции, форма обратной связи);
⇢ Запрет доступа к API, закрытым разделам и административным функциям;
⇢ Ограничение отображаемой информации (без персональных данных);
⇢ Логирование действий, доступных до аутентификации;
⇢ Ограничение попыток взаимодействия (например, капча).

🏷 Примеры
⇢ Пример 1: До входа пользователь может только просмотреть страницу авторизации и справочную информацию.
⇢ Пример 2: Попытки обращения к API без токена отклоняются системой и логируются.

🧩 Индивидуальный подход
Допустимо изменять:
⇢ перечень разрешенных действий до входа;
⇢ глубину проверки публичных запросов;
⇢ механизм ограничения (капча, rate limiting, белые списки).
Главное — минимизация функционала до аутентификации.

📖 Термины
Действия до аутентификации | капча | rate limiting | белые списки | API | brute-force | логи

🔎 Дополнительная информация
⇢ Разрешенный функционал должен быть безопасным, устойчивым к атакам и исключать манипуляции с данными.
⇢ Важно учитывать риски, связанные с brute-force и обходом проверок.

🔬 Способы тестирования
⇢ Анализ публичных страниц и API;
⇢ Проверка попыток выполнения запрещенных действий до входа;
⇢ Анализ логов;
⇢ Интервью с администраторами и разработчиками.

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

🔥 Тренды ПДн: итоги недели 01.12–07.12

1. 🧑‍💼 Ответственный по ПДн по ГПХ: можно ли так?
Организации обсуждают, можно ли назначить ответственным по ПДн исполнителя по ГПХ. Вопрос касается различий в ответственности и рисков при отсутствии трудовых отношений.
Мнения экспертов:
⇢ ✅ За: закон не требует, чтобы ответственным был именно работник; аутсорсинг широко используется.
⇢ ❌ Против: лицо по ГПХ может не иметь достаточных полномочий и устойчивой связи с внутренними процессами.
Вывод: возможно, но критично обеспечить доступ к процессам, регламентам и управленческим решениям.

2. 🌐 Тильда, хостинг и указание ЦОДов
Поднимается практический вопрос: нужно ли перечислять все ЦОДы Тильды (Селектел, Яндекс и др.) в документации оператора, если сайт собран на конструкторе и содержит ПДн.
Мнения экспертов:
⇢ ✅ За: если Тильда фактически участвует в обработке, корректно указывать ее инфраструктуру.
⇢ ❌ Против: не всегда возможно точно определить весь перечень ЦОДов, а РКН такой детализации прямо не требует.
Вывод: достаточно указывать Тильду как обработчика; при необходимости — ссылаться на официальную документацию сервиса.

3. 🎯 Лиды без согласия: можно ли обойтись пользовательским соглашением?
Компании ищут правовое основание для обработки лидов, по которым субъект не оставлял явного согласия.
Мнения экспертов:
⇢ ✅ За: если лиды приходят через сайт, можно продумать UX так, чтобы пользователь соглашался с правилами обработки (оферта, пользовательское соглашение).
⇢ ❌ Против: если дальше идут маркетинговые контакты, пользовательское соглашение не спасает — риски уже по линии ФАС и ст. 15 152-ФЗ.
Вывод: ПС может легитимизировать обработку, но не маркетинг; для маркетинга требуется СОПД.

4. 🧾 ИП и регистрация у РКН: что нужно иметь
Индивидуальные предприниматели уточняют, какие документы обязаны подготовить для соблюдения 152-ФЗ.
Мнения экспертов:
⇢ ✅ За: для уведомления РКН документы не требуются; важно определить цели, состав данных и процессы.
⇢ ❌ Против: игнорирование реальной схемы обработки ПДн приводит к ошибкам в уведомлении.
Вывод: необходим минимальный набор ЛНА: политика, регистры процессов, меры защиты, документы по основаниям обработки.

5. 🆔 ОГРН как ПДн: является или нет?
Обсуждают, относится ли ОГРН к персональным данным, если используется рядом с ФИО ИП и иными сведениями.
Мнения экспертов:
⇢ ✅ За: ОГРНИП может считаться ПДн, но ОГРН юрлица — нет.
⇢ ❌ Против: комбинация нескольких сведений может формировать связку с физлицом.
Вывод: ОГРНИП является ПДн в отличии от ОГРН ЮЛ.

6. 🏨 Передача ФИО гостиницам: поручение или нет?
Работодатели передают списки ФИО работников в гостиницы для командировок.
Мнения экспертов:
⇢ ✅ За: гостиница обрабатывает ПДн на основании закона и своей деятельности, поручение не требуется.
⇢ ❌ Против: важно уведомить субъектов в приказе или информационном уведомлении.
Вывод: ни согласие, ни поручение не нужны; достаточно уведомления работников.

7. 💳 Зарплатные проекты и аутсорс-бухгалтерия
Компании спрашивают, можно ли включить передачу ПДн в банк в согласие на поручение обработки ПДн бухгалтерии.
Мнения экспертов:
⇢ ✅ За: можно объединить в одно согласие, но только если деятельность требует письменной формы.
⇢ ❌ Против: решение о зарплатном проекте принимает работодатель; поручение бухгалтеру не заменяет правовое основание передачи в банк.
Вывод: передачу в банк можно оформить без согласия через коллективный договор или ЛНА; бухгалтерия — отдельный обработчик.

8. 📄 Политика vs ЛНА: что обязательно указывать?
Развернулась дискуссия: должен ли оператор включать цели, сроки, категории ПДн и третьих лиц прямо в политику.
Мнения экспертов:
⇢ ✅ За: РКН часто требует раскрытия информации в политике; субъекты должны понимать, что происходит.
⇢ ❌ Против: закон не обязывает включать детальные процессы в политику; это рекомендуется, но не обязательно.
Вывод: политика — про принципы; конкретика — в ЛНА. Однако во избежание споров с РКН многие операторы расширяют содержание публичной политики.

Больше — по тегу #ТрендыПДн

☰ Все | 🏠 Главная

✅ ЗНИ.8 – Уничтожение (стирание) или обезличивание персональных данных на машинных носителях при их передаче между пользователями, в сторонние организации для ремонта или утилизации, а также контроль уничтожения (стирания) или обезличивания (Приказ ФСТЭК № 21)
Требование устанавливает необходимость гарантировать полное удаление или обезличивание ПДн перед передачей носителей другим пользователям, сторонним организациям или при выводе их из эксплуатации.

🗂 Примечания по применимости
Требование распространяется на:
⇢ жесткие диски, SSD, флеш-накопители, мобильные устройства;
⇢ серверные и пользовательские носители;
⇢ передачу оборудования на ремонт, обслуживание, утилизацию.
Не распространяется на:
⇢ носители, не содержащие ПДн (при документированном подтверждении).

🎯 Цель
⇢ Предотвратить утечку ПДн при передаче носителей третьим лицам.
⇢ Исключить восстановление данных с МНИ после их вывода из эксплуатации.
⇢ Обеспечить безопасную смену владельцев носителей.

🧰 Лучшие практики
⇢ Использование таких методов стирания, как многократная перезапись, криптографическое стирание;
⇢ Обезличивание данных, если их необходимо сохранить в аналитических целях;
⇢ Фиксация факта уничтожения в актах;
⇢ Запрет передачи неисправных носителей без предварительного стирания;
⇢ Контроль подрядчиков, осуществляющих ремонт или утилизацию.

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

🧩 Индивидуальный подход
Допускается адаптировать:
⇢ методы уничтожения (механическое, программное, криптостирание);
⇢ порядок оформления актов;
⇢ уровень контроля подрядчиков.
Главное — невозможность восстановления ПДн.

📖 Термины
МНИ | уничтожение данных | обезличивание данных | контроль подрядчиков | вывод из эксплуатации

🔎 Дополнительная информация
⇢ SSD требуют специальных методов стирания из-за особенностей работы контроллеров.

🔬 Способы тестирования
⇢ Проверка регламентов уничтожения/обезличивания;
⇢ Анализ актов списания и журналов передачи оборудования;
⇢ Проверка наличия инструментов для безопасного стирания;
⇢ Интервью с администраторами и ИБ.

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ РСБ.7 – Защита информации о событиях безопасности (Приказ ФСТЭК № 21)
Требование предписывает обеспечивать защиту журналов событий безопасности (логов) от несанкционированного доступа, изменения, удаления или подмены, поскольку эти данные критичны для расследования инцидентов и контроля безопасности.

🔐 Примечания по применимости
Требование распространяется на:
⇢ журналы ОС, приложений, СрЗИ, сетевых устройств, контейнеров;
⇢ централизованные системы логирования (SIEM, syslog);
⇢ архивы логов и резервные копии.
Не распространяется на:
⇢ системы, где журналы отсутствуют по архитектуре (при документированном обосновании).

🎯 Цель
⇢ Обеспечить целостность и достоверность записей событий безопасности.
⇢ Исключить подмену журналов злоумышленниками.
⇢ Сохранить данные для последующего анализа и расследований.

🧰 Лучшие практики
⇢ Пользователи и администраторы не должны иметь возможность изменять логи;
⇢ Передача логов на отдельный защищенный сервер или SIEM;
⇢ Контроль целостности (хеширование, электронная подпись);
⇢ Резервное копирование журналов;
⇢ Журналирование попыток доступа к самим логам.

🏷 Примеры
⇢ Пример 1: Логи с серверов автоматически отправляются в SIEM, куда ограничен доступу для администраторов этих серверов.
⇢ Пример 2: Целостность архивных журналов контролируется через электронные подписи.

🧩 Индивидуальный подход
Можно варьировать:
⇢ механизмы защиты (подписи, хеш-деревья, WORM-хранилища);
⇢ уровни доступа к логам;
⇢ глубину дублирования и резервирования.
Главное — невозможность корректировки записей задним числом.

📖 Термины
Логи | контроль целостности | резервное копирование | SIEM | syslog | подмена логов злоумышленниками | утечка логов

🔎 Дополнительная информация
⇢ Компрометация журналов — один из ключевых признаков попытки скрыть следы атаки.
⇢ Логи должны храниться отдельно от систем, которые их генерируют.

🔬 Способы тестирования
⇢ Анализ прав доступа к журналам;
⇢ Проверка настроек SIEM/syslog;
⇢ Проверка механизмов контроля целостности;
⇢ Интервью с администраторами и ИБ.

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

❗️Технические работы в Базе знаний ПД№1 пройдут в субботу 13 декабря с 11:00 до 13:00

Буду выкладывать карточки по следующим блокам:
1) Требования для УЗ-3 (приказ ФСТЭК № 21)
2) новые #Термины

🛎 Отключите на время уведомления в тг, чтобы я вас не спамил 😊

💬 Карточки базы знаний можно не читать в моменте, а возвратиться к ним, когда будет нужно найти ответ на конкретный вопрос.

✅ АНЗ.1 – Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей (Приказ ФСТЭК № 21)
Требование предписывает регулярно выявлять уязвимости в ИС, анализировать их критичность и своевременно устранять, чтобы исключить использование слабых мест злоумышленниками.

🛠 Примечания по применимости
Требование распространяется на:
⇢ серверы, рабочие станции, сетевое оборудование;
⇢ прикладное ПО, веб-приложения, базы данных;
⇢ средства защиты информации и компоненты инфраструктуры.
Не распространяется на:
⇢ полностью изолированные системы (при документированном подтверждении и компенсирующих мерах), где требование выполнить невозможно в силу объективных причин

🎯 Цель
⇢ Предотвратить эксплуатацию известных уязвимостей.
⇢ Снизить вероятность инцидентов, связанных с устаревшими версиями ПО.
⇢ Обеспечить безопасное состояние ИС в условиях постоянно меняющихся угроз.

🧰 Лучшие практики
⇢ Проведение регулярного сканирования уязвимостей (ежемесячно или чаще);
⇢ Мониторинг бюллетеней безопасности (CVE, производителя ПО, ФСТЭК);
⇢ Оценка критичности уязвимостей и приоритизация устранения;
⇢ Устранение критичных уязвимостей в кратчайшие сроки;
⇢ Ведение журнала уязвимостей и контроля сроков исправления.

🏷 Примеры
⇢ Пример 1: После выхода патча, закрывающего критичную уязвимость для веб-сервера, он устанавливается в течение суток, результат фиксируется в системе учета.
⇢ Пример 2: Ежемесячное сканирование инфраструктуры выявляет уязвимости, которые затем закрываются обновлениями или харденингом настроек.

🧩 Индивидуальный подход
Допускается адаптировать:
⇢ периодичность и очередность сканирования;
⇢ глубину проверок (сетевой сканинг, анализ конфигураций, ручные тесты);
⇢ сроки устранения в зависимости от критичности.
Главное — фиксированный процесс и контроль исполнения.

🔎 Дополнительная информация
⇢ Многие атаки используют давно известные уязвимости.
⇢ Важна связка АНЗ.1 → АНЗ.2 (обновления ПО) для полной защиты.

🔬 Способы тестирования
⇢ Анализ регламентов выявления и устранения уязвимостей;
⇢ Проверка журналов сканирования (Nessus, MaxPatrol и др.);
⇢ Сверка фактического состояния систем с отчетами;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Уязвимость | сканер уязвимостей | устранение уязвимости | критичность уязвимости | Nessus | MaxPatrol | анализ конфигураций | ручная верификация уязвимостей | изолированная система | веб-сервер | CVE | харденинг

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ АНЗ.3 – Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации (Приказ ФСТЭК № 21)
Требование обязывает операторов регулярно контролировать состояние ПО и СрЗИ, проверять корректность их настроек и своевременно выявлять отклонения, влияющие на безопасность и стабильность ИС.

🧭 Примечания по применимости
Требование распространяется на:
⇢ операционные системы, серверные и клиентские приложения;
⇢ средства защиты информации (СЗИ от НСД, МЭ, антивирусы, СКЗИ);
⇢ сетевое и системное оборудование.
Не распространяется на:
⇢ тестовые стенды без доступа к ИС и ПДн (при документированном обосновании).

🎯 Цель
⇢ Предотвратить сбои, уязвимости и ошибки, возникающие из-за неверных настроек или отказов ПО/СрЗИ.
⇢ Обеспечить стабильную и защищенную работу всех компонентов ИС.
⇢ Исключить ситуации, когда СрЗИ формально установлено, но не функционирует.

🧰 Лучшие практики
⇢ Регулярная проверка работоспособности сервисов и СрЗИ;
⇢ Контроль конфигураций через политики, шаблоны и бенчмарки;
⇢ Мониторинг состояния ПО и СрЗИ в режиме реального времени;
⇢ Алерты при отключении или некорректной работе СрЗИ;
⇢ Периодический аудит настроек и сопоставление с эталонными значениями.

🏷 Примеры
⇢ Пример 1: Состояние антивирусных модулей проверяется ежедневным мониторингом, отключенные агенты попадают в отчет.
⇢ Пример 2: Конфигурации межсетевых экранов регулярно сравниваются с утвержденными эталонами, выявленные расхождения устраняются.

🧩 Индивидуальный подход
Допускается адаптация:
⇢ периодичности контроля (ежедневно/еженедельно/по событиям);
⇢ глубина проверки (поверхностные health-check или полный аудит конфигураций);
⇢ инструментов мониторинга (SIEM, Zabbix, специализированные решения).
Главное — непрерывность контроля и документированные процедуры.

🔎 Дополнительная информация
⇢ Неверная настройка часто становится критичнее самой уязвимости.
⇢ Контроль настроек — ключевой элемент DevSecOps и процессов эксплуатации.

🔬 Способы тестирования
⇢ Анализ регламентов контроля настроек и работоспособности;
⇢ Проверка журналов мониторинга и отчетов по состоянию СрЗИ;
⇢ Сверка конфигураций с эталонными шаблонами;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Конфигурация | уязвимость | health-check | baseline | алерт | бенчмарк | агент безопасности | параметры настройки | DevSecOps | Zabbix | СрЗИ | СЗИ от НСД | межсетевой экран | СКЗИ | тестовый стенд

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ АНЗ.4 – Контроль состава технических средств, программного обеспечения и средств защиты информации (Приказ ФСТЭК № 21)
Требование обязывает вести учет, отслеживать изменения и регулярно контролировать фактический состав оборудования, установленного ПО и СрЗИ, чтобы исключить появление несанкционированных устройств или программ в ИС.

🧭 Примечания по применимости
Требование распространяется на:
⇢ все серверы, рабочие станции, сетевые устройства;
⇢ операционные системы, прикладное ПО, зависимости;
⇢ СрЗИ: антивирусы, СЗИ от НСД, межсетевые экраны, СКЗИ.
Не распространяется на:
⇢ тестовые и изолированные системы без связи с ИС (при документированном исключении).

🎯 Цель
⇢ Предотвратить установку несанкционированного ПО и оборудования.
⇢ Своевременно выявлять отклонения в составе ИС.
⇢ Обеспечить соответствие фактической конфигурации утвержденной.

🧰 Лучшие практики
⇢ Ведение реестра оборудования, ПО и СрЗИ;
⇢ Использование автоматизированных средств инвентаризации (CMDB);
⇢ Регулярный контроль изменений состава устройств и ПО;
⇢ Уведомления при появлении неизвестных хостов или программ;
⇢ Запрет установки ПО без согласования и прав админа.

🏷 Примеры
⇢ Пример 1: CMDB автоматически собирает информацию о версии ОС, установленном ПО и наличии СрЗИ. Несоответствия фиксируются в отчетах.
⇢ Пример 2: При появлении неизвестного сетевого устройства система мониторинга отправляет уведомление службе ИБ.

🧩 Индивидуальный подход
Можно адаптировать:
⇢ глубину контроля (только ПО / ПО + драйверы / ПО + оборудование + настройки);
⇢ частоту инвентаризации;
⇢ методы выявления изменений (сканирование, агенты).
Главное — фиксируемый и регулярный процесс сверки.

🔎 Дополнительная информация
⇢ Наличие неучтенного оборудования (shadow IT) — частая причина инцидентов.
⇢ Контроль состава критичен для систем с повышенными требованиями безопасности.

🔬 Способы тестирования
⇢ Проверка реестров ПО, оборудования и СрЗИ;
⇢ Сравнение фактического состава с CMDB/учетными журналами;
⇢ Анализ отчетов о выявленных отклонениях;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Инвентаризация | прикладное ПО | системное ПО | зависимости | shadow IT | состав ПО | контроль состава ПО | состав ИСПДн | технологический стек | CMDB | права администратора | сканирование | сканер уязвимостей | агент безопасности

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ ЗСВ.3 – Регистрация событий безопасности в виртуальной инфраструктуре (Приказ ФСТЭК № 21)
Требование обязывает фиксировать события безопасности, возникающие на уровне гипервизоров, виртуальных машин, виртуальных сетей и средств управления виртуализацией, чтобы обеспечить анализ и расследование инцидентов.

🧭 Примечания по применимости
Требование распространяется на:
⇢ гипервизоры (VMware ESXi, Hyper-V, KVM);
⇢ управляющие панели (vCenter, SCVMM, Proxmox);
⇢ виртуальные машины, виртуальные сети и хранилища;
⇢ операции администрирования и автоматизации (API, скрипты).
Не распространяется на:
⇢ физические сегменты без использования виртуализации.

🎯 Цель
⇢ Обеспечить контроль всех критичных событий виртуальной среды.
⇢ Предотвратить скрытые изменения, несанкционированные операции и атаки внутри виртуальной инфраструктуры.
⇢ Обеспечить возможность расследования инцидентов на уровне ВМ и гипервизора.

🧰 Лучшие практики
⇢ Логирование действий администраторов и операций управления ВМ;
⇢ Фиксация создания, удаления, изменения конфигурации ВМ;
⇢ Регистрация операций снапшотов, миграции и работы API;
⇢ Передача логов в SIEM для корреляции;
⇢ Контроль целостности журналов и ограничение доступа к ним.

🏷 Примеры
⇢ Пример 1: vCenter отправляет логи о создании, изменении и удалении ВМ в центральный SIEM.
⇢ Пример 2: Все действия администраторов гипервизора фиксируются, включая изменения сетевых и дисковых настроек.

🧩 Индивидуальный подход
Допускается адаптация:
⇢ перечня регистрируемых событий;
⇢ уровня детализации логов;
⇢ методов доставки (syslog, агент, API).
Главное — фиксировать критически значимые операции управления виртуальной средой.

🔎 Дополнительная информация
⇢ События виртуальной среды часто становятся единственным источником информации при расследовании инцидентов, связанных с ВМ.
⇢ Особое внимание требуется для API-доступа и автоматизации.

🔬 Способы тестирования
⇢ Проверка настроек логирования в гипервизорах и управляющих панелях;
⇢ Анализ журналов событий виртуализации;
⇢ Проверка маршрутизации логов в SIEM;
⇢ Интервью с администраторами виртуальной инфраструктуры.

📖 Термины
Событие ИБ | гипервизор | виртуальная машина | виртуальная сеть | средства управления виртуализацией | логи | события среды виртуализации | инцидент ИБ | расследование инцидентов ИБ | VMware ESXi | Hyper-V | KVM | vCenter | SCVMM | Proxmox | API | скрипт | атаки на виртуальную инфраструктуру | проверка настроек логирования в гипервизорах | проверка настроек логирования в управляющих панелях | проверка маршрутизации логов в SIEM

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ ЗСВ.9 – Реализация и управление антивирусной защитой в виртуальной инфраструктуре (Приказ ФСТЭК № 21)
Требование обязывает обеспечивать полноценную антивирусную защиту виртуальной среды, включая гипервизоры, виртуальные машины, золотые образы, а также механизмы централизованного управления защитой и контроля состояния.

🛡 Примечания по применимости
Требование распространяется на:
⇢ виртуальные машины (серверные и пользовательские);
⇢ шаблоны ВМ, снапшоты, золотые образы;
⇢ гипервизоры и управляющие сервисы, если они подвержены вредоносному ПО.
Не распространяется на:
⇢ полностью изолированные ВМ без доступа к сети и внешним данным (при документированном исключении).

🎯 Цель
⇢ Предотвратить заражение виртуальных машин и распространение вредоносного ПО внутри виртуальной среды.
⇢ Защитить критичные ВМ и управляющие компоненты виртуализации.
⇢ Обеспечить контроль состояния антивирусной защиты на всех виртуальных объектах.

🧰 Лучшие практики
⇢ Использование специализированных антивирусов для виртуальных сред;
⇢ Централизованное управление антивирусом через сервер управления;
⇢ Сканы образов, шаблонов и снапшотов перед развертыванием;
⇢ Мониторинг актуальности баз и состояния агентов;
⇢ Исключение отключения антивируса внутри ВМ без санкции ИБ.

🏷 Примеры
⇢ Пример 1: Виртуальные серверы защищены agentless-антивирусом, работающим через службы интеграции гипервизора, нагрузка минимальна.
⇢ Пример 2: Шаблоны ВМ регулярно проверяются, чтобы исключить развертывание зараженных образов.

🧩 Индивидуальный подход
Допускается адаптация:
⇢ использование разных типов антивирусных агентов;
⇢ частоту и глубину сканирования;
⇢ политики обновления баз в изолированных сегментах.
Главное — обеспечить непрерывность защиты.

🔎 Дополнительная информация
⇢ В виртуальных средах заражение одной ВМ может быстро распространиться на другие через общие ресурсы или шаблоны.
⇢ Контроль антивируса должен охватывать как живые ВМ, так и базовые образы.

🔬 Способы тестирования
⇢ Проверка наличия антивирусных решений на ВМ и в управляющей среде;
⇢ Анализ логов обновлений и состояния агентов;
⇢ Проверка защиты шаблонов и образов;
⇢ Интервью с администраторами виртуализации и ИБ.

📖 Термины
Антивирусная защита | agentless-антивирус | гипервизор | виртуальная машина | базовый образ ВМ | health-check | снапшот | заражение виртуальной машины | контроль состояния антивирусной защиты | мониторинг актуальности баз | агент безопасности

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ ЗСВ.10 – Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей (Приказ ФСТЭК № 21)
Требование предписывает сегментировать виртуальную инфраструктуру таким образом, чтобы обеспечить изоляцию обработки ПДн между разными пользователями и группами, исключая несанкционированный доступ и пересечение информационных потоков.

🧩 Примечания по применимости
Требование распространяется на:
⇢ виртуальные машины, пулы ВМ, виртуальные сети и хранилища;
⇢ гипервизоры и управляющие платформы (vCenter, SCVMM, Proxmox);
⇢ среды обработки ПДн различными пользователями и подразделениями.
Не распространяется на:
⇢ среды, где доступ к ПДн осуществляется строго одним пользователем (при документированном исключении).

🎯 Цель
⇢ Исключить доступ пользователей к данным других пользователей/групп.
⇢ Предотвратить пересечение трафика и утечку ПДн между сегментами.
⇢ Повысить управляемость и безопасность виртуальной среды.

🧰 Лучшие практики
⇢ Создание отдельных виртуальных сетей/VLAN для разных групп;
⇢ Использование распределенных виртуальных свичей с ACL и правилами безопасности;
⇢ Разделение хранилищ и пулов ресурсов по пользователям/подразделениям;
⇢ Раздельные папки ВМ в управляющих панелях с привязкой прав;
⇢ Ограничение межсегментных взаимодействий через межсетевой экран.

🏷 Примеры
⇢ Пример 1: Подразделение HR использует отдельный сегмент: выделенная виртуальная сеть, отдельное хранилище и ограниченные права в vCenter.
⇢ Пример 2: Исполнительные ВМ клиентов в облачной среде разделены по проектам, между ними отсутствуют сетевые маршруты.

🧩 Индивидуальный подход
Допускается адаптация:
⇢ глубины сегментации (по пользователям, департаментам, типам данных);
⇢ методов изоляции (VLAN, VXLAN, виртуальные FW, микросегментация);
⇢ использования отдельных пулов ресурсов для критичных данных.
Главное — обеспечить реальную техническую изоляцию.

🔎 Дополнительная информация
⇢ Сегментирование — ключевой элемент Zero Trust в виртуальных инфраструктурах.
⇢ Гипервизор должен обеспечивать гарантию отсутствия межсегментной утечки.

🔬 Способы тестирования
⇢ Анализ схем виртуальных сетей и ресурсов;
⇢ Проверка ACL, FW и политик микросегментации;
⇢ Тестирование отсутствия взаимодействия между сегментами;
⇢ Интервью с администраторами виртуальной инфраструктуры.

📖 Термины
Виртуальная инфраструктура | пул ВМ | гипервизор | vCenter | SCVMM | Proxmox | сегментирование виртуальной инфраструктуры | микросегментация | информационный поток | группы пользователей | ACL | сетевой маршрут | VLAN | VXLAN | виртуальный FW | Zero Trust

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ ЗИС.20 – Защита беспроводных соединений, применяемых в информационной системе (Приказ ФСТЭК № 21)
Требование обязывает обеспечивать защищенное использование беспроводных технологий в ИС, предотвращая перехват, подмену и несанкционированный доступ через Wi-Fi и другие радиоканалы.

📡 Примечания по применимости
Требование распространяется на:
⇢ корпоративные Wi-Fi сети, беспроводные контроллеры, точки доступа;
⇢ мобильные устройства сотрудников;
⇢ беспроводные сегменты, задействованные в обработке ПДн или служебных данных.
Не распространяется на:
⇢ участки сети, где беспроводной доступ отключен и документированно запрещен.

🎯 Цель
⇢ Предотвратить несанкционированное подключение к ИС через радиоканал.
⇢ Исключить перехват или подмену данных, передаваемых по беспроводным сетям.
⇢ Снизить риски атак типа rogue-AP, MITM и перехвата трафика.

🧰 Лучшие практики
⇢ Использование современных протоколов защиты (WPA3, WPA2-Enterprise + 802.1X);
⇢ Аутентификация пользователей через RADIUS/сертификаты;
⇢ Изоляция гостевых и корпоративных сетей;
⇢ Отключение WPS, устаревших шифров и открытых SSID;
⇢ Мониторинг и обнаружение rogue-AP и подозрительных устройств.

🏷 Примеры
⇢ Пример 1: Корпоративный Wi-Fi использует WPA2-Enterprise, аутентификация проводится через RADIUS, гости — в отдельном сегменте.
⇢ Пример 2: Система обнаружения Wi-Fi-угроз автоматически блокирует попытки подключения к несанкционированным точкам доступа.

🧩 Индивидуальный подход
Допускается адаптация:
⇢ методов аутентификации (сертификаты, EAP-TLS, учетные записи AD);
⇢ уровней сегментации и изоляции;
⇢ требований к мобильным устройствам (MDM, шифрование).
Главное — исключить доступ к ИС через незащищенные беспроводные каналы.

🔎 Дополнительная информация
⇢ Беспроводные сети — один из наиболее уязвимых векторов атак.
⇢ Необходимо регулярно проводить радиоаудит и проверку конфигураций.

🔬 Способы тестирования
⇢ Проверка настроек Wi-Fi точек доступа и контроллеров;
⇢ Сканирование на наличие rogue-AP;
⇢ Анализ журналов аутентификации и шифрования;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Беспроводные технологии | беспроводные сети | беспроводные контроллеры | точка доступа Wi-Fi | гостевая сеть | мобильные устройства | rogue-AP | MITM | перехвата трафика | WPA3 | 802.1X | RADIUS | SSID | мониторинг точек доступа

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ УКФ.1 – Определение лиц, которым разрешены действия по внесению изменений в конфигурацию информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21)
Требование предписывает формально определить круг лиц, имеющих право изменять конфигурации ИС и систем защиты ПДн, чтобы исключить несанкционированные и неконтролируемые изменения.

👤 Примечания по применимости
Требование распространяется на:
⇢ администраторов систем, сетей, БД;
⇢ администраторов СрЗИ;
⇢ лиц, ответственных за эксплуатацию ИС и ее конфигураций.
Не распространяется на:
⇢ пользователей, не выполняющих технические функции и не имеющих прав на изменение конфигурации.

🎯 Цель
⇢ Исключить внесение изменений в ИС посторонними лицами.
⇢ Обеспечить прозрачность, подотчетность и контроль всех изменений.
⇢ Снизить риски инцидентов из-за ошибок, саботажа или несанкционированных действий.

🧰 Лучшие практики
⇢ Формальное закрепление перечня ответственных лиц (приказ, регламент, матрица ролей);
⇢ Использование ролевой модели (RBAC) для администраторов;
⇢ Разделение администраторских функций между ролями (сети, БД, СрЗИ);
⇢ Двухфакторная аутентификация для привилегированных пользователей;
⇢ Журналирование всех изменений конфигураций.

🏷 Примеры
⇢ Пример 1: Перечень администраторов систем и СрЗИ утверждается приказом, доступ предоставляется только им.
⇢ Пример 2: Для изменений конфигурации межсетевого экрана требуется авторизация через привилегированный доступ и запись в журнал.

🧩 Индивидуальный подход
Допускается варьировать:
⇢ детализацию ролей (администратор ОС / БД / виртуализации / СрЗИ);
⇢ процедуру предоставления и отзыва прав;
⇢ контроль доступа через специализированные PAM-системы.
Главное — документировать и контролировать полномочия.

🔎 Дополнительная информация
⇢ Неопределенные полномочия — частая причина критичных инцидентов.
⇢ Лучший подход — совмещение RBAC + приказов + PAM.

🔬 Способы тестирования
⇢ Проверка приказов и регламентов назначения ответственных;
⇢ Анализ фактических прав администраторов (AD/LDAP, роли в системах);
⇢ Проверка журналов изменений;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Конфигурация ИС | система защиты ПДн / СЗПДн | несанкционированные изменения | привилегированный пользователь | непривилегированный пользователь | неотказуемость | матрица ролей | RBAC | системный администратор | MFA | БД | журналирование событий ИБ | PAM | AD| LDAP

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ УКФ.2 – Управление изменениями конфигурации информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21)
Требование обязывает организовать контролируемый процесс изменения конфигураций ИС и систем защиты ПДн, чтобы исключить хаотичные, несанкционированные или рискованные изменения, влияющие на безопасность и устойчивость системы.

🔧 Примечания по применимости
Требование распространяется на:
⇢ серверы, рабочие станции, сетевое оборудование, СрЗИ;
⇢ виртуальную инфраструктуру и облачные сервисы;
⇢ системные и прикладные настройки, политики доступа.
Не распространяется на:
⇢ изменения, не влияющие на безопасность или работу ИС (например, пользовательские настройки интерфейса).

🎯 Цель
⇢ Исключить неконтролируемые изменения конфигурации.
⇢ Обеспечить предсказуемость, стабильность и безопасность работы ИС.
⇢ Снизить риски инцидентов, связанных с ошибками конфигурации.

🧰 Лучшие практики
⇢ Введение формализованной процедуры Change Management;
⇢ Разделение сред: Dev ⇢ Stage ⇢ Prod;
⇢ Тестирование изменений перед внедрением;
⇢ Обязательное документирование и логирование всех изменений;
⇢ Применение системы контроля конфигураций (GPO, Ansible).

🏷 Примеры
⇢ Пример 1: Перед изменением правил на межсетевом экране создается RFC (Request for Change), проводится проверка ИБ и тестирование в тестовой среде.
⇢ Пример 2: Изменение параметров сервера фиксируется в журнале изменений; доступ к инструментам изменений — только у уполномоченных лиц.

🧩 Индивидуальный подход
Организация может адаптировать:
⇢ глубину проверки изменений (по уровню риска);
⇢ порядок согласований (ИБ, эксплуатация, руководитель);
⇢ степень автоматизации внесения и контроля изменений.
Главное — все изменения должны быть управляемыми и прослеживаемыми.

🔎 Дополнительная информация
⇢ Неправильная конфигурация — одна из самых частых причин утечек и инцидентов.
⇢ Использование DevOps/DevSecOps практик может повысить качество и скорость внедрения изменений.

🔬 Способы тестирования
⇢ Проверка регламентов управления изменениями;
⇢ Анализ журналов изменений (журналы CI/CD, системы управления конфигурациями);
⇢ Сверка фактической конфигурации с baseline;
⇢ Интервью с администраторами и ИБ.

📖 Термины
Управление изменениями / Change Management | RFC (Request for Change) | СЗПДн | политика доступа | Dev-среда | Stage-среда | Prod-среда | тестирование изменений | журналирование событий безопасности | система контроля конфигураций | Ansible | GPO | DevSecOps | CI/CD

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ УКФ.3 – Анализ потенциального воздействия планируемых изменений в конфигурации информационной системы и системы защиты персональных данных на обеспечение защиты персональных данных и согласование изменений в конфигурации информационной системы с должностным лицом (работником), ответственным за обеспечение безопасности персональных данных (Приказ ФСТЭК № 21)
Требование устанавливает необходимость оценивать риски, которые могут возникнуть из-за планируемых изменений конфигурации, и согласовывать такие изменения с назначенным лицом, ответственным за обеспечение безопасности ПДн.

🧭 Примечания по применимости
Требование распространяется на:
⇢ изменения конфигураций серверов, сетевого оборудования, виртуальной инфраструктуры;
⇢ изменения настроек СрЗИ;
⇢ корректировки политик доступа, логирования, сегментации;
⇢ внедрение нового ПО, обновлений и модулей.
Не распространяется на:
⇢ косметические изменения, не влияющие на безопасность (например, UI-настройки).

🎯 Цель
⇢ Предотвратить внесение изменений, способных ослабить защиту ПДн.
⇢ Обеспечить участие специалиста по ИБ в процессе изменений.
⇢ Снизить риски инцидентов, вызванных небезопасными конфигурациями.

🧰 Лучшие практики
⇢ Проведение формализованного анализа рисков перед изменением (impact assessment);
⇢ Согласование изменений с ответственным за безопасность ПДн и ИБ-службой;
⇢ Тестирование изменений в тестовой среде;
⇢ Оценка влияния изменений на доступы, журналы, сегментацию, шифрование;
⇢ Документирование результатов анализа и решений по внедрению.

🏷 Примеры
⇢ Пример 1: Перед изменением политики межсетевого экрана проводится оценка риска влияния на защищенность ПДн, решение согласуется ответственным за ИБ.
⇢ Пример 2: Внедрение нового модуля CRM проходит анализ на предмет возможного доступа к ПДн и согласовывается с ответственным за СЗПДн.

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

🔎 Дополнительная информация
⇢ Изменения конфигурации — одна из ключевых причин инцидентов, связанных с нарушением безопасности ПДн.
⇢ Согласование помогает избежать незамеченных рисков и ошибок конфигурирования.

🔬 Способы тестирования
⇢ Проверка регламентов оценки и согласования изменений;
⇢ Анализ журналов Change Management;
⇢ Проверка наличия согласований в документации по RFC;
⇢ Интервью с ответственным за безопасность ПДн и администраторами.

📖 Термины
Конфигурация ИС | СЗПДн | Change Management | RFC (Request for Change) | impact assessment | СрЗИ | изменения конфигурации ИС | ответственный за обеспечение безопасности ПДн | служба ИБ I UI

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная

✅ УКФ.4 – Документирование информации (данных) об изменениях в конфигурации информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21)
Требование обязывает фиксировать все изменения конфигурации ИС и СЗПДн, обеспечивая полноту и прослеживаемость действий, влияющих на безопасность персональных данных.

🗂 Примечания по применимости
Требование распространяется на:
⇢ изменения конфигураций серверов, сетевого оборудования, виртуальной инфраструктуры;
⇢ изменения настроек СрЗИ;
⇢ корректировки политик доступа, логирования, сегментации;
⇢ внедрение нового ПО, обновлений и модулей.
Не распространяется на:
⇢ косметические изменения, не влияющие на безопасность (например, UI-настройки).

🎯 Цель
⇢ Обеспечить возможность восстановления истории изменений для расследований и аудита.
⇢ Исключить несанкционированные или незаметные изменения конфигурации.
⇢ Повысить управляемость и прозрачность процессов эксплуатации.

🧰 Лучшие практики
⇢ Ведение журнала изменений (Change Log) в рамках процесса Change Management;
⇢ Фиксация: даты, автора, описания изменения, согласований и результатов внедрения;
⇢ Автоматизация записи изменений через системы управления конфигурациями (Ansible, GPO);
⇢ Хранение записей в защищенном репозитории (PAM/CMDB/SIEM);
⇢ Привязка изменений к инцидентам, заявкам и задачам.

🏷 Примеры
⇢ Пример 1: Изменение правил межсетевого экрана фиксируется в системе управления изменениями: кто внес, когда, что изменил, кем согласовано.
⇢ Пример 2: Настройки сервера документируются автоматически в CMDB после каждого развертывания Ansible-скрипта.

🧩 Индивидуальный подход
Допускается варьировать:
⇢ глубину документирования (минимальная/расширенная);
⇢ уровень автоматизации;
⇢ формат хранения записей (электронный журнал, система заявок, CMDB).
Главное — изменения должны быть полными, однозначными и прослеживаемыми.

🔎 Дополнительная информация
⇢ Документирование облегчает расследование инцидентов и подтверждение соответствия требованиям ИБ.
⇢ Полезно сочетать журнал изменений с baseline-конфигурациями.

🔬 Способы тестирования
⇢ Проверка журналов изменений, записей RFC и CMDB;
⇢ Сравнение фактических конфигураций с документированными;
⇢ Проверка целостности хранилища изменений;
⇢ Интервью с администраторами и специалистами ИБ.

📖 Термины
Конфигурация ИС | изменения конфигурации ИС | СЗПДн | Change Management | RFC (Request for Change) | Change Log | Ansible | GPO | PAM | CMDB | SIEM | соответствие требованиям ИБ

Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3

☰ Все | 🏠 Главная