Специалист по защите информации
0,0
рейтинг
23 мая 2013 в 10:42

Разработка → Защищаем персональные данные по новому приказу ФСТЭК. Больше ответов или вопросов?

15 мая 2013 года Минюст наконец-то зарегистрировал приказ ФСТЭК № 21 от 18 февраля 2013 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

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

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

В этой статье я постараюсь простым языком проанализировать новый документ ФСТЭК России, взвесить его плюсы и минусы, а также постараться ответить на вопрос «что же теперь делать операторам персональных данных?».



Что из себя представляет документ в целом



В целом, это действительно шаг вперед в плане законотворчества в сфере защиты персональных данных. Наконец-то в списке мер мы увидели упоминание мобильных устройств и средств виртуализации, чего раньше законодатели тщательно старались избегать. Наконец-то нет обязаловки как в прошлом приказе: «Если у тебя ИСПДн 1 класса, тебе нужно потратить n денег на средства защиты информации, если 2 класса, то n-m денег, а если 3 класса, то n-m-k денег.».

Сейчас ситуация такая: у нас есть 15 групп различных технических и организационных мер, в каждой группе от 2 до 20 различных мер, напротив каждой меры отмечено, является ли эта мера базовой (я буду их называть далее условно обязательными) для определенного уровня защищенности (если стоит плюс, то мера базовая, если нет — компенсирующая). Тут нужно заметить, что в перечне есть немало мер, которые могут быть только компенсирующими, то есть не отмечены плюсом ни для одного из четырех уровней защищенности.

Оператор персональных данных действует по следующему алгоритму:
— определяет уровень защищенности своей ИСПДн согласно ПП 1119;
— выбирает все меры, которые отмечены плюсом для выбранного уровня защищенности (базовые меры);
— убирает из полученного списка меры, которые связаны с технологиями, не используемыми в ИСПДн (например, убираем меры для защиты виртуальной инфраструктуры, если средства виртуализации не используются);
— смотрит на полученный список мер и сравнивает с актуальными угрозами в модели угроз, если выбранными мерами нейтрализуются не все актуальные угрозы, добавляет в список компенсирующие меры, необходимые для нейтрализации всех оставшихся угроз;
— добавляет к полученному списку меры, определенные в других нормативных актах (например в ПП № 1119 есть небольшое количестве мер, а также есть общие требования в ФЗ-152), после чего получает итоговый список мер, которые нужно выполнить;
— выполняет меры из окончательного списка…

Вроде бы все просто: определяем уровень защищенности, рисуем модель угроз, выбираем и уточняем меры из нового приказа ФСТЭК, выполняем эти меры и у нас комар носа не подточит. Но…

Ложка дегтя



Собственно здесь начинается критика как нового документа, так и остального законодательства в целом.

Проблемы у 21 приказа ФСТЭК в целом такие же как и у многих других законодательных документов — использование размытых формулировок, возможность двоякого толкования текста, отсутствие пояснений там, где они жизненно необходимы.

Понять как тщательно готовился документ и сколько раз его перечитывали и редактировали за эти полгода можно уже по тому факту, что после четвертого пункта в приказе сразу идет шестой… Ну ладно, это придирки, а что есть по существу?

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

Едем дальше. Пункт 3 говорит нам о том, что меры по обеспечению безопасности ПДн должны быть направлены на нейтрализацию актуальных угроз безопасности. С другой стороны ФЗ-152 говорит нам о том, что организационные и технические меры применяются для выполнения требований по защите ПДн. Так все-таки, есть у нас свобода или очередная обязаловка? Опять необходимо разъяснение.

Далее. Шестой пункт гласит о том, что раз в 3 года оператор самостоятельно или с привлечением сторонних организаций должен проводить оценку эффективности реализованных мер защиты ПДн. Тут получилось как с оценкой вреда субъекту персональных данных в 152-ФЗ. Получается, что оценку провести нужно, а какой-либо методики проведения такой оценки нет. А может быть оценка эффективности является заменой аттестации информационной системы? Тогда почему оператор может проводить ее самостоятельно, не имея лицензии на ТЗКИ?

Десятый пункт документа на первый взгляд очень многообещающий, в нем сказано "При невозможности технической реализации отдельных выбранных мер по обеспечению безопасности персональных данных, а также с учетом экономической целесообразности на этапах адаптации базового набора мер и (или) уточнения адаптированного базового набора мер могут разрабатываться иные (компенсирующие) меры, направленные на нейтрализацию актуальных угроз безопасности персональных данных".

