152-ФЗ и ФСТЭК: два месяца на модель угроз и переписку с Роскомнадзором

С начала года Роскомнадзор заметно активизировал плановые и внеплановые проверки операторов персональных данных. Среди клиентов, которые «знали, что надо», но откладывали на потом, началось движение. К нам обратилась производственная компания: уведомление в РКН подали, реестр операторов есть, но документального пакета, который требует регулятор для подтверждения мер защиты, нет вообще. Мы взялись помочь.

Итог - два месяца переписки и согласований. Вот что за этим стояло.

Что нужно было собрать

Формально пакет для РКН - это не один документ. Регулятор ожидает увидеть несколько взаимосвязанных бумаг:

• Акт классификации ИСПДн - определяет класс каждой информационной системы, обрабатывающей персданные, по методическим документам ФСТЭК и ФСБ.
• Модель угроз - перечень актуальных угроз безопасности ПД применительно к конкретной инфраструктуре.
• Политика обработки персональных данных - публичный документ, который оператор обязан публиковать и предоставлять по запросу.
• Плюс внутренние регламенты, приказы о назначении ответственных, журналы - но это уже оперативная часть.

На бумаге выглядит структурированно. На практике начинаются вопросы.

Где споткнулись на классификации

Клиент - производство, около ста двадцати человек, несколько юридических лиц в структуре. ИСПДн как минимум три: 1С:Зарплата, кадровая база, CRM с данными контрагентов. Первый вопрос - что является одной системой, а что разными. Юридические лица разные, но сервер один. Классифицировать как одну ИСПДн или как несколько? Методические документы ФСТЭК дают критерии, но их интерпретация неоднозначна именно для холдинговых структур.

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

Класс по зарплатной базе вышел К2: иные персональные данные (СНИЛС, паспорт, банковские реквизиты) плюс более пятидесяти субъектов. CRM попала в К3 - там только ФИО и телефоны контрагентов, биометрии нет, масштаб меньше.

Модель угроз: методика есть, ясности меньше

Вот здесь начался основной затык. ФСТЭК в конце прошлого года анонсировал обновление методики по разработке модели угроз, но документ на момент нашей работы был в статусе «уточняется». Базовая методика 2008 года есть, УБИ (базовые модели угроз) есть - но как именно их применять к конкретному производству с не очень стандартной топологией, всякий трактует по-своему.

Мы взяли базовую модель угроз ФСТЭК как основу и наложили на реальную инфраструктуру клиента. Угрозы, которые в документе ФСТЭК помечены как «актуальные для К2», включили автоматически. Дальше - оценка вероятности реализации с учётом конкретных условий: есть ли внешний периметр, как организован доступ к серверам, есть ли удалённые пользователи.

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

Документ по итогу вышел на тридцать страниц. Два раза переписывали формулировки - первый раз после того, как сами перечитали и поняли, что кое-где рассуждение звучит расплывчато, второй - по комментариям клиентского юриста, который хотел убрать несколько пунктов «чтобы не создавать лишних обязательств». Юриста убедили не трогать: документ должен отражать реальность, иначе при проверке он работает против вас.

Переписка с РКН

Подали пакет. Через три недели вернулся запрос: регулятор попросил уточнить, каким образом обеспечивается уничтожение персданных при расторжении договора с контрагентом - в политике обработки это было прописано общо. Дописали конкретный срок и механизм - автоматическая архивация через шесть месяцев, ручное удаление после подтверждения. Ещё одна итерация.

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

Что в итоге

Два месяца - это не потому что мы медленно работали. Первый месяц ушёл на разработку и внутренние согласования со стороны клиента. Второй - на переписку с РКН и финальную правку. Если бы политика обработки с самого начала содержала конкретные сроки и механизмы, один цикл переписки удалось бы сэкономить.

Мы продолжаем вести этот проект в рамках аудита информационной безопасности. Следующий этап - контрольная проверка технических мер: журналирование на сервере с 1С, разграничение доступа к кадровой базе, политики паролей. Документы приняты, но документы - это только верхушка. Что под ними - отдельный разговор.