понедельник, 17 декабря 2012 г.

СЗПДн. Анализ. Обработка фотографий и биометрия


14 декабря были опубликованы разъясненияРоскомнадзора по вопросам обработки персональных данных работников и соискателей, подготовленные совместно с экспертами: А.В. Лукацким, Емельянниковым М.Ю., Волковым А.Н., Токаренко А.В.

Появление такого документа радует, потому что подобные вопросы возникают у всех операторов ПДн и теперь могут быть решены гораздо быстрее.  

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

При этом обработку черно-белых ксерокопий паспортов трактовалась краснодарским РКН как обработка биометрических данных, а нарушением являлось отсутствие согласия субъекта на обработку биометрических ПДн.
С моей точки зрения имело место обработка обычных категорий ПДн (не биометрических) но при этом происходит нарушение  152-ФЗ части 5 статьи 5:
“5. Содержание и объем обрабатываемых персональных данных должны соответствовать заявленным целям обработки. Обрабатываемые персональные данные не должны быть избыточными по отношению к заявленным целям их обработки.”

Чтобы хоть как-то прояснить официальную позицию РНК, отправил 2 запроса в РКН (2 месяца назад и месяц назад) с вопросами:
·        относится ли ксерокопия паспорта к биометрическим данным
·        может ли оператор обрабатывать ксерокопии паспортов в рамках трудового договора с субъектом ПДн, без получения дополнительного согласия

Был получен следующий ответ:




Как видно, РКН считает что фото + дополнительные данные = биометрия. Копия паспорта = биометрия.

По этому поводу могу посоветовать операторам:
·      следить за новыми разъяснениями РКН,  возможно там более подробно будет освещен данный вопрос
·      отказаться от обработки копий паспортов, либо заштриховывать фотографии (не потому что биометрия, а потому что избыточные данные)
·      минимизировать технологические процессы обработки фотографий субъектов ПДн,  для всех оставшихся процессов четко определить цели для достижения которых необходимы фотографии субъектов; если эти цели – идентификация субъекта и попадает под  152-ФЗ статью 11, то собирать согласие на обработку биометрических ПДн; быть готовым собрать согласие и для всех остальных случаев обработки фотографий субъектов ПДн.  


UPDATE. Примеры:

ОАО «ТАВС «Кубань»
РКН выдал предписание об устранении нарушений и отправил дело в прокуратуру
http://23.rsoc.ru/news/p45/news42795.htm

Прокуратура возбудила дела об административных правонарушениях по статье 13.11 КоАП РФ и направила его мировому судье судебного участка № 40 Карасунского внутригородского округа г. Краснодара
http://23.rsoc.ru/news/news45215.htm

Мировой судья признал оператора виновным
http://msud40.krd.msudrf.ru/modules.php?name=info_pages&id=1897


ООО «Европа-СПА»
РКН выдал предписание об устранении нарушений и отправил дело в прокуратуру
http://23.rsoc.ru/news/p224/news38850.htm
Мировой судья признал оператора виновным
http://msud52.krd.msudrf.ru/modules.php?name=info_pages&id=1621

Дальше просто предписания (не стал тратить время на подборку одного к другому, и так всё понятно)

ОАО "ЮКА"
http://msud101.krd.msudrf.ru/modules.php?name=info_pages&id=1453&cl=1

ФГБУ санаторий «Юность»
http://msud98.krd.msudrf.ru/modules.php?name=info_pages&id=2340&cl=1

ООО «МФО «Клиника «На здоровье» (хотя на сайте название зачем то удалили)
http://msud245.krd.msudrf.ru/modules.php?name=info_pages&id=1005&cl=1

ЗАО Санаторий «Кубань»
http://msud1.krd.msudrf.ru/modules.php?name=info_pages&id=4519

пятница, 14 декабря 2012 г.

СЗПДн. Анализ. Предложения по совершенствованию состава и содержания организационных и технических мер по ОБ ПДн от ФСТЭК


В соответствии с информационным сообщением ФСТЭК России “о проекте приказа ФСТЭК России «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»” от 07 декабря 2012 г. № 240/22/4947 провел экспертизу проекта приказа ФСТЭК России “Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных”.
                                   
В соответствии с предыдущим комплектом документов регуляторов (ФСТЭК и ФСБ) нам удавалось реализовывать эффективные проекты по защите ПДн.

А именно была возможность учесть базовый набор мер от регуляторов, пожелания заказчика и выбрать только те меры, которые были необходимы для обработки актуальных угроз безопасности ПДн.

Новые документы ФСТЭК анализировал в том направлении, насколько они будут помогать или мешать реализации эффективных проектов СЗПДн у операторов аналогично тому, как это удавалось делать ранее.

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

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

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

В приложение привожу примеры типов СЗИ которые обязательно потребуются для защиты ИСПДн самого простого 4 уровня защищенности (напомню, что к таким ИСПДн относятся и системы обрабатывающие обезличенные и общедоступные ПДн). Приведен один из возможных вариантов реализации мер который получился на самый первый взгляд, естественно возможны и другие варианты.
·        СЗИ от НСД, например сертифицированная ОС Windows (ИАФ.1, ИАФ.3, ИАФ.4, ИАФ.5, ИАФ.6, УПД.1, УПД.2, УПД.6, УПД.11, УПД.1, все РСБ, ЗИС.11)
·        Remote IPSec или SSL VPN (ИАФ.6, УПД.13, УПД.14, УПД.15, все РСБ, ЗИС.7, ЗИС.15, ЗИС.28)
·        Site-to-Site VPN (ЗИС.7, все РСБ, ЗИС.15, ЗИС.28)
·        межсетевой экран (УПД.16, все РСБ, ЗИС.6)
·        средства инвентаризации АРМ или централизованного управления АРМ (ОПС.3, все РСБ, ОЦЛ.7)
·        средство управления работой со съемными носителями (ЗНИ.1, ЗНИ.2, ЗНИ.8, ЗНИ.9, все РСБ)
·        средства анализа защищенности (ОЦЛ.1, ОЦЛ.2)
·        антивирус (ОЦЛ.3, все РСБ,)
·        средства резервного копирования и восстановления (ОЦЛ.8, ЗИС.10)
·        СЗИ от НСД для виртуализации или сертифицированная платформа виртуализации (ЗСВ.2, ЗСВ.7, все РСБ)

Это минимальный набор СЗИ и все они должны быть сертифицированы на 6 класс защиты.


пятница, 7 декабря 2012 г.

СОИБ. Проектирование. Усиленная аутентификация на уровне сети (UPD)


В своем блоге я уже делал несколько заметок по теме усиленной аутентификации (например, эта), и теме защищенного доступа к сети. Сегодня ещё одна заметка в продолжение.

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

Но на пути внедрения усиленной аутентификации могут встать технические ограничения:
·        большинство бизнес-приложений организации может не поддерживать усиленную аутентификацию (об этом я писал в заметке)
·        в организации могут быть программно или аппаратно отключены USB порты на АРМ пользователей, либо они могут быть опечатаны. А большинство средств усиленной аутентификации (токены, смарт-карты, биометрические сканеры) подключаются по USB
·        в организации может использоваться нестандартная служба каталогов (Linux и LDAP или Novell eDirectory) а большинство средств усиленной аутентификации основаны на Microsoft Active Directory
·        рабочие места пользователей могут работать под управлением ОС отличных от семейства Windows. Может оказаться сборная солянка Windows, Linux, MacOS, Android, iOS и т.п.  

В таких случаях нам на помощь приходит аутентификация и контроль доступа на уровне сети, которая не зависит от приложений и почти не зависит от устройств пользователей. Дальше привожу несколько вариантов решений на базе продукта Cisco ISE.

Вариант 1. Аутентификация на уровне сети интегрированная с аутентификацией в eDirectiry (нет усиления аутентификации, но есть дополнительный контроль доступа)



Вариант 2. Аутентификация на уровне сети по сертификатам (при этом сертификат и закрытые ключи могут хранится как на съемном носителе, так и на виртуальном токене, так и в сетевых каталогах)


Вариант 3. Аутентификация на уровне сети по SMS на мобильный телефон сотрудника