152-ФЗ и Приказ ФСТЭК №21 в 2017: аудит ИСПДн показал расхождения с обновлёнными методичками

Февраль у нас неожиданно получился регуляторным. На прошлой неделе обсуждали законопроект 187-ФЗ по КИИ, а параллельно закрыли два аудита ИСПДн по 152-ФЗ у разных клиентов. Вот где реально интересно: несмотря на то что оба клиента формально «уже делали» аудит год-полтора назад, по обновлённым методическим рекомендациям ФСТЭК картина у обоих оказалась другой.

Что изменилось в методичках

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

На практике мы видим одну и ту же картину: предыдущий аудитор (внешний или внутренний) проходил по таблице мер из Приложения к Приказу №21 галочками и закрывал документ. Методические рекомендации по базовым, компенсирующим и адаптированным мерам при этом не брались в расчёт. Результат - формально «пройдено», по факту несколько мер либо реализованы не полностью, либо не реализованы вообще.

Что нашли на аудитах

У обоих клиентов ИСПДн с УЗ-3 - самый распространённый уровень для HR-систем и систем кадрового учёта с персданными сотрудников. Расхождения попадались примерно в одних и тех же местах:

• Идентификация и аутентификация (ИАФ). Мера ИАФ.3 - управление идентификаторами - у одного клиента была формально «выполнена» через политику в AD, но без регламента блокировки неиспользуемых учёток. В методичках явно написано, что нужен документально подтверждённый процесс, а не просто настройка GPO.
• Управление доступом (УПД). УПД.5 - разделение полномочий - в обоих случаях не было разграничения между администраторами системы и администраторами безопасности. Один человек делал всё. По Приказу №21 для УЗ-3 это допустимо в определённых условиях, но условия были не задокументированы.
• Регистрация событий (РСБ). РСБ.1 - определение событий для регистрации - у второго клиента лог вёлся, но перечень регистрируемых событий нигде не был зафиксирован как документ. Опять тот же паттерн: настройка есть, бумаги нет.
• Защита машинных носителей (ЗНИ). ЗНИ.8 - уничтожение носителей - отдельная тема. Оба клиента не могли показать ни акта уничтожения носителей, ни регламента. Диски при выводе из эксплуатации просто... выбрасывались.

Чеклист по уровням защищённости

Ниже - то, что мы используем как первичный чеклист при аудите. Это не полная таблица мер из Приказа №21, а именно те точки, где чаще всего расхождения:

УЗ-4 (минимальный, специальные категории не обрабатываются, меньше 100 000 субъектов):

• ИАФ.1 - идентификация/аутентификация пользователей: логин+пароль, политика сложности задокументирована
• УПД.1 - управление учётными записями: есть регламент заведения и блокировки
• РСБ.1 - события для регистрации: перечень зафиксирован в документе
• ОЦЛ.1 - контроль целостности: хотя бы антивирус с актуальными базами

УЗ-3 (большинство корпоративных ИСПДн с данными сотрудников):

• Всё из УЗ-4, плюс:
• ИАФ.3 - управление идентификаторами: регламент блокировки неиспользуемых учёток, не просто политика в AD
• УПД.5 - разделение полномочий: либо реальное разграничение, либо обоснование почему нет и компенсирующие меры
• ЗНИ.8 - уничтожение носителей: акты уничтожения, регламент
• РСБ.2 - содержание записей о событиях: время, субъект, объект, тип операции, результат
• АНЗ.1 - выявление уязвимостей: хотя бы раз в год сканирование, фиксация результатов

УЗ-2 (специальные категории, от 100 000 субъектов):

• Всё из УЗ-3, плюс:
• ЗИС.3 - обеспечение подлинности сетевых соединений: сертифицированные СКЗИ если данные идут по открытым каналам
• УПД.13 - реагирование на НСД: задокументированный план реагирования, не просто «звони сисадмину»
• ЗТС.3 - управление конфигурациями: базовые конфигурации зафиксированы, отклонения фиксируются

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

Где документы важнее технологий

Самый распространённый разрыв, который мы видим у клиентов, прошедших самостоятельный аудит: техническая мера есть, документального подтверждения нет. Настройка GPO есть - политики в виде утверждённого документа нет. Антивирус стоит - регламент обновления баз и ответственный в документе не зафиксированы.

ФСТЭК при проверке смотрит в первую очередь на документы. Не потому что там любят бюрократию, а потому что документ - единственное доказательство того, что мера действительно реализована системно, а не «да у нас так всегда было». Это логика любой проверки.

Что дальше по этим двум клиентам

По первому клиенту - закрываем расхождения в документации, ЗНИ.8 требует отдельного регламента и первичных актов. Несколько недель работы.

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

Вывод прикладной: если аудит ИСПДн делался до 2016 года, стоит его перепроверить. Не потому что закон изменился, а потому что методические рекомендации уточнились, и то что раньше читалось как «галочка выставлена» - теперь может читаться иначе.