четверг, 11 августа 2011 г.

СЗПДн. Анализ. Новое в 152-ФЗ 2.0

На просторах сети Интернет коллеги активно проводят анализ определенных статей ФЗ-152 2.0.

У меня так-же стояла задача провести постатейный анализ изменений в ФЗ-152, поэтому интересно было выбрать публикации, в которых указывалось конкретные пункты, части и статьи закона, а так-же проводился их анализ.
Подобралась следующая таблица, которую я в дальнейшем планирую пополнять:
Автор заметки
Анализируемые статьи
Основная цель заметки
Михаил Емельянников
ч.3 ст.6
ч.5 ст.6
ч.2 ст.18
ЛООПДППО
Михаил Емельянников
ст. 5
ст. 6
ст. 9
ст. 14
ст. 17
ст. 24
Права субъектов ПДн
Михаил Емельянников
ст. 3
ст. 18
ст. 18.1
ст. 21.1
ст. 22
Термины и определения
Алексей Волков
ч. 1 ст. 11
Биометрия
Алексей Волков
ч. 3. Ст. 6
ч. 5 Ст. 6
ч. 1 Ст. 18.1
ч 2 ст 19
Оценка эффективности,
контроль
Алексей Волков
ст. 18.1
ст. 19
ст. 22.1
Обязанности Оператора
Алексей Волков
ст. 18.1

Политика обработки ПДн
Алексей Волков
ст.19
Этапы определения мер по обеспечению безопасности ПДн
Алексей Лукацкий
ст. 14
ст.18
ст.18.1
ст.19
Общее мысли
Игорь Харов
22.1
Лицо, ответственное за организацию обработки ПДн
Артем Аветян
ст.19
Этапы определения мер по обеспечению безопасности ПДн
Мои комментарии ниже
ст. 3
ст. 5
ч. 1 ст. 6
ч. 8 ст. 9
ст.21
ч. 2.1 ст 25
Общее мысли
Сергей Борисов
ч. 2 ст. 19
СЗИ
Сергей Борисов
ч. 1 ст. 6
ч. 1 ст. 8
ч. 3 ст. 9
Контактные ПДн

