Найти в Дзене

Документы под Приказ №117: что нужно кроме политики ИБ

«У нас есть Политика информационной безопасности на 15 страниц. Этого достаточно?» Нет. Политика ИБ — это декларация намерений. ФСТЭК проверяет исполнение. Для соответствия Приказу №117 нужен комплект из 15-25 документов, каждый из которых отвечает на конкретный вопрос регулятора. Ключевые запросы: орд по приказу фстэк 117, документы для фстэк, политика иб гис, комплект документов для аттестации Время чтения: 5 минут Политика ИБ — важный документ. Она устанавливает цели, принципы, распределение ответственности. Но сама по себе она ничего не защищает. При проверке ФСТЭК спросит: как вы управляете уязвимостями? Политика отвечает: «мы управляем уязвимостями в соответствии с требованиями регулятора». Это не ответ. Ответ — регламент управления уязвимостями с описанием процедуры, сроков, ответственных, инструментов. Та же логика для инцидентов, доступа, резервного копирования, взаимодействия с подрядчиками. Каждое требование Приказа №117 должно быть раскрыто в отдельном документе или разделе
Оглавление

«У нас есть Политика информационной безопасности на 15 страниц. Этого достаточно?»

Нет. Политика ИБ — это декларация намерений. ФСТЭК проверяет исполнение. Для соответствия Приказу №117 нужен комплект из 15-25 документов, каждый из которых отвечает на конкретный вопрос регулятора.

Ключевые запросы: орд по приказу фстэк 117, документы для фстэк, политика иб гис, комплект документов для аттестации

Время чтения: 5 минут

Политика ИБ — важный документ
Политика ИБ — важный документ

Миф о «главном документе»

Политика ИБ — важный документ. Она устанавливает цели, принципы, распределение ответственности. Но сама по себе она ничего не защищает.

При проверке ФСТЭК спросит: как вы управляете уязвимостями? Политика отвечает: «мы управляем уязвимостями в соответствии с требованиями регулятора». Это не ответ. Ответ — регламент управления уязвимостями с описанием процедуры, сроков, ответственных, инструментов.

Та же логика для инцидентов, доступа, резервного копирования, взаимодействия с подрядчиками. Каждое требование Приказа №117 должно быть раскрыто в отдельном документе или разделе.

Обязательный минимум ОРД

Акт классификации информационной системы. По новой матрице «уровень значимости × масштаб». Для каждой системы отдельно.

Модель угроз безопасности информации. С учётом новых требований: угрозы контейнеризации (Docker, Kubernetes), угрозы ИИ, угрозы через подрядчиков. Копипаст из БДУ ФСТЭК не пройдёт — модель должна быть адаптирована под конкретную систему.

Техническое задание на систему защиты информации. Требования к СЗИ, архитектура, интеграции.

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

Регламент управления уязвимостями. Процедура сканирования, классификация уязвимостей, SLA (24 часа на критические, 7 дней на высокие), порядок применения компенсирующих мер, ответственные.

Регламент управления инцидентами. Классификация инцидентов, процедура реагирования, эскалация, взаимодействие с НКЦКИ, сроки уведомления.

Регламент расчёта КЗИ. Периодичность, источники данных, процедура расчёта, верификация, формат отчёта в ФСТЭК.

Порядок взаимодействия с ГосСОПКА. Технические требования, форматы обмена, ответственные, процедура передачи сведений об инцидентах.

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

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

Частые ошибки в ОРД

Несоответствие реальности. Документ описывает процесс, которого нет. Регламент управления уязвимостями есть, сканер не закуплен. При проверке это квалифицируется как фальсификация.

Отсутствие привязки к конкретной системе. Универсальные шаблоны из интернета не работают. Документ должен содержать название системы, её характеристики, конкретных ответственных с должностями и ФИО.

Копипаст старых норм. Ссылки на Приказ №17, устаревшие ГОСТы, отменённые методики. Документы должны актуализироваться при изменении нормативной базы.

Избыточность. 200 страниц политики ИБ, которую никто не читал. Документ должен быть рабочим инструментом, а не памятником бюрократии.

Отсутствие версионности. Нет истории изменений, непонятно, какая версия актуальна. При проверке это создаёт хаос.

Как выйти из документного ада

Принцип 1: сначала процессы, потом документы. Нельзя описать то, чего нет. Сначала выстройте процесс управления уязвимостями — потом опишите его в регламенте. Иначе получится фикция.

Принцип 2: один документ — одна функция. Не смешивайте управление уязвимостями с управлением инцидентами в одном документе. Это затрудняет актуализацию и проверку.

Принцип 3: разделяйте «витрину» и рабочие инструменты. Политика ИБ — это витрина для регулятора и руководства. Рабочие регламенты — для исполнителей. Они могут (и должны) различаться по стилю и детализации.

Принцип 4: встраивайте актуализацию в процесс. Документ, который не обновляется — мёртвый документ. Включите пересмотр ОРД в регулярные процедуры: при изменении инфраструктуры, при обновлении нормативки, при инцидентах.

Комплект ОРД — это не разовый проект, а живая система. Она требует поддержки, но без неё соответствие Приказу №117 недоказуемо.

Telegram: @fishchuk_pravo

-2