понедельник, 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 на мобильный телефон сотрудника



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

СОИБ. Проектирование. Недостающий элемент С-терра


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

В рамках одного из проектов проектировалось решение для крупного заказчика. Требовалось создать систему защищенного взаимодействия между большим количеством крупных удаленных офисов Заказчика.  Требования по пропускной способности составляли порядка 20-30 Мбит, требования к форм-фактору – desktop, потому что не во всех офисах были стойки, криптография в соответствии с законодательством – по ГОСТ.

Так как у Заказчика в основном использовалось активное сетевое оборудование и сетевые средства защиты производства Cisco Systems, оптимальным вариантом были криптошлюзы С-терра СиЭсПи.

Но в линейке криптошлюзов С-терра был большой разрыв в интересующей нас области:  самый простой шлюз С-терра CSP VPN Gate 100 – имеет производительность VPN до 10 Мбит/c. Следующий по криптошлюз Gate 1000 – имеет производительность уже до 200 Мбит/c и стоечное исполнение. Плюс Заказчик хотел получить решение дешевле Gate 1000.

В результате совместной работы инженеров С-терра СиЭсПи и Микротест было разработана новая модель криптошлюза С-терра G-1000-L-5102, которая в ближайшее время должна поступить в продажу.
Фото аппаратной платформы:



Данная модель прошла все испытания и показала производительность VPN порядка 50-100 Мбит/c.

Краткое сравнение нового криштошлюза С-терра CSP VPN Gate G-1000-L-5102 с ближайшими аналогами других производителей приведено в таблице ниже и позволяет ожидать, что новая модель займет достойное  место на рынке.
Основные характеристики
С-терра CSP VPN Gate
G-1000-L-5102
АПКШ  «Континент» IPC-25
Vipnet HW100C
Vipnet HW1000
Stonegate
FW-315-L
(с СКЗИ и серт.)
Производительность VPN по ГОСТ, до мбит/c
50
30
20
280
25
Форм-фактор
desktop
desktop
desktop
1U
desktop
Примерная рекомендованная стоимость, руб.
48 600
60 000
60 600
119 000
60 500

В ближайшее время должны появиться новости на официальных сайтах, тогда добавлю на них ссылку.  За вклад в развитие рынка средств VPN хочется сказать отдельное спасибо инженеру Микротест, Кириллу Луконину.

среда, 21 ноября 2012 г.

СЗПДн. Анализ. Информационное сообщение ФСТЭК по защите ПДн



Сегодня на сайте ФСТЭК Р было опубликовано  информационное сообщение “об особенностях защиты персональных данных при их обработке в информационных системах персональных данных и сертификации средств защиты информации, предназначенных для защиты персональных данных” от 20 ноября  2012 г. № 240/24/4669.


В нем ФСТЭК Р информирует о планируемой дате размещения нового правового акта по защите ПДн (разработанного в соответствии с ПП 1119) – 07 декабря 2012 г.
и приводит основные положения будущего документа:
·        новые требования будут распространяться только на новые СЗПДн;
·        все существующие сертификаты трогать не будут;
·        при выборе средств защиты, при наличие в сертификате ФСТЭК Р упоминаний классов ИСПДн надо руководствоваться таблицей:
СЗИ, сертифицированные  в соответствии с  требованиям 1.0
усл.
об.
усл.
об.
могут применяться для защиты ПДн в соответствии с требованиям 2.0
для защиты ИСПДн до 1 класса
К1
УЗ1
ИСПДн до 1 уровня защищенности включительно
УЗ2
УЗ3
для защиты ИСПДн до 2 класса
К2
УЗ4
ИСПДн 4 уровня защищенности
К3
К4


·        планируется внести изменения в Требования к системам обнаружения вторжений и Требования к средствам антивирусной защиты для привязки их к уровням защищенности ИСПДн в соответствии со следующей таблицей:
классы защиты СЗИ в соответствии с Требованиями из комплекта 1.0
усл.
об.
усл.
об.
могут применяться для защиты ПДн в соответствии с требованиям 2.0
4 класс защиты СОВ и САЗ могут применяться для защиты ИСПДн 1 класса
К1
УЗ1
ИСПДн 1 и 2 уровня защищенности