По нескольким пунктам хочу так-же добавить свои комментарии.
В статье 3 приведено следующее новое определение:
«обезличивание персональных данных - действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных»
Понятие «обезличивание персональных данных» расширенно. Теперь позволяется применять идентификаторы,  выделить данные, позволяющие определить принадлежность субъекта ПДн, в отдельную базу, которая будет защищаться по полной программе. В остальных базах  можно оставлять только внутренние идентификаторы и категоризировать их как «обезличенные».
В части 2 статьи 5 приведено изменилась формулировка:
«Обработка персональных данных должна ограничиваться достижением конкретных, заранее определенных и законных целей. Не допускается обработка персональных данных, несовместимая с целями сбора персональных данных»
То есть теперь цели обработки должны быть более конкретными. “выполнение ФЗ” и “получение прибыли” – не пройдет. Конкретной целью обработки ПДн будет, например “идентификация субъекта при оказании ему услуги”, “доставка субъекту отчетов об оказанных услугах”.
На счет несовместимых целей – вообще беда. Нигде не определены критерии совместимости. Приходится полагаться на экспертное мнение.
В части 7 статьи 5 приведено следующее требование:
«Обрабатываемые персональные данные подлежат уничтожению либо обезличиванию по достижении целей обработки или в случае утраты необходимости в достижении этих целей, если иное не предусмотрено федеральным законом.»
Теперь при достижении целей обработки можно не только уничтожить ПДн, но и допускается обезличивание ПДн. То есть при разделении баз, достаточно будет удалить данные из базы, позволяющей определить принадлежность субъекта ПДн.
Интересен пункт 7 части 1 статьи 6:
«7) обработка персональных данных необходима для осуществления прав и законных интересов оператора или третьих лиц либо для достижения общественно значимых целей при условии, что при этом не нарушаются права и свободы субъекта персональных данных»
Теоретически любую цель обработки ПДн можно подтянуть под этот пункт и осуществлять обработку без согласия субъекта. Для этого надо собрать и изучить законодательство и подзаконные акты связанные с видом деятельности оператора.
В части 8 статье 9 приведено следующее условие:
«Персональные данные могут быть получены оператором от лица, не являющегося субъектом персональных данных, при условии предоставления оператору подтверждения наличия оснований, указанных в пунктах 2 - 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 настоящего Федерального закона»
Если возможна обработка без согласия субъекта, то данные могут быть получены от третьих лиц.  Третьи лица должны будут предоставить оператору подтверждение наличия оснований. То есть третье лицо должно предоставить нам ссылку на ФЗ или иной документ.
В каждой части статьи 21 в обязанности оператора по устранению нарушений законодательства, допущенных при обработке персональных данных, по уточнению, блокированию и уничтожению персональных данных входит  обеспечение устранения нарушений ЛООПДППО. Например часть 3 статьи 21:
«3. В случае выявления неправомерной обработки персональных данных, осуществляемой оператором или лицом, действующим по поручению оператора, оператор в срок, не превышающий трех рабочих дней с даты этого выявления, обязан … обеспечить прекращение неправомерной обработки персональных данных лицом, действующим по поручению оператора. В случае если обеспечить правомерность обработки персональных данных невозможно, оператор в срок, не превышающий десяти рабочих дней с даты выявления неправомерной обработки персональных данных, обязан … обеспечить их уничтожение. ...»
Таким образом, оператор должен перед тем как поручать обработку ЛООПДППО тщательно продумать регламент взаимодействия с ним, и прописать ответственность ЛООПДППО за устранение нарушений законодательства по обращению к нему Оператора.
В части 2.1 статье 25 приведено следующее требование:
«2.1. Операторы, которые осуществляли обработку персональных данных до 1 июля 2011 года, обязаны представить в уполномоченный орган по защите прав субъектов персональных данных сведения, указанные в пунктах 5, 7.1, 10 и 11 части 3 статьи 22* настоящего Федерального закона, не позднее 1 января 2013 года.
* указанные пункты ч.3 ст.22 содержат дополнительные сведения, включенные в уведомление оператора в Роскомнадзор»
Фактически все операторы, в том числе подавшие уведомление, обязаны подать Уведомление в Роскомнадзор.
В случае неподачи - ст. 19.7 КоАП РФ.

понедельник, 8 августа 2011 г.

СЗПДн. Анализ. iPad, iPhone и обработка ПДн

Рассмотрим задачу, когда Компании необходимо обрабатывать (просматривать) на устройствах типа iPad персональные данные. Пусть это будут не критичный набор персональных данных, но и не обезличенный. Следовательно, необходимо обеспечить безопасность обработки ПДн на iPad.