Казалось бы, вот оно — ссылаемся на экономическую нецелесообразность и не покупаем никаких сертифицированных средств защиты. Ну тут же нас выводит из состояния эйфории следующий абзац: «В этом случае в ходе разработки системы защиты персональных данных должно быть проведено обоснование применения компенсирующих мер для обеспечения безопасности персональных данных».

То есть вот как, просто сказать проверяющему «Мы тут с мужиками прикинули и решили, что внедрять сертифицированные СЗИ это слишком дорого и поставили бесплатный китайский антивирус» не получится. Нужно показывать какие-то бумажки, обосновывающие применение иных мер, а не базовых. Как обосновать? Мне пока на ум приходит только проведение процедуры анализа рисков по ISO 27001, что, в случае найма для этих целей сторонней организации, само по себе может влететь в копеечку. К тому же, еще не факт, что анализ рисков покажет, что внедрять сертифицированные СЗИ экономически нецелесообразно…

Собственно тут мы и дошли до основной части документа — приложение с перечнем мер. Тут тоже не все так просто как хотелось бы. Вроде бы и меры разбиты на группы и удобно пронумерованы, вроде бы и удобные столбики с плюсиками показывают является ли в нашем случае та или иная мера условно обязательной или нет. Но, все равно, после изучения таблицы с мерами остается чувство неопределенности. Вот, например, пункт четвертый основного текста приказа уже не обязывает, вроде как, применять только сертифицированные СЗИ. Это хорошо. Но этот же пункт и не говорит прямым текстом, что можно применять несертифицированные СЗИ или не применять СЗИ вообще. Вот как он звучит дословно:
Меры по обеспечению безопасности персональных данных реализуются в том числе посредством применения в информационной системе средств защиты информации, прошедших в установленном порядке процедуру оценки соответствия, в случаях, когда применение таких средств необходимо для нейтрализации актуальных угроз безопасности персональных данных.

В то же время, первая же мера, условно обязательная для всех уровней защищенности, звучит так: «Идентификация и аутентификация пользователей, являющихся работниками оператора». Понятно, что эта мера может быть реализована и штатными средствами любой ОС. И вроде как четвертый пункт не обязывает применять тот же Secret Net или Dallas Lock, но где гарантия, что не придет проверяющий и не скажет «Вы все не так поняли, тут должно стоять сертифицированное СЗИ, вот вам предписание»? Кто и как определяет — для нейтрализации конкретной угрозы необходимо ли сертифицированное СЗИ или можно обойтись без него? Почему нельзя написать прямым текстом, что применение сертифицированных СЗИ не обязательно, или обязательно в каких-то конкретных случаях?

Ну и формулировка самих мер иногда очень интересна. Вот например условно-обязательная мера защиты сред виртуализации для уровней защищенности от третьего и выше:
«Разбиение виртуальной инфраструктуры на сегменты для обработки персональных данных отдельным пользователем и/или группой пользователей».

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

Я очень надеюсь, что когда-нибудь представители ФСТЭК все же дадут официальные разъяснения по поводу спорных вопросов.

Вместо резюме



В общем и целом заметны попытки ФСТЭК дать большую свободу действия операторам при выборе стратегии защиты персональных данных, но размытости и неопределенности в формулировках в сочетании с неясностью позиции самого регулятора в спорных моментах, заставляют насторожиться.

Что же делать операторам сейчас?

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

