среда, 25 июня 2014 г.

Общее. Опять черные списки. Теперь для операторов ПДн

Вчера в Госдуму был внесен законопроект по внесению изменений в законодательные акты, связанные с ПДн и сетью Интернет. 

Помимо требования о необходимости обработки ПДн граждан РФ в БД, расположенных на территории РФ, о котором написал Алексей Лукацкий, РКН наделяется полномочиями ограничивать доступ к информации, обрабатываемой с нарушением законодательства о ПДн и вести реестр нарушителей прав субъектов ПДн.

В своей заметке Алексей не совсем корректно говорит о том, что полномочия по ограничению доступа и реестр нарушителей связаны только с БД, расположенными вне РФ.  На самом, деле вид нарушения никак не ограничивается. Под новую норму попадают такие часто встречаемые ситуации:
·        Не подача уведомления в РКН, когда оно необходимо
·        Некорректно заполненное уведомления в РКН
·        Отсутствие публичной политики ПДн, когда ПДн собираются через сеть Интернет
·        Жалоба субъекта и т.п.

То есть там, где оператору грозил мелкий штраф, теперь возможна блокировка сайта Оператора.

За нарушение в обработке ПДн в одной ИСПДн, теперь могут пострадать все ИСПДн оператора.

Блокировать планируется теми же механизмами черных списков, которые раньше внедрялись в соответствии с ФЗ о защите детей, потом для блокирования террористов, ложной информации о банках, нерадивых блогеров, а теперь и операторов ПДн.


Многие эксперты высказываются что существующие механизмы ограничения доступа не эффективны. Злоумышленники слишком быстро меняют доменные имена и ip-адреса и черные списки за ними не успевают.
В случае с легальными операторами ПДн - для них замена доменного имени приведет к потере клиентов, а следовательно черные списки будут более эффективны.

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


среда, 18 июня 2014 г.

Общее. Целенаправленные эксперты по ИБ

Недавно пятнадцати экспертам (не считая главреда) предложили написать статьи на тему одного нового типа угроз. Видимо, темы друг друга эксперты не знали, поэтому многие написали своими словами об одном и том же.

·        12 из 15 всю статью или часть статьи давали определение этого нового типа угроз
·        6 из 15 называли широко известные примеры данного нового типа угроз (игра в кто первый скажет stuxnet)
·        5 из 15 приводили описания инцидентов, связанных с данным новым типом угроз
·        5 из 15 считают данный нового типа угроз чисто маркетинговой фишкой для продажи определенных технических решений
·        5 из 15 экспертов считают что в качестве контрмеры в общем случае нужно специализированное решение по защите от данного типа угроз
·        4 из 15 экспертов считают что в качестве контрмеры в общем случае нужен SIEM
·        4 из 15 экспертов считают что в качестве контрмеры в общем случае нужен NGIPS
·        3 из 15 экспертов считают что в качестве контрмеры в общем случае нужен NGFW
·        3 из 15 экспертов считают что в качестве контрмеры в общем случае нужен DLP
·        2 из 15 экспертов считают что в качестве контрмеры в общем случае нужно обучение

Теперь вопрос для будущих поколений, которые забудут про упомянутые статьи, но наткнуться на приведенную выше статистику – как вы думаете, что это за новый тип угроз?


вторник, 17 июня 2014 г.

СОИБ. Внедрение. Новые возможности СЗИ от НСД Secret Net 7.2 под прицелом (UPD)

Недавно мой однофомилец Илья Борисов в своем блоге призвал отказаться от продвижения security-by-marketing в сторону real security.

Чтобы поддержать эту инициативу хочу поделится некоторыми моментами из опыта внедрения  Secret Net 7.2 и анализу некоторых маркетинговых функций этого СЗИ от НСД

·        Собственные механизмы управления и система управления.
Напомню что во всех предыдущих версиях Secret Net, требовало внесения изменений в схему AD, управления системой осуществлялось через надстройки групповых политик AD, частично хранило настройки в AD и требовало для установки и работы учетную запись с максимальными привилегиями в AD.
Собственная система управления, не требующая внесения изменений в AD и больших привилегий в AD, я рассматриваю как технологический прорыв, выводящий SN на один уровень с другими современными СЗИ на Российском рынке.

·        Упрощение системы автоматической установки на множество АРМ

Посмотрим, какие неприятные моменты были обнаружены при реализации проекта (внедрение Secret Net для защиты ИСПДн, которая составляет 10% от общего кол-ва узлов):
1.      Документация в версии 7.2 обновилась, но реально в ней документированы не все новые возможности.
Например, отсутствует описание варианта установки без модификации схемы AD. (UPDATE - благодаря помощи Кода Безопасности найдено примечание в отдельном обзаце по поводу такой установки. Но детали по правам доступа отсутствуют)
2.      В целом техническая поддержка вендора Код Безопасности оказалась не готова к любым к вопросам по установке или настройке Secret Net версии 7.2
На любой вопрос, даже по документации, спрашивали свой любимый набор данных



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

 Похоже, что производитель даже не задумывался об определении реально необходимых полномочий для установки своего ПО и сразу попросил максимально возможные.
Дальнейший опыт установки показал что чуть меньших прав тоже достаточно
(UPDATE - из комментариев Кода безопасности получено что для установки достаточно локального админа. Для добавления в управление SN - администратора в Secret Net. Можно сделать раздельно)

4.      Так-же перед установкой сервера безопасности Secret Net необходимо включить режим “Доверять компьютеру делегирование ”. Но на вопрос к ТП указать для каких служб и объектов необходимо включить делегирование, получил ответ, что они пока не в курсе и просят установить делегирование для любых сервисов и объектов. Что в будущем, может привести к печальным последствиям, предполагая, что в домене есть узлы более ценных ИС, кроме ИСПДн и что в третьем пункте мы назначили права доменного админа.



5.      При автоматической установке клиентов обнаружился ещё пара моментов
a.      установка клиентов из системы управления невозможна, опять придется действовать через групповые политики
b.      нужно подготовить файл настройки, файл настройки и дистрибутивы выложить на папку в общем доступе, а в файле настройки  -  логин и пароль учетки от имени которой будет установка и подключение клиента к серверу (смотри пункт 3). Отличный подарок для внутреннего злоумышленника (от которых мы и планировали защищаться)
  (UPDATE) Из комментариев Кода Безопасности получена информация, что учетные данные пользователя указывать не нужно. В таком случае установка возможно с правами локального администратора и потом отдельно добавляем в оперативное управление SN администратором SN.

6.      Оказалось что централизованная система управления не до конца централизованная.  Управлять контролем целостности через неё не получится. Приходится устанавливать и запускать отдельную утилиту на АРМ администратора.  Неужели так трудно включить все функции управления в одну консоль?




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