VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Не указана необходимость регистрации в Котлонадзоре как оператора по обработке ПДн.
Про лицензии очень расплывчато написали.
Если персональные данные (ПДн) передаются хостеру (VDS) в открытом виде и хостер занимается их защитой. то нужна лицензия ФСТЭК России на техническую защиту конфиденциальной информации.
Если хостер шифрует ПДн клиента (например для хранения в защищенных контейнерах) и это является частью предоставляемых услуг, то нужна лицензия ФСБ России по криптографии (ПП 313).
Если у хостера нет ПДн в открытом виде, а хранятся только зашифрованные контейнеры (причем их шифровал сам клиент) то лицензии (ФСТЭК/ФСБ) не нужны.
Итого — у хостера в общем случае должна быть лицензия ФСТЭК России на ТЗКИ и желательно ФСБ России по криптографии
В свое время, пытались RAID-60 массив восстановить, а точнее один файл (снапшот виртуалки), обратились в специализированную компанию, были готовы заплатить ~20k $ — они поднять не смогли.
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.
Создание образа — это 3/100 от расследования. Реальная проблему взывает аналитика, особенно когда не знаешь что ищет и принесли машину «посмотреть».
В случаях проведения внутреннего расследование (без необходимости передачи данных в суд) анализ делают вообще без образа, прямо на живой системе, в параллель работе пользователя, либо с даунтаймом на час или парочку.
Но опять таки — аналитика, аналитика, аналитика :) вот что нужно.
Объясните мне пожалуйста экономическую эффективность солнечной энергетики.
Как я не считал, получается что «обычная сетевая электроэнергия» дешевле, причем в разы…
При расчете себестоимости солнечной электроэнергии (по 10 летним циклам) я учитывал:
1. Стоимость панелей
2. Ограниченный срок жизни панелей < 10 лет.
3. Необходимость технического обслуживания и чистки панелей (особенно снег зимой).
В отношении экологии — сказать что солнечная энергия это «очень чисто» тоже нельзя. Следует учесть эко-затраты на создание/утилизацию панелей и как минимум использование земли (в данном случае — зона отчуждения ЧАЭС это можно опустить)
В итоге, как вы считаете, есть ли практическая польза от солнечных электростанций в текущих экономических реалиях?
Подскажите, а есть ли PoC-exploit демонстрирующий возможность злонамеренного использования ME?
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Исходя из практики использования IT систем, можно сказать что вариант отключения ME подходит только для закрытых систем, то есть систем создаваемых с 0 и с конечным перечнем фирменного софта, рассчитанного на отсутствие ME.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
Кроме повышения безопасности, какие негативные моменты с точки зрения функционала вызовет отключение данной системы. Такие фишки как WOL, включение по нажатию клавиши, я так понимаю работать не будут?
В теории с безопасностью мобильных приложений действительно плохо, но на практике статика по ним небольшая. И я думаю тут закономерность.
Операция по обналичиванию украденного что для кражи по юриками (в том числе Банкам) что по физикам стоит одинаково. У физиков много не украдешь (не считая исключений).
Поэтому интерес к данному виду кражи не такой большой как по сравнению с другими видами атак.
Согласен, спада нет.
Можно сказать что идет спад только по «белому пластику» (атака при которой создают копию магнитной дорожки платежной карты) из-за 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. Переделывать стандарт (думаю это предпочтительней).
На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Поясню. У каждого хостера, позиционирующего себя в области услуг хостинга ПДн.
Про лицензии очень расплывчато написали.
Если персональные данные (ПДн) передаются хостеру (VDS) в открытом виде и хостер занимается их защитой. то нужна лицензия ФСТЭК России на техническую защиту конфиденциальной информации.
Если хостер шифрует ПДн клиента (например для хранения в защищенных контейнерах) и это является частью предоставляемых услуг, то нужна лицензия ФСБ России по криптографии (ПП 313).
Если у хостера нет ПДн в открытом виде, а хранятся только зашифрованные контейнеры (причем их шифровал сам клиент) то лицензии (ФСТЭК/ФСБ) не нужны.
Итого — у хостера в общем случае должна быть лицензия ФСТЭК России на ТЗКИ и желательно ФСБ России по криптографии
А вообще, сейчас реально «поднять» данные только с носителей, имеющих физические дефекты (например, головка сгорела), а для данных имеющих логические повреждения (как из примера ранее) — это практически нереально.
В случаях проведения внутреннего расследование (без необходимости передачи данных в суд) анализ делают вообще без образа, прямо на живой системе, в параллель работе пользователя, либо с даунтаймом на час или парочку.
Но опять таки — аналитика, аналитика, аналитика :) вот что нужно.
Было бы здорово иметь линки на русские переводы данных книг (при наличии)
Как я не считал, получается что «обычная сетевая электроэнергия» дешевле, причем в разы…
При расчете себестоимости солнечной электроэнергии (по 10 летним циклам) я учитывал:
1. Стоимость панелей
2. Ограниченный срок жизни панелей < 10 лет.
3. Необходимость технического обслуживания и чистки панелей (особенно снег зимой).
В отношении экологии — сказать что солнечная энергия это «очень чисто» тоже нельзя. Следует учесть эко-затраты на создание/утилизацию панелей и как минимум использование земли (в данном случае — зона отчуждения ЧАЭС это можно опустить)
В итоге, как вы считаете, есть ли практическая польза от солнечных электростанций в текущих экономических реалиях?
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
Операция по обналичиванию украденного что для кражи по юриками (в том числе Банкам) что по физикам стоит одинаково. У физиков много не украдешь (не считая исключений).
Поэтому интерес к данному виду кражи не такой большой как по сравнению с другими видами атак.
Можно сказать что идет спад только по «белому пластику» (атака при которой создают копию магнитной дорожки платежной карты) из-за 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. Переделывать стандарт (думаю это предпочтительней).
На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.