ИСПДн 3 уровня защищенности (с актуальными угрозами 2-ого  типа или подключенные к Интернет)
УЗ2
УЗ3+
5 класс защиты СОВ и САЗ могут применяться для защиты ИСПДн 2 класса
К2
УЗ3-
ИСПДн 3 уровня защищенности (с неактуальными угрозами 2-ого  типа и не подключенные к Интернет)
6 класс защиты СОВ и САЗ могут применяться для защиты ИСПДн 3 и 4 класса
К3
УЗ4
ИСПДн 4 уровня защищенности
К4

Я думаю из этих таблиц можно примерно понять какая будет преемственность между старыми и новыми требованиями ФСТЭК Р по защите ПДн

В целом видно,
что для защиты ПДн ФСТЭК упоминает только сертифицированные СЗИ и речь идет о сертификатах. На альтернативные способы оценки соответствия рассчитывать не стоит;
что СЗИ раньше использованные для защиты наиболее часто встречаемого класса К2, сейчас тянут только на самый низкий УЗ4  и редко встречаемый УЗ3 для автономных  ИСПДн.


вторник, 13 ноября 2012 г.

СЗПДн. Проектирование. Как централизованно управлять криптошлюзами С-терра?


Есть два замечательных производителя СЗИ: Cisco Systems предлагает комплекс решений для создания защищенной сети без границ, но не имеет Российской криптографии; С-терра СиЭсПи – предлагает широкую линейки средств построения VPN включающих Российскую криптографию, но не производит других средств защиты. В маркетинговых материалах этих двух производителей говорится о тесной  интеграции  друг с другом.  

Так получилось, что в одном проекте по защите ПДе планировалось использование и интеграция решений этих двух производителей.

Один из вопросов, который необходимо было решить при проектировании – определить, как будут управляться сетевые средства защиты информации.

Приоритетным вариантом являлось использование централизованной системы управления. Причин использовать именно его несколько:
·        Визуализации всех сетевых средств защиты на графической консоли
·        Гибкая ролевая модель управления
·        Иерархия и наследование политик (глобальные, общие и локальные политики/объекты)
·        Централизованное управление событиями сетевой безопасности (сбор, просмотр и более быстрое реагирование)
·        Централизованное управление состоянием сетевых средства защиты (общее состояние, загрузка процессора, памяти, интерфейсов и т.п.)
·        Централизованное управление версиями сетевых средств защиты (резервное копирование, обновление)
·        Централизованная отчетность о работе сетевых средств защиты

Для комплекса решений Cisco Systems предлагается система управления Cisco Security Manager. Для управления решений С-терра СиЭсПи одним из основных вариантов предлагается так-же использоваться Cisco Security Manager.  Это подтверждается в маркетинговой информации двух производителей:



·        С-Терра СиЭсПи. Обзор продуктовой линейки 2012

Отлично. Начинаем проектировать и интегрировать криптошлюзы С-терра СиЭсПи с Cisco Security Manager (CSM). При детальном изучении документации и тестировании получаем следующее:

1) Базовые настройки (IP-адресация, импортирование сертификата, настройка NTP) обязательно выполняются вручную, через SSH. Применение на данном этапе CSM невозможно.

2) Построение Site-to-site IPSec VPN в конфигурации Hub-and-Spoke с резервированием шлюза как в нашей ситуации, официально не поддерживается:
“В топологии Hub and Spoke VPN не поддерживается вариант конфигурации с резервированием шлюза”

