В теории с безопасностью мобильных приложений действительно плохо, но на практике статика по ним небольшая. И я думаю тут закономерность.
Операция по обналичиванию украденного что для кражи по юриками (в том числе Банкам) что по физикам стоит одинаково. У физиков много не украдешь (не считая исключений).
Поэтому интерес к данному виду кражи не такой большой как по сравнению с другими видами атак.
Согласен, спада нет.
Можно сказать что идет спад только по «белому пластику» (атака при которой создают копию магнитной дорожки платежной карты) из-за EMV (чипованных) и PayPass / PayWaveкарт.
В тоже время наблюдается рост атак CNP (card not present), что не нужно интерпретировать не как ошеломляющую победу EMV (чиповыанных ) карт, а как общее повышение интереса преступной среды к воровству в области электронных платежей.
Это статистика отчетных форм 0403203 и 0409258 В них преимущественно данные по ущербу клиентам (хотя в 203 должна быть общая).
Проблема с картами Кузнецкого и процессорного центра, в котором проблема локализовалась сюда не относится поскольку проблемы были на «банковской стороне».
Друзья, спасибо вам за ваши комментарии. Вы помогли взглянуть на то с чем я уже давно работал свежим взглядом.
Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.
Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.
В общем случае архитектура документов по данной тематике следующая:
1. Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов
2. Регламент управления доступом. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,.но это внутреннее дело каждой компании, каждый работает как ему удобней.
Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
Здесь не соглашусь, по следующей причине:
Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.
Коллеги, разрешите вступлюсь за КриптоПРО.
Клиентская лицензия для КП CSP (без возможности формирования ЭП + только клиентский TLS) — бесплатна.
Кому надо можете запросить соответствующее письмо у них в офисе.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов?
Для сквозного прохода от точки доступ. Так обычным юзерам намного проще они говорят друг-другу «Возьми файлы в паке отчеты нашего отдела», а передавать полную ссылку на путь, а тем более копировать ее в поле адрес explorerа доступно далеко не всем.
Я не делаю ресурсы вложенными
Делали бы так с удовольствием, но требования бизнеса другие, искоренить пробовали — не вариант.
… сигнал к тому, что информационный ресурс надо разделить на два ресурса…
Менять структуру файловой системы ради распределения доступа — в общем случае не вариант, так как на нее могут быть завязаны приложения, которые «привыкли» искать файлы в определенных местах. В частных случаях это можно делать, но в общем случае это тупиковый путь — пробовали. Плюс очень много негатива от пользователей.
NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
Они есть это IDM — но это деньги.
По поводу стандартизации. Сказать пользователю, что мы не разграничиваем доступ к такой-то папке потому как это запрещено нашим внутренним стандартом — тупиковый путь. Был подобный опыт, но когда на этом настаивает топ-менеджер, то тут 2 варианта остается
1. Искать новую работу
2. Переделывать стандарт (думаю это предпочтительней).
На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.
Да, для целей ИБ нужна «третья» учетная система, которая бы вела учет прав доступа и выполняла бы работы по предоставлению доступа, а это классический IDM.
Если есть деньги (от 1 млн. р., из тех цен что нам предлагали) то это хороший выбор, если нет, то живем с тем что есть.
Избавиться от Крипто-Про в тестовых целях конечно можно, но на проде у вас могут следующие грабли:
1. Поддержка ключевых носителей eToken, Соболь, и т.д.
2. Поддержка параметров алгоритмов.
3. Работа с аппаратными генераторами случайных чисел.
4. Экзотические грабли, но тем не менее — переход на новые шифры «Кузнечик», «Стрибог» и т.д. не факт что в Bounty Castle оперативна появится их поддержка.
Хотя если делать замену КП на BC как черного ящика, то есть нечто что шифрует, то такой способ имеет место быть.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR
В разных организациях данная схема была реализована по разному в том числе с траверс группами. В текущей, админам проще прописывать каждый раз новые траверсы, но как говорится каждому свое.
По поводу групп согласен -NA, стандарт можно расширить на указанные полномочия. Сразу описывать их не стал, поскольку у тех кто столкнулся с данной задачей впервые будет взрыв мозга.
В целом согласен.
В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.
Для себя дублируем структуру папок на уровне OU в AD, например так:
Informations reourses:
— FILE
— FILESRV
— Имя точки входа
— вложенные ресурсы
Но это тоже костели.
Если есть идеи как улучшить стандарт, давайте сделаем это :) Можно в личку отписать или обменяться контактами.
Потому в тот момент, когда права становятся стационарными ....
А когда наступает этот момент и кто его определяет? Вы уверены что все ваши «стационарные» права переведены на группы?
Безусловно, у каждого подхода «per user» или «per group» есть свои плюсы и минусы. Исходя из собственного опыте лучше иметь список из сотен групп, нежели проводить аудит сотен «шар», в которых предоставлены права.
Основная схема групп в домене должна отражать реальную организационную структуру предприятия, то есть должны быть отделы, подотделы, должности и т.п.
Вы говорите про ролевые группы, в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа, на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно.
В вашем примере есть ролевая группа «Главные бухгалтера», которую вы помещаете в группу доступа FOLDER-FILESRV-Общая_бухгалтерии-RW. Стандарту этому не противоречит.
К сожалению на практике так сделать не получается.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
Еще забыл сказать. Когда выдаются права «per group» делать это могут сотрудники тех. поддержки, которым делегирован доступ в АД на изменения состава групп, но которые не являются администраторами файловых серверов.
Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?
Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.
Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
Mapped drive при управлением доступом это зло.
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
Операция по обналичиванию украденного что для кражи по юриками (в том числе Банкам) что по физикам стоит одинаково. У физиков много не украдешь (не считая исключений).
Поэтому интерес к данному виду кражи не такой большой как по сравнению с другими видами атак.
Можно сказать что идет спад только по «белому пластику» (атака при которой создают копию магнитной дорожки платежной карты) из-за EMV (чипованных) и PayPass / PayWaveкарт.
В тоже время наблюдается рост атак CNP (card not present), что не нужно интерпретировать не как ошеломляющую победу EMV (чиповыанных ) карт, а как общее повышение интереса преступной среды к воровству в области электронных платежей.
Проблема с картами Кузнецкого и процессорного центра, в котором проблема локализовалась сюда не относится поскольку проблемы были на «банковской стороне».
Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.
Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.
В общем случае архитектура документов по данной тематике следующая:
1. Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов
2. Регламент управления доступом. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,.но это внутреннее дело каждой компании, каждый работает как ему удобней.
Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.
Клиентская лицензия для КП CSP (без возможности формирования ЭП + только клиентский TLS) — бесплатна.
Кому надо можете запросить соответствующее письмо у них в офисе.
Для сквозного прохода от точки доступ. Так обычным юзерам намного проще они говорят друг-другу «Возьми файлы в паке отчеты нашего отдела», а передавать полную ссылку на путь, а тем более копировать ее в поле адрес explorerа доступно далеко не всем.
Делали бы так с удовольствием, но требования бизнеса другие, искоренить пробовали — не вариант.
Менять структуру файловой системы ради распределения доступа — в общем случае не вариант, так как на нее могут быть завязаны приложения, которые «привыкли» искать файлы в определенных местах. В частных случаях это можно делать, но в общем случае это тупиковый путь — пробовали. Плюс очень много негатива от пользователей.
Они есть это IDM — но это деньги.
По поводу стандартизации. Сказать пользователю, что мы не разграничиваем доступ к такой-то папке потому как это запрещено нашим внутренним стандартом — тупиковый путь. Был подобный опыт, но когда на этом настаивает топ-менеджер, то тут 2 варианта остается
1. Искать новую работу
2. Переделывать стандарт (думаю это предпочтительней).
На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.
Если есть деньги (от 1 млн. р., из тех цен что нам предлагали) то это хороший выбор, если нет, то живем с тем что есть.
1. Поддержка ключевых носителей eToken, Соболь, и т.д.
2. Поддержка параметров алгоритмов.
3. Работа с аппаратными генераторами случайных чисел.
4. Экзотические грабли, но тем не менее — переход на новые шифры «Кузнечик», «Стрибог» и т.д. не факт что в Bounty Castle оперативна появится их поддержка.
Хотя если делать замену КП на BC как черного ящика, то есть нечто что шифрует, то такой способ имеет место быть.
В разных организациях данная схема была реализована по разному в том числе с траверс группами. В текущей, админам проще прописывать каждый раз новые траверсы, но как говорится каждому свое.
По поводу групп согласен -NA, стандарт можно расширить на указанные полномочия. Сразу описывать их не стал, поскольку у тех кто столкнулся с данной задачей впервые будет взрыв мозга.
В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.
Для себя дублируем структуру папок на уровне OU в AD, например так:
Informations reourses:
— FILE
— FILESRV
— Имя точки входа
— вложенные ресурсы
Но это тоже костели.
Если есть идеи как улучшить стандарт, давайте сделаем это :) Можно в личку отписать или обменяться контактами.
А когда наступает этот момент и кто его определяет? Вы уверены что все ваши «стационарные» права переведены на группы?
Безусловно, у каждого подхода «per user» или «per group» есть свои плюсы и минусы. Исходя из собственного опыте лучше иметь список из сотен групп, нежели проводить аудит сотен «шар», в которых предоставлены права.
Вы говорите про ролевые группы, в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа, на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно.
В вашем примере есть ролевая группа «Главные бухгалтера», которую вы помещаете в группу доступа FOLDER-FILESRV-Общая_бухгалтерии-RW. Стандарту этому не противоречит.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
Короче сплошные плюсы :)
Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)