Остальным — классифицировать свои ИСПДн, построить модель угроз, составить список мер и, по мере возможности, их выполнять. Мониторить всевозможные новости, касающиеся разъяснений регуляторов, практики проведения проверок, мнений экспертов и общей тенденции развития законодательства в этой сфере.
Андрей Березов @Loreweil
карма
40,5
рейтинг 0,0
Специалист по защите информации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (16)

  • +1
    Безотносительно содержания, но за качество документа хочется отбить им руки.
  • +4
    Скажите мне, пожалуйста, как эксперты, которым не лень разбираться в дебрях российских законов – а не проще ли (для обычной коммерческой фирмы, чья деятельность не подлежит строгому регулированию) сделать две вещи: 1) получить от клиента в России согласие на трансграничную передачу его персональных данных 2) вынести всю содержательную деятельность, в которой участвуют эти данные, в юридическое лицо за пределами РФ? И забыть навсегда про всю эту юридическую казуистику и нарастающие объемы меняющихся каждые полгода постановлений?
    • +1
      кто бы попробовал да отписался)
    • +1
      Ну, а вы сами попробуйте. Пример: вы банк/страховая решили, что все ваши клиенты будут хранить ПД в ЦОДе в другом государстве. Мало того, что вам необходимо будет взять соглашение со всех нынешних ваших клиентов (личная подпись сотрудника, который страхуется по ДМС), но и в будущем при проведении тендера вы будете, как «белая ворона», которая передает данные заграницу. И еще это вас не избавит от защиты по ФЗ 152 рабочих станций, на которых и происходит обработка ПД.
    • 0
      Не так-то просто собрать согласия, сейчас люди с настороженностью относятся к подписанию подобных бумажек. Еще сложнее, если фирма не новая, а с уже наработанной базой клиентов, как вы старым клиентом объясните, что внезапно понадобилось передавать их ПДн за границу?
      • 0
        Согласен на счет ситуации, когда фирма уже не новая. Но если создается новая компания — то по целому ряду причин, не только ФЗ-152, целесообразно сразу выносить core-бизнес юридически (и по возможности физически) за пределы РФ. Я говорю об ИТ-компаниях, не о банках и не о супермаркетах.
  • +1
    … что после четвертого пункта в приказе сразу идет шестой…
    А потом придут проверяющие и скажут — вы не выполнили 5-й пункт! Аяя-яй вам за это!!!
  • 0
    Как говорится, что законом не запрещено, то разрешено.
    4 пункт по идее дает определенную свободу действия по выбору средств защиты. Оператор (я) не считаем, что наши угрозы требуют закупки сертифицированного фаервола випнет, нас устраивает и gnu netfilter. Если будет предписание, то его можно теперь попробовать оспорить через суд.

    И скорее всего такие ситуации будут возникать. Не исключаю сценарий, что регулятору, как человеку простому, обязательно нужна будет внушительная бумага с печатями и подписями авторитетных организаций, что да netfilter это реальный сетевой экран не хуже этих ваших сертифицированных випнетов. На слово то может и не поверить.
    • 0
      Скорее всего регулятор попросит отчет о проведении оценки эффективности выбранных мер защиты. Правда опять же не понятно как эту оценку проводить, методик никаких нет. Да и с аттестацией это не вяжется. Аттестация — проверка соответствия требованиям. Требования выполнили — получи аттестат, а оценка эффективности по идее должна проводиться по прошествии определенного периода времени. Опять же, сиди вот и думай что там ФСТЭК имел ввиду…
  • 0
    Про пункт 1 было разъяснение ФСТЭК. Только оно еще больше все запутало.
    Потому и мнения делятся. (Что-то у меня цитаты не выделяются:), весь текст ниже — это мнения не мои)

    2. Для собственных нужд получение лицензии не требуется, она нужна в случае, если ваша организация оказывает услуки по ТЗКИ или получает с этого доход. По этому поводу ФСТЭК специально выпускал инф. сообщение №240/22/2222 от 30 мая 2012г, в которм разъяснял свою точку зрения на этот счет
    все, что относится к шифрованию — находится в ведении ФСБ…
    так вот… как ни удивительно, но установка клиент-банка с использованием любого российского криптопровайдера — это УЖЕ установка шифросредств!!..
    Исходя из этого лицензии должны были бы иметь ВСЕ организации страны…

    Именно исходя из этого ФСБ не раз заявляло, что лицензированию подлежит исключительно оказание услуг…
    скажем, если вы формируете ЭЦП для себя — то фиг бы с ним… если хоть одна ЭЦП выйдет наружу для организации документооборота — все, это подлежит лицензированию…
    в ПП о лицензировании СКЗИ — есть фраза про «для себя» в названии (и больше нигде нет), а в ПП по ТЗКИ — такой оговорки нет, и формально устанавливать и НСД (тот же секретнет) и антивирус (если Вы его используете с ЦЕЛЬЮ выполнить государственные требования) и МЭ — вы без лицензии не имеете право.
    Что такое «для себя» — тут в толкованиях раздрай и шатание.
    Мое видение (упрощенно):
    1. если организация является органом криптозащиты (т.е. сама генерит ключики)
    И
    2. использует эти ключики для защиты информации, которая не подлежит ОБЯЗАТЕЛЬНОЙ защите по законодательству
    И
    3. не передает ключики сторонним организациям и физическим лицам не работникам (а работникам, только для достижения бизнес целей соответствующих 2 пункту)
    Это
    «для себя»

    Нарушение 2 или 3 пункта и обязательное наличие 1 пункта при этом — это лицензия.

    99% организаций не требуется лицензия в силу не выполнения 1-го пункта. Всякие отчетности, госзакупки и т.п. — все делается лицензиатами (УЦ), которые ОБЯЗАНЫ по нормативке ставить, контролировать, разбираться в нарушениях. Дело безопасника проверить договор с таким УЦ на наличие обязанности установок и ведения документации (внесения записей в документацию заказчика).
  • 0
    я вам больше скажу — ФСТЭК избранным лицензиатам рассылал проект приказа до публикации, готовились замечания, но не все легли в документ. Я в целом динамику развития деятельности ФСТЭК одобряю, привлечение экспертного сообщества сделало документ лучше, несмотря на все оставшиеся косяки. А пункт 5 срезал Минюст, т.е. косяк с нумерацией скорее на их стороне. На практике ФСТЭК, как мне кажется, будет рекомендовать использовать серт. средства, а мы будем отбиваться отсутствием пункта и моделью угроз. Жизнь покажет.
  • 0
    А подскажите, а как обеспечить требования закона для сервера Ubuntu+Apache+Django+MySQL+самописное ПО на Django, на котором лежат ФИО и телефоны учеников частной школы (общедоступные идентифицирующие данные)?
    А то читаю-читаю законы и мнения и даже мысли нет, что нужно сделать и с чего начать. С этими типами угрозы — непонятки. Возможные дыры в системном ПО — это первый тип? или третий?
    И даже если обеспечивать 4-й, самый низкий, уровень защищенности — какие сертифицированные СЗИ использовать и надо ли? встроенные firewall на IPtables — удовлетворяет?
    одни вопросы…
    • 0
      Сейчас написано, что сертифицированные СЗИ должны применяться, только тогда, когда их применение необходимо для нейтрализации угроз. В новом приказе фстэка базовые и компенсирующие меры сформулированы так, что большинство из них реализуемо без сертифицированных СЗИ. Что касается типа угроз, то дыры в ПО есть всегда и везде, но сам факт наличия дыр еще не является угрозой 1 или 2 типа, угрозой является возможность их использования. Вы можете в модели угроз написать, что у вас стоят последние патчи, стойкие к общедоступным эксплойтам, а 0day уязвимости слишком дороги на черном рынке и ради вашей информации навряд ли кто-то будет покупать 0day эксплойты. Опять же, чтобы показать что ваши информация не шибко желанная для квалифицированного злоумышленника было бы неплохо провести анализ рисков по ISO 27001. Также можно провести пентесты, чтобы показать, что угрозы 1 и 2 типа неактуальны.
      • 0
        То есть, возможно, ничего дополнительного не придется ставить? Интересно…
        Подскажите ссылками как оформлять эту модель угроз и как провести анализ рисков по ISO 27001?

        Завел еще вопрос habrahabr.ru/qa/41492/ — там говорят, что нужно высылать уведомление в Роскомнадзор и для https нужно гостированное шифрование — как прокомментируете?

        спасибо за участие :)
        • +1
          Вот я про это и писал в статье, что если читать документ то создается такое впечатление, что в большнистве случаев можно обойтись без сертифицированных СЗИ, но прямым текстом это не написано. Написано что сертифицированные СЗИ нужны только когда они НЕОБХОДИМЫ. Кто и как должен определять эту необходимость — черт его знает =) А в перечне мер написано например «Идентификация и аутентификация пользователей». Эту меру можно реализовать как каким-нибудь секрет нетом, так и штатными функциями любой ОС и так далее в таком духе.
          Про оформление модели угроз и анализу рисков тут в нескольких постах не распишешь, некоторые этим вопросам посвящают курсы, которые стоят немалых денег =) Если кратко то по моделированию угроз основной документ фстэка здесь. Оформлять МУ можно по-разному, разные образцы есть в сети. Тоже самое можно сказать по анализу рисков, читаем ГОСТ, проводим мероприятия, документируем в свободной форме.
          Уведомление в РКН обязательно нужно послать, как подготовиться к проверке РКН, я писал в другой статье: habrahabr.ru/post/169527/
          Насчет шифрования, то это уже стезя ФСБ, нужно смотреть их документы и требования. Насколько я знаю, от ФСБ тоже ожидается в ближайшем времени новый документ по защите ПДн.
          • 0
            Огромное спасибо, буду изучать :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.