Особенности такой обработки, которые повлияют на оценку угроз:
· Обработка ПДн ведется чаще всего в виде просмотра через web-браузер.
· Хранение ПДн на устройстве не производится.
· Объем обрабатываемых на устройстве ПДн минимальный.
· Устройство чаще всего находится за пределами контролируемой зоны.
· В виду нетрадиционности и новизны ОС iOS, вероятность заражения вирусами небольшая, но в виду набора популярности iOS вероятность ненулевая – определим как «низкая».
Если немного упрощенно, то для данных условий получаем следующую модель угроз:
Наименование угрозы
Вероятность
Потенциальный ущерб от угрозы
Актуальность угрозы
Требования к мерам защиты, необходимым для нейтрализации актуальной угрозы
Организационные
Технические
Перехват ПДн передаваемых по каналу связи
Средняя
Низкий
Актуальная
Применение средств криптографической защиты ПДн
Нарушение характеристик безопасности ПДн в связи с несанкционированным физическим доступом к устройству
Средняя
Низкий
Актуальная
Обеспечение физической безопасности устройства
Применение средств защиты от НСД к ПДн
Нарушение характеристик безопасности ПДн в связи с несанкционированным сетевым доступом к устройству
Низкий
Низкий
Неактуальна
Применение средств межсетевого экранирования
Нарушение характеристик безопасности ПДн в связи с внедрением вредоносного ПО
Низкий
Низкий
Неактуальна
Применение средств антивирусной защиты
Рассмотрим, какими средствами можно реализовать необходимые контрмеры.
Средства защиты от НСД, работающие под iOS, фактически отсутствуют. Но средства защиты от НСД могут быть реализованы серверными компонентами, предоставляющими удаленный доступ к приложению по протоколам HTTP/HTTPS, либо самим приложением ИСПДн. Сертифицированных уже ФСТЭК РФ вариантов немало. Например:
· Citrix Presentation Server 4.5.
· Check Point Connectra.
· StoneGate SSL.
Наибольшая проблема возникает со средствами криптографической защиты.
В данный момент СКЗИ под iOS разрабатываются:
· ViPNet Client iOS, компанией ОАО «ИнфоТеКС».
· «Континент АП» для iOS, компанией ООО «Код Безопасности».
· «Крипто-Про CSP» для iOS, компанией ООО "КРИПТО-ПРО".
Но в данный момент они находятся на стадии бета-тестирования, после которого необходимо будет пройти этап сертификации.
Так что для обработку ПДн на устройствах типа iPad, iPhone лучше не планировать до середины 2012 года.

вторник, 2 августа 2011 г.

СОИБ. Анализ. Сертификация Интернет-магазинов

Как сообщает ИТАР-ТАСС, на встрече Национальной ассоциации дистанционной торговли на встрече с Роскомнадзором было решено создать экспертный технический совет, которому предстоит:
· выработать и довести до участников рынка Интернет-торговли первоочередные технические меры, позволяющие не допустить утечку персональных данных;
· разработать систему добровольной сертификации безопасности Интернет-магазинов.
Собственно подобные идеи приходили мне уже давно, но останавливались в звязи со сложностью создания и регистрации в ФСТЭК системы добровольной сертификации.
Деятельность Интернет-магазинов должна соответствовать следующим требованиям в области ИБ:
· требованиям ФЗ-152 «О персональных данных» и его подзаконным актам;
· требованиям международного стандарта PCI DSS.
При необходимости определения детальных мер защиты Интернет-магазин может руководствоваться следующими методиками международных специализированных на web организаций:
Попробуем предположить, какие задачи может решить экспертный технический совет?
1. Провести анализ различных вариантов реализации Интернет-магазина. При наличие принципиальных различий выделить классы (типы) Интернет-магазинов. Для каждого класса подготовить типовую информационную модель Интернет-магазина.
2. Для каждого класса разработать типовую модель угроз безопасности Интернет-магазина, в том числе требования ИБ, выполнение которых необходимо для нейтрализации угроз. При разработке моделей угроз могут учитываться как положения ФЗ-152, так и PCI DSS.
3. Разработать комплект мер по обеспечению ИБ (Стандарт обеспечения ИБ) Интернет-магазина. Данные меры логично разделить на:
a. реализуемые разработчиком web приложений;
b. реализуемые владельцем Интернет-магазина;
c. реализуемые провайдером, размещающим web приложение.
Данный комплект мер может совместить в себе меры необходимые для реализации ФЗ-152, PCI DSS, а так-же учесть методические документы международных специализированных организаций.
4. Разработать методику оценки соответствия Интернет-магазина требованиям по ИБ.
5. Подготовить комплект документов, необходимый для регистрации системы добровольной сертификации в области ИБ. В том числе необходимо будет разработать требования к организациям, которые будут проводить оценку соответствия и выдавать сертификаты.

Было бы здорово, если в планах экспертного технического совета есть что-то подобное. В результате мы можем получить что-нибудь типа СТО БР ИББС или НИР Тритон.