152-ФЗ в 2012: закрываем модель угроз и комплект оргмер до конца отсрочки

В конце прошлого года один из клиентов позвонил с привычным вопросом: «Ну там по персональным данным надо что-то сделать, но мы пока подождём». Мы спросили, чего именно ждём. Оказалось - непонятно. Поправки к 152-ФЗ уже вступили в силу ещё с 1 июля 2011-го. Три отраслевых приказа - ФСТЭК №58 (ещё 2010 год), ФСБ №378 (2014... нет, уже ФСБ работало по своим более ранним руководящим документам) - в той или иной степени обязательны. Ждать нечего: отсрочки, которую операторы де-факто сами себе выдали, больше нет.

За последние два месяца у нас это уже третий клиент с похожей ситуацией: уведомление в Роскомнадзор подано, реестр операторов есть, а реальной документации под ИСПДн - ноль. Решили написать про то, что минимально нужно закрыть.

Что изменилось с поправками

До июля 2011-го формула защиты была проще: классифицировал ИСПДн, выбрал класс (К1-К4), дальше - либо аттестация, либо декларирование. С поправками картина стала другой. Во-первых, исчезла жёсткая привязка к четырём классам - теперь оператор сам определяет «актуальные угрозы» и под них выстраивает защиту. Во-вторых, ответственность за выбор мер прямо лежит на операторе. В-третьих, ФСТЭК и ФСБ в 2010-2012 году активно дорабатывают методики - приходится следить.

Это, с одной стороны, больше свободы. С другой - если что-то пойдёт не так на проверке, «я думал, что класс К3 и этого хватит» уже не работает как аргумент.

Что конкретно требует документации

Разбирая ситуацию у клиентов, мы каждый раз прохожим по одному и тому же списку пробелов. Вот что нужно закрыть минимально.

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

Второе - модель угроз. По новой логике 152-ФЗ это ключевой документ: именно из неё выводится, какие меры защиты актуальны. ФСТЭК выпустил базовую модель угроз ещё в 2008-м, методика частной модели - отдельный приказ. На практике модель угроз для небольшой 1С с сотрудниками - это 15-20 страниц, которые можно сделать за несколько дней при наличии нормального шаблона. Без неё на проверке сразу вопросы.

Третье - классификация ИСПДн. Акт классификации с подписями - отдельный документ. После поправок классификация стала чуть менее формальной, но акт всё равно нужен как точка отсчёта для выбора мер.

Четвёртое - организационные меры. Это: политика обработки ПДн (публичная, вешается на сайт), внутреннее положение об обработке, инструкции для ответственных лиц, журнал учёта носителей, приказ о назначении ответственного за организацию обработки ПДн. Бумажная работа, но именно её Роскомнадзор запрашивает в первую очередь.

Пятое - согласия субъектов. Форма согласия на обработку ПДн должна содержать конкретный перечень данных, цели, перечень действий, срок. Шаблоны из 2009 года уже не соответствуют актуальным требованиям - их надо переписывать.

Шестое - договоры с обработчиками. Если ПДн передаются в стороннюю бухгалтерию, кадровый аутсорс, облачную CRM - нужен договор поручения обработки с явным перечнем мер защиты, которые берёт на себя обработчик.

Про технические меры - отдельно

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

Как мы работаем с этим сейчас

Три клиента в очереди. С одним уже закрыли модель угроз и классификацию, готовим оргдокументы. Со вторым только начали инвентаризацию - выяснилось, что ИСПДн не одна, а три: 1С, CRM на внешнем хостинге и самописная система учёта клиентов из 2006 года, о которой IT почти забыло. С третьим разбираемся с согласиями: старая форма на сайте не содержит ни цели, ни перечня действий - это надо переделывать с юристом.

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