3) Построение Remote Access VPN, не предоставляется возможным, поскольку:
“Рекомендуется не использовать сценарии, в которых настройка CSP VPN Gate выполняется как через CSM, так и вручную. Если потребность в таком сценарии существует, то надо стараться задавать вручную только те команды, которые CSM не использует в процессе настраивания CSP VPN Gate.
Следует учитывать, что при отгрузке конфигурации, CSM может изменить или удалить некоторые из команд, которые существовали в изначально импортированной конфигурации, например ip local pool или crypto isakmp policy. Для примера, рассмотрим, почему создание политики безопасности шлюза через CSM для работы с мобильными клиентами невозможно. Порядок действий, который приводит к данному ограничению, следующий:
шлюз добавлен в CSM для работы по одной из топологий при помощи CSM проведена централизованная настройка шлюзов по одной из топологий – FullMesh, Hub and Spoke, Point to Point затем, например, по SSH отредактировать конфигурацию одного из шлюзов для работы с мобильными клиентами – создать пул адресов, привязать к криптокарте, создать identity и др. после загрузки на шлюз созданной конфигурации через CSM, работа с мобильными клиентами будет невозможна в созданной топологии.
Причина состоит в том, что все пулы адресов, не привязанные к команде crypto isakmp client configuration address-pool local, CSM удаляет”.

4) Поскольку CSM имеет ряд ограничений по работе с конфигурацией С-терра (затирание части конфига после загрузки), что может поставить под угрозу работу криптошлюзов из-за затирания команд:
“3. Возможны некоторые проблемы с восстановлением конфигурации. В некоторых случаях изменение или удаление существующих команд может быть безвозвратным: даже если в CSM удалить изменения, внесенные в конфигурацию, например, удалить VPN Topology, первоначальная конфигурация (которая была до Deploy) может не восстановиться в полном объеме. Более того, возможны ситуации, когда какие-то элементы конфигурации могут быть испорчены именно при отмене изменений, сделанных в CSM. Например:
в первоначальной конфигурации была настройка crypto isakmp identity dn
в CSM, в VPN Global Setings выставлена настройка Identity – Distinguished Name
в прогружаемой из CSM конфигурации команда crypto isakmp identity отсутствует
если потом удалить VPN Topology и снова прогрузить конфигурацию, то будет прописана команда crypto isakmp identity address (значение по умолчанию), что отличается от того, что было в первоначальной конфигурации.
CSP VPN Gate не поддерживает функциональность Rollback, позволяющую вернуться к конфигурациям, которые были загружены в устройство ранее”

5) Нет возможности копировать и обновлять образы средств защиты             
6) Нет возможности детального мониторинга состояния средств защиты

От производителя получен комментарий, что CSM может использоваться для создания простых политик site-to-site, hub-and-spoke и быстрого разворачивания однотипных конфигураций. То есть делается базовая преднастройка, далее одна политика распространяется на все устройства с помощью CSM, далее идет только конфигурация устройств через SSH а CSM больше не используется.

Данный вариант использования Cisco Security Manager с моей точки зрения не соответствует приведенным в начале статьи целям (для которых он будет использоваться при управлении решениями Cisco Systems) и для управления устройствами С-терра её использовать не стоит.

В определенной степени исправить ситуацию может недавно вышедшая система централизованного управления С-Терра КП. Посмотрим какие функции в сравнении с CSM выполняются:
·        Визуализация - нет
·        Гибкая ролевая модель управления - нет
·        Иерархия и наследование политик  - частично, есть визарды для настройки  политик и шаблоны политик
·        Централизованное управление событиями сетевой безопасности (сбор, просмотр и более быстрое реагирование) - да
·        Централизованное управление состоянием сетевых средства защиты (общее состояние, загрузка процессора, памяти, интерфейсов и т.п.) – частично, только общее состояние
·        Централизованное управление версиями сетевых средств защиты (резервное копирование, обновление) – частично, обновление сертификатов, ключей
·        Централизованная отчетность о работе сетевых средств защиты - нет
Как видим что и тут поставленных целей мы не достигнем.

Коллеги, буду признателен если вы поделитесь, как управляете большим количеством С-терра и удалось ли подружить с CSM?

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