Приказ ФСТЭК №21 на практике: три аудита и самые частые замечания по техническим мерам защиты ПДн
Обобщаем опыт трёх аудитов по Приказу ФСТЭК №21: самые частые несоответствия - сегментация, аутентификация, уровень защищённости. Публикуем матрицу мер по УЗ.
ФСТЭК уточняет применение Приказа №21 о технических мерах защиты ПДн - практика проверок 2016 года
К нам в последние месяцы довольно часто приходят с запросом «хотим понять, правильно ли у нас реализованы технические меры по Приказу №21». После нескольких аудитов с таким фокусом появилась возможность сравнить результаты - и картина оказалась предсказуемо похожей у разных организаций.
Приказ ФСТЭК России №21 от 2013 года - документ, который определяет состав технических и организационных мер защиты для информационных систем персональных данных. По сути, это перечень мер, обязательных или адаптируемых в зависимости от уровня защищённости (УЗ) конкретной ИСПДн. Четыре уровня - УЗ-1 самый жёсткий, УЗ-4 самый мягкий. Чем выше уровень, тем длиннее список обязательных мер.
По итогам трёх аудитов соответствия разных по размеру организаций - государственного учреждения, регионального банка и медицинской организации - есть что обобщить. Ни одна из них не проходила формальную аттестацию недавно, все имели документацию разной степени актуальности и считали, что «в целом всё нормально».
Три самых частых замечания
Первое - отсутствие или формальность сегментации сети ИСПДн. Это, пожалуй, самое распространённое несоответствие. Приказ №21 для УЗ-1 и УЗ-2 требует применения мер по разграничению доступа к сетевым ресурсам, в том числе выделения ИСПДн в отдельный сегмент с контролем трафика. На практике у двух из трёх клиентов ИСПДн находилась в той же сети, что и рабочие станции общего назначения, принтеры и прочий зоопарк. Межсетевое экранирование было - на периметре. Внутренней сегментации не было вовсе.
Показательный случай: у одного клиента в документах было написано «ИСПДн изолирована в отдельном сегменте», а по факту сегментация существовала только на уровне VLAN без каких-либо ACL между ними. Трафик между VLAN ходил свободно. Это не сегментация в смысле Приказа №21 - это маркировка без ограничений.
Второе - слабая аутентификация на доступе к ИСПДн. Мера «Идентификация и аутентификация пользователей» присутствует во всех уровнях УЗ, но наполнение разное. Для УЗ-2 и выше требования включают усиленную аутентификацию или двухфакторную для привилегированных пользователей. Везде видели одно: парольная политика задана в общей GPO, пароли «не менее 8 символов», двухфакторки нет ни у кого - ни у администраторов, ни у операторов ИСПДн. Причём в одном случае у администратора БД с доступом ко всей базе ПДн пароль был установлен «никогда не истекает» - «чтобы не беспокоили».
Для медицинской организации с УЗ-2 (специальные категории данных - здоровье) это прямое несоответствие базовому набору мер.
Третье - несоответствие фактического уровня защиты задокументированному классу. Это системная проблема. Организации когда-то определили УЗ - нередко в 2013-2014 году, по старой классификации или с ошибками в методологии. С тех пор ИСПДн развивались, состав обрабатываемых данных менялся, появлялись новые категории субъектов. Уровень защищённости никто не пересматривал. В одном случае организация работала с данными о состоянии здоровья сотрудников в кадровой системе, что автоматически поднимает требования, но в документах это не было отражено, и меры соответствовали УЗ-3, а не УЗ-2.
Матрица мер по уровням УЗ - что проверяем
Приводим компактную версию того, что проверяем при аудите в первую очередь по каждому уровню. Не полный перечень мер из Приказа №21, а то, где наиболее часто находим несоответствия:
| Мера | УЗ-4 | УЗ-3 | УЗ-2 | УЗ-1 |
|---|---|---|---|---|
| Идентификация и аутентификация пользователей | базовая парольная политика | + блокировка после N попыток | + усиленная аутентификация привилегированных | + двухфакторная для всех операторов |
| Управление доступом | ролевое разграничение | + запрет совмещения критичных ролей | + мандатный контроль доступа | + контроль информационных потоков |
| Сегментация (сетевое разграничение) | не требуется | не требуется | выделенный сегмент с МЭ | выделенный сегмент + контроль трафика |
| Регистрация событий безопасности | локальное журналирование | + централизованный сбор | + защита журналов от изменения | + мониторинг в реальном времени |
| Антивирусная защита | сертифицированный АВ | + управляемое обновление | + поведенческий анализ | + защита серверов и рабочих станций |
| Обновления безопасности | по регламенту | + приоритизация критичных | + управляемое распределение | + контроль уязвимостей |
| Резервное копирование | есть, без требований к хранению | + раздельное хранение | + тестирование восстановления | + проверка целостности резервных копий |
УЗ-1 и УЗ-2 требуют применения сертифицированных ФСТЭК средств защиты информации по ряду мер. Это отдельный пласт: нужно не просто использовать подходящий продукт, но убедиться, что сертификат действует и продукт присутствует в актуальном реестре. Мы уже встречали истёкшие сертификаты - об этом писали раньше в посте про аудит операторов.
Почему так выходит
Логика понятна. Когда Приказ №21 вышел в 2013 году, организации создали документы и в той или иной мере реализовали меры. Потом жизнь пошла своим чередом: инфраструктура менялась, ответственные менялись, документы не обновлялись. «Мы аттестовались три года назад» - это не значит, что сейчас соответствие сохранилось.
Ещё один фактор - интерпретация мер. Приказ №21 написан на уровне принципов, а не технических спецификаций: «разграничение доступа», «регистрация событий безопасности». Что именно считается достаточной реализацией - это пространство для интерпретации, и при проверке ФСТЭК трактует его по-своему. Мы видим, что в 2016 году проверяющие стали детальнее смотреть именно на техническую реализацию, а не только на наличие документов.
Что делаем с этим
После каждого такого аудита результат - не просто список несоответствий, а приоритизированный план: что критично и требует устранения до любой проверки, что можно закрыть в рабочем порядке за несколько недель, что требует более длительной работы или архитектурных изменений.
Сегментацию в двух организациях мы уже начали прорабатывать - это недели работы, не дни, потому что перестройка сетевой архитектуры затрагивает всё, что к этой сети подключено. Аутентификацию для привилегированных пользователей закрыть проще - это конфигурация и, возможно, внедрение одного инструмента.
Вопрос актуальности документации оказывается самым быстрым в исправлении и самым болезненным в признании: когда в документах написано одно, а по факту другое - это несоответствие не техническое, а организационное, и устраняется оно регулярным ревью, а не разовым проектом.