Странная инициатива, нарушающая базовый принцип банковского бизнеса — «деньги любят тишину». Да и к тому же убивающее понятие «банковская тайна» как класс.
С точки зрения обеспечения безопасности в первую очередь интересны именно сухие цифры. Интересные преступления отмечены в разделах «Анализ преступления» каждой группы.
Давайте поразмыслим над предлагаемой идеей с точки зрения безопасности:
1. Предлагаемый вами криптопротокол базируется на организационных мерах. Создание идентификационного и аутентификационных ключей математически не связаны друг с другом, а это открывает дорогу человеческой глупости — невыполнению требований безопасности.
2.
Ключ SK0 уничтожается. Шаги с первого по третий выполняются в рамках единого процесса без записи SK0 в энергонезависимую память.
Очень сложно для реализации. Когда система работает в виртуальной инфраструктуре реализацию данного требования гарантировать невозможно. Во всех современных сертифицированных ФСБ России СКЗИ есть требования, чтобы после перезагрузки отчищался файл подкачки. Но это практически нигде не выполняется поскольку сильно замедляет процедуру перезагрузки. Были случаи когда активация данной фичи увеличивала время перезагрузки до 15 минут.
3.
Если используемая ключевая пара оказывается скомпрометированной, её ключ (в примере это PK1) помещается в список отзывов
Проблема в том, что списки отзыва сейчас мало кто проверяет. Это в первую очередь относится к браузерам — habr.com/post/332730
4. В чем преимущество вашего подхода?
а) Если использовать стандартный подход с одной ключевой парой, безопасность базируется на обеспечения конфиденциальности 1-го секретного ключа. Скомпрометировали ключ — запускается относительно сложная процедура переидентификации участников, которая базируется на использования альтернативных бесключевых методов аутентификации (например, паспорт).
б) Если рассматривать ваш подход, то безопасность базируется на обеспечении конфиденциальности n-секретных ключей (ключей аутентификации). Сразу возникает вопрос, что сделать проще: засекретить 1 ключ или n-ключей. Ответ очевиден. Едем дальше.
Злоумышленник скомпрометировал 1 из ключей аутентификации и сказал что все остальные ваши легальные ключи скомпрометированы, что тогда? Опять приходим к задаче аутентификации бесключевым способом (паспорт).
в) Вы не определили сколько ключей аутентификации нужно генерить. Если абонент сгенерирует только 1 ключ, ваш подход схлопывается к стандартному.
г) Что будет если злоумышленник скомпрометировал сразу все n-ключей аутентификации? Опять возвращаемся к бесключевой аутентификации.
Рекомендации для улучшения подхода:
1. Посмотрите в сторону математической связи между генерацией ключей идентификации и аутентификации. Она должна быть такой, чтобы ее нельзя было обмануть / не делать и т.д.
2. Опишите всю вашу распределенную систему. Как минимум в ней я услышал про список отзыва ключей (CRL), а раз он есть, то должен быть центр сертификации, иначе как обеспечивается валидность CRL? Описав всю распределенную систему ее можно сравнить со аналогичными схемами классических криптографических задач: ЭДО, криптовалюты и т. д.
Возможно вы найдете определенные ниши, где ваш поход будет работать лучше стандартных.
Проблема в том, насколько можно доверять источникам данных.
Например, был некий абстрактный банк. Собирал вклады, кредитовал связанный с владельцем бизнес, кое-как сводил концы с концами. Затем приходит проверка ЦБ, говорит: «по новым методикам все ваши кредиты плохие и по всем нужно досоздавать резервы». У банка денег на это не хватает, у него отзывают лицензию, вкладчики бегут, образуется дыра в капитале. После этого на Председателя Правления банка (считай генерального директора) заводят уголовное дело и говорят что он украл деньги (в размере дыры в капитале). Как справедливо классифицировать данную ситуацию?
Или другой пример, уже реальный. Хакеры, взломали банковскую сеть, получили доступ к биржевому терминалу и совершали торговые операции, в результате которого банк потерял деньги, а курс доллара относительно рубля заметно изменился. Мнение специалистов по данному инциденту не всегда однозначное. Многие, например, считают, что вся эта атака — фикция, а по факту была некачественная работа сотрудников банка.
Сказать, как на самом деле обстояли дела в обоих рассматриваемых примера — нельзя, недостаточно фактов. Поэтому, при подготовки статьи был принят постулат, что вся написанная в источниках информация правдива и достоверна.
Но в целом вы задаете вполне резонный и справедливый вопрос.
Косвенно подобную тенденцию (больше украл, меньше получил) можно отследить и в представленных материалах, если сравнить наказания, например, в группах:
«Обычные» преступления, совершенные одиночками, не являющимися работниками банка
и
«Обычные» преступления, совершенные одиночками, являющимися работниками банка
В данном исследовании лично для меня тоже открылось много много парадоксов:
1. Женщины, милейшие создания, о которых мысль дурную подумать грех вполне себе могут втихаря подворовывать.
2. IT-специалисты — первые подозреваемые для служб ИБ в преступлениях практически не участвуют. В публикациях данных нет вообще, есть случаи только из личного опыта.
3. Хакеры, хакеры… кредитчики (сотрудники выдающие кредиты), вот кто ворует, так ворует. Хакеры лишь на жалком втором месте. Хотя по неофициальным данным хакерские атаки на баки сейчас реально очень схожи с ограблениями банков на «диком западе» (и часто бывают и много крадут).
Однозначно классифицировать преступления довольно сложно. В приведенных материалах много преступлений которые, как вы правильно заметили, можно отнести к различным категориям. К компьютерным преступлениям, я старался относить те, что по духу ближе к хакерству нежели к обычным.
Подскажите, есть ли данные по экономической эффективности вашей системы?
Например, были у компании — X млн. руб. и 3 плохих сотрудника.
Компания купила вашу систему за Y млн. руб., после чего уволила 3-х плохих и наняла 3-х хороших, работников.
Вопрос покроет ли стоимость DLP в Y млн. руб. выгоды от замены 3-х плохих на 3-х хороших?
наша платежная система создавалась с мыслью о том, чтобы быть интересной в первую очередь для разработчиков, тех, кто ее создает.
Интересный подход, обычно пишут чтоб комфортно было потребителям.
В описании bug bunty написано:
Политика вознаграждения
В настоящий момент мы не осуществляем выплату вознаграждения за найденные уязвимости в соответствии с правилами HackerOne Vulnerability disclosure program (VDP).
DPDK (https://www.dpdk.org/) — это фреймворк для работы с сетью в обход ядра.
Ядро ОС выполняет функцию (де)/мультиплексирования при работе приложений с сетевым оборудованием. Тут получается, что данный фреймворк фактически монопольно, предоставляет сеть только одному приложению, из-за этого становится быстрее, но теряется универсальность.
Реальное применение подобного подхода очень ограниченно, хотя и не нулевое.
Ждем других не менее интересных постов.
1. Предлагаемый вами криптопротокол базируется на организационных мерах. Создание идентификационного и аутентификационных ключей математически не связаны друг с другом, а это открывает дорогу человеческой глупости — невыполнению требований безопасности.
2. Очень сложно для реализации. Когда система работает в виртуальной инфраструктуре реализацию данного требования гарантировать невозможно. Во всех современных сертифицированных ФСБ России СКЗИ есть требования, чтобы после перезагрузки отчищался файл подкачки. Но это практически нигде не выполняется поскольку сильно замедляет процедуру перезагрузки. Были случаи когда активация данной фичи увеличивала время перезагрузки до 15 минут.
3.
Проблема в том, что списки отзыва сейчас мало кто проверяет. Это в первую очередь относится к браузерам — habr.com/post/332730
4. В чем преимущество вашего подхода?
а) Если использовать стандартный подход с одной ключевой парой, безопасность базируется на обеспечения конфиденциальности 1-го секретного ключа. Скомпрометировали ключ — запускается относительно сложная процедура переидентификации участников, которая базируется на использования альтернативных бесключевых методов аутентификации (например, паспорт).
б) Если рассматривать ваш подход, то безопасность базируется на обеспечении конфиденциальности n-секретных ключей (ключей аутентификации). Сразу возникает вопрос, что сделать проще: засекретить 1 ключ или n-ключей. Ответ очевиден. Едем дальше.
Злоумышленник скомпрометировал 1 из ключей аутентификации и сказал что все остальные ваши легальные ключи скомпрометированы, что тогда? Опять приходим к задаче аутентификации бесключевым способом (паспорт).
в) Вы не определили сколько ключей аутентификации нужно генерить. Если абонент сгенерирует только 1 ключ, ваш подход схлопывается к стандартному.
г) Что будет если злоумышленник скомпрометировал сразу все n-ключей аутентификации? Опять возвращаемся к бесключевой аутентификации.
Рекомендации для улучшения подхода:
1. Посмотрите в сторону математической связи между генерацией ключей идентификации и аутентификации. Она должна быть такой, чтобы ее нельзя было обмануть / не делать и т.д.
2. Опишите всю вашу распределенную систему. Как минимум в ней я услышал про список отзыва ключей (CRL), а раз он есть, то должен быть центр сертификации, иначе как обеспечивается валидность CRL? Описав всю распределенную систему ее можно сравнить со аналогичными схемами классических криптографических задач: ЭДО, криптовалюты и т. д.
Возможно вы найдете определенные ниши, где ваш поход будет работать лучше стандартных.
Например, был некий абстрактный банк. Собирал вклады, кредитовал связанный с владельцем бизнес, кое-как сводил концы с концами. Затем приходит проверка ЦБ, говорит: «по новым методикам все ваши кредиты плохие и по всем нужно досоздавать резервы». У банка денег на это не хватает, у него отзывают лицензию, вкладчики бегут, образуется дыра в капитале. После этого на Председателя Правления банка (считай генерального директора) заводят уголовное дело и говорят что он украл деньги (в размере дыры в капитале). Как справедливо классифицировать данную ситуацию?
Или другой пример, уже реальный. Хакеры, взломали банковскую сеть, получили доступ к биржевому терминалу и совершали торговые операции, в результате которого банк потерял деньги, а курс доллара относительно рубля заметно изменился. Мнение специалистов по данному инциденту не всегда однозначное. Многие, например, считают, что вся эта атака — фикция, а по факту была некачественная работа сотрудников банка.
Сказать, как на самом деле обстояли дела в обоих рассматриваемых примера — нельзя, недостаточно фактов. Поэтому, при подготовки статьи был принят постулат, что вся написанная в источниках информация правдива и достоверна.
Но в целом вы задаете вполне резонный и справедливый вопрос.
«Обычные» преступления, совершенные одиночками, не являющимися работниками банка
и
«Обычные» преступления, совершенные одиночками, являющимися работниками банка
1. Женщины, милейшие создания, о которых мысль дурную подумать грех вполне себе могут втихаря подворовывать.
2. IT-специалисты — первые подозреваемые для служб ИБ в преступлениях практически не участвуют. В публикациях данных нет вообще, есть случаи только из личного опыта.
3. Хакеры, хакеры… кредитчики (сотрудники выдающие кредиты), вот кто ворует, так ворует. Хакеры лишь на жалком втором месте. Хотя по неофициальным данным хакерские атаки на баки сейчас реально очень схожи с ограблениями банков на «диком западе» (и часто бывают и много крадут).
Например, были у компании — X млн. руб. и 3 плохих сотрудника.
Компания купила вашу систему за Y млн. руб., после чего уволила 3-х плохих и наняла 3-х хороших, работников.
Вопрос покроет ли стоимость DLP в Y млн. руб. выгоды от замены 3-х плохих на 3-х хороших?
То есть получается: 80/320 = 1/4 = 25% энергии тратится впустую. Что-то, как-то много…
Есть планы по интеграции решения с распространенными антивирусными EDR (Kaspersky AV, Dr.Web, ESET)?
Интересный подход, обычно пишут чтоб комфортно было потребителям.
В описании bug bunty написано:
Насколько бесплатная программа будет эффективной?
Ядро ОС выполняет функцию (де)/мультиплексирования при работе приложений с сетевым оборудованием. Тут получается, что данный фреймворк фактически монопольно, предоставляет сеть только одному приложению, из-за этого становится быстрее, но теряется универсальность.
Реальное применение подобного подхода очень ограниченно, хотя и не нулевое.
А с чем проблемы-то были?