«Проверки по 152-ФЗ — не экзамен на сообразительность, а сверка операционной реальности с тем, что вы сами же декларировали регулятору. Фокус проверяющих предсказуем, потому что он задан вашими же документами: они идут не куда угодно, а туда, куда вы их сами направили своими актами категорирования, перечнями СЗИ и политиками.»
Почему вектор проверки заранее известен
ФСТЭК или Роскомнадзор не начинают исследование организации с чистого листа. Основой для проверки служат документы, уже представленные в эти органы: модель угроз, акт категорирования, список используемых средств защиты информации (СЗИ). Регулятор работает методологически, проверяя соответствие деклараций фактическому положению дел в тех узлах, которые сама организация обозначила как значимые.
С практической точки зрения это означает, что проверяющие экономят ресурсы, концентрируясь на заранее определённых точках приложения. Если в перечне СЗИ указан конкретный межсетевой экран, проверка будет изучать его настройки, журналы и интеграцию, а не искать в сети неизвестные средства. Их цель — убедиться, что заявленное работает так, как описано в представленных вами документах.
Три области, которые проверка изучит досконально
Проверка не ставит задачу найти нарушение любой ценой. Её цель — выявить системные расхождения. Именно поэтому внимание концентрируется на трёх ключевых точках, где такие расхождения возникают чаще всего.
1. Разрыв между документами и реальными процессами
Это основное поле для найденных нарушений. Проверка начинает с ваших внутренних нормативных документов — политики информационной безопасности, регламентов управления доступом, инструкций по резервному копированию. Затем она запрашивает операционные доказательства их исполнения.
Типичный сценарий: в регламенте прописано, что выдача прав администратора требует согласования руководителя ИБ-службы и директора по ИТ. При запросе журналов системы управления учётными записями или заявок в ITSM-системе оказывается, что за последний год ни одна такая операция не была задокументирована, при этом новые администраторы в системе появлялись.
Проверяющие не принимают устных объяснений о «временных мерах» или «оперативной необходимости». Формальное требование, зафиксированное вами же, становится эталоном, а его неисполнение — нарушением. Следовательно, внутренние документы должны быть не только корректными с точки зрения регулятора, но и реализуемыми в вашей ежедневной работе.
2. Мониторинг и реагирование на инциденты: наличие против работоспособности
Требование иметь систему мониторинга безопасности и план реагирования на инциденты (ИБ) выполняется формально почти всеми. Однако проверка смотрит на интеграцию этих элементов в живые процессы компании.
- Мониторинг должен быть действенным. Недостаточно просто развернуть SIEM и настроить сбор логов. Проверка может запросить отчёты за последний квартал, где видно, какие инциденты были выявлены автоматически, а не вручную. Попросят показать, как срабатывало правило корреляции, которое породило событие, и какие действия последовали. Если система только хранит данные, но не генерирует инциденты для реагирования, это считается пассивным хранением, а не мониторингом.
- План реагирования должен быть «живым». Абстрактный документ из двадцати страниц, который никто не открывал с момента аттестации, вызовет вопросы. Регулятор проверяет интеграцию плана: назначены ли ответственные, определены ли каналы связи, проводились ли учения. Ключевой вопрос: «Были ли инциденты ИБ за последний год? Покажите, как вы действовали согласно пунктам 3.2 и 5.1 вашего плана».
Отсутствие реальных инцидентов — не оправдание. Это может привести к углублённой проверке: «Покажите, как ваша система мониторинга обнаружила бы попытку несанкционированного доступа, и какие шаги были бы предприняты». Если доказать работоспособность цикла «обнаружение-реагирование» не получается, формальное наличие систем не засчитывается.
3. Категорирование и реальное применение СЗИ
Эта область — источник самых сложных и предметных разговоров с проверяющими. Процесс самостоятельного категорирования информационных систем по уровню значимости часто содержит субъективные оценки, направленные на занижение уровня и упрощение требований. Проверка анализирует логику, заложенную в акт категорирования, на соответствие методическим рекомендациям ФСТЭК.
После подтверждения уровня значимости внимание переключается на средства защиты информации (СЗИ). Фокус здесь двоякий:
- Соответствие не списку, а архитектуре. СЗИ должны быть адаптированы под конкретную среду. Например, применение «коробочного» межсетевого экрана для защиты виртуальной инфраструктуры в частном облаке требует специфической конфигурации и интеграции с платформой виртуализации. Если СЗИ из перечня работает в режиме «пропускаю всё», это формальное соответствие при фактическом несоответствии.
- Проверка эффективности, а не наличия. Регулятор может запросить не только сертификат или лицензию на СЗИ, но и доказательства его работоспособности: акты проверки правил фильтрации МЭ, отчёты о проведении обновлений сигнатур СОВ, результаты тестов на обнаружение атак. Важен актуальный статус и корректность настройки.
Именно здесь чаще всего находят критическое расхождение: система имеет высокий уровень значимости, а средства защиты либо не развёрнуты в полном объёме, либо работают в демонстрационном или неэффективном режиме.
Подготовка: от формального соответствия к операционной устойчивости
Подготовка к проверке — не маскировка проблем, а их системное устранение. Нужно работать в тех же трёх фокусах, где будет работать проверяющий.
Формирование операционных доказательств
Цель — создать связанную цепочку документов, которая подтверждает, что формальные требования выполняются в ежедневной работе.
- Для процессов: Вести и архивировать журналы согласований в ITSM, протоколы совещаний по изменению конфигураций, подписанные акты о проведении восстановления из резервной копии.
- Для мониторинга: Регулярно (еженедельно/ежемесячно) формировать отчёты SIEM с перечнем сработавших корреляционных правил, принятых по ним решений и статусов инцидентов. Даже если это были ложные срабатывания, это доказательство работы системы.
- Для СЗИ: Иметь акты периодической проверки конфигураций, графики обновлений, результаты тестового внедрения новых правил.
Эти документы — не «бумага для проверки», а артефакты работающих процессов. Их наличие смещает диалог с проверяющим с вопроса «есть ли у вас это?» на предметное обсуждение «как это работает?».
Аудит и актуализация внутренних документов
Политика безопасности и регламенты должны проходить регулярный пересмотр (хотя бы раз в год) с двумя целями:
- Привести в соответствие с изменениями в законодательстве (152-ФЗ, приказы ФСТЭК).
- Привести в соответствие с реальными возможностями и практиками организации.
Требование, которое невозможно выполнить в текущих условиях (например, «ежедневный полный аудит логов всех систем» при отсутствии автоматизации),, это мина замедленного действия. Его необходимо либо скорректировать до реализуемого («еженедельный выборочный аудит критических систем с полным аудитом по событиям»), либо обеспечить ресурсы для его выполнения. Это предотвращает ситуацию, когда проверка обнаруживает собственный невыполняемый регламент организации.
Что обычно проверяют поверхностно (но расслабляться нельзя)
Некоторые формальные области редко становятся предметом глубокого изучения, если нет явных сигналов проблем. К ним часто относят:
- Наличие и содержание инструкций для рядовых пользователей по ИБ.
- Факт проведения вводного инструктажа и периодического обучения (часто достаточно предоставить график и подписанные ведомости).
- Формальное назначение ответственных лиц приказом.
- Наличие перспективного плана развития системы защиты.
Однако игнорировать их — ошибка. Эти элементы являются фундаментом. Если при углублённой проверке в критической области (например, в применении СЗИ) обнаруживается серьёзное нарушение, проверяющие расширят фокус. Формальные недостатки в «неважных» документах станут дополнительными пунктами в предписании, увеличивая общий объём нарушений. Их корректное оформление создаёт защитный периметр, ограничивая зону углублённого изучения.
Итог: превратить проверку в рутину
Понимание фокусов проверки позволяет сместить усилия с реактивной подготовки «к визиту» на проактивное построение системы. Когда требования 152-ФЗ и ФСТЭК интегрированы в операционные процессы, а не существуют параллельно с ними, проверка становится плановой сверкой. Средства защиты работают как часть инфраструктуры, мониторинг — как часть эксплуатации, а политики — как отражение реальных действий.
Конечная цель — не просто пройти очередную проверку, а создать систему информационной безопасности, которая устойчива. Устойчивость же проверяется не только контролирующими органами, но и реальными угрозами, для противодействия которым, по сути, все эти требования и созданы.