Работник УЦ ОБЯЗАН руководствоваться регламентом УЦ. Когда клиент выбирает в каком УЦ получить ЭП, он должен ознакомиться с регламентом, оценить удовлетворяет ли он его требованиям безопасности и т.д.
Если в регламенте УЦ написано, что блокировка производится по простому звонку, то оператор ОБЯЗАН выполнить ее. Клиент должен был оценить риски подобных действий до подписания документов.
На практике, все удостоверяющие центры гос. и коммерческие обычно, с которыми я работал, проводят подобные действия по кодовому слову.
Скорее все журналисты столкнулись с преступной халатностью работников УЦ.
И на последок про DoS. Если вы нашли на улице банковскую карту, то вы можете позвонить в банк эмитент сказать им об этом и ее заблокируют просто по вашему звонку…
Менять бизнес-процессы и принятые бизнес-практики, но это очень сложно, почти нереально.
Если говорить о практике, то варианты есть — кодовое слово, биометрическая идентификация, идентификация через доверенный сторонний сервис и т.д. Ну и в конце концов, можно применять различные методы идентификации для операций различного уровня риска.
Проблема в том, что это будет «усилий» от клиента, но тут уже ничего не поделаешь. Хочешь жить — борись за жизнь.
Проблем тут несколько
1) Паспортные данные, СНИЛС используется как аутентификационная информация, но по сути это публичные данные. Нужно искоренять практику, когда для аутентификации личности используется данная информация.
2) У текущей схемы государственного PKI — набора аккредитованных УЦ (63-ФЗ) есть фатальная проблема конфликт интересов УЦ между безопасностью и продажами. УЦ зарабатывают на количестве проданных ЭП (электронных подписей). Для упрощения продаж ослабляются процедуры проверки документов и идентификации личности. Клиенты не хотят заморачиваться и любую «безопасность» воспринимают как бюрократию, в результате чего пойдут в тот УЦ, где «бюрократии» нет. Это не проблема одного УЦ, это системная проблема, решить которую можно только на уровне законодательства. Нужно менять всю схему. Текущая вариант, когда государство периодически проводит проверки качества работы УЦ по факту не решает проблему.
С точки зрения публикации, то тут журналисты совершили уголовку — подделали подпись собственника (заявителя) ЭП, подделали сканы паспорта. Такое может быть даже если документы будут внимательно проверять. По сути работник УЦ ОБЯЗАН был звонить не журналисту «заминать» вопрос, а в полицию и возбуждать 159, 327 УК РФ.
Не стоит забывать, что подделывая бумажную подпись можно бед натворить много больше, нежели с помощью ЭП.
Можете рассказать, какие железки тестили.
В статье упоминаются только Google Glass и RealWear HMT-1z1, а было ли еще что-нибудь? Ну, например, те же Oculus или Cardboad?
Вы правы, нельзя заниматься compliance-ИБ не зная или не отслеживая законы, но это еще не все. Для качественной работы нужно еще их правильно интерпретировать, а для этого одного чтения документов мало, нужна дополнительная инфа: курсы, конференции, профессиональное общение и т.д.
Зачем обязательно RCE? DoSа вполне хватит (например, SYN flood никто не отменял, да и slow lori тоже могут покатать неплохо). Причем в зависимости от настроек системы, подобное открытие еще может дать неплохой amplify для reflected DDoS.
Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list'ом встречаюсь со стеной непонимания.
White-list по IP не самая хорошая идея. Разрабы могут не иметь статики (static IP) и выходить в Инет с разных мест.
Если хотите повышать реальную безопасность лучше прислушаться к рекомендациям Microsoft и весь доступ к внутренним сервисам открывать только через remoate access vpn.
С точки зрения практической ИБ тут полно вопросов:
1. Перехват ключей во время передачи. (качество «шифрования» передаваемых данных подобными железками порой вызывает большие вопросы).
2. Несанкционированное использование ключей во время их «хранения в USB хабе» (case: админ вытащил ключ ЭП и подписал платежку в банк).
и многое другое… если интересно угрозы ИБ подобной системы можно посмотреть в публикации.
Единственным более менее безопасным вариантом эксплуатации подобного решения — использования токенов с неизвлекаемым ключом в режиме неизвлекаемого ключа (более подробно тут).
С юридической точки зрения тут вопросов очень много. В некоторых случаях подобное решение вообще не допустимо (внимательно читать договоры об ЭДО).
Единственным правильным вариантом с точки зрения ИБ/юридизма будет использование HSM, о чем писали выше. От себя еще раз добавлю — не размещайте ключи ЭП от клиент-банка в подобной системе.
Кроме проблем с забыванием паролей неплохо было бы обратить внимание и на общую защищенность IT инфраструктуры (бухгалтерия, клиент-банк и т.д.).
Настоятельно рекомендую посмотреть в сторону организации резервного копирования, да и другие ИБ контроли общепиту будут не чужды.
обеспечения законности работы систем ДБО для ЮЛ (передача криптоключей и сертифицированных СКЗИ клиентам — лицензируемая деятельность).
обеспечения возможности покупки Cisco с полной криптографией (вендоры перед продажей запрашивают инфу о лицензии и на ее основании пишут ходатайство в ФСБ о возможности продажи).
А если эти библиотеки не стандартные, а самописные какие-нибудь?
Если самописные то, это ближе к понятию разработка СКЗИ и соответственно лицензионному виду деятельности.
....«правильные» ФСБ-шные эксперты…
Сейчас у регуляторов сменилось поколение, и во многом они стали ближе к народу. Это можно увидеть, хотя бы на конференции ТБ Форум, где первые лица ФСТЭКа напрямую общались с аудиторией и рассказывали о своих планах. По линии ФСБ таких мероприятий меньше, но и на них можно увидеть, что от жесткого нормативного регулирования идет движение к учету интересов сообщества и деловых кругов (хотя и не так быстро как хотелось бы).
Считать всех работников регуляторов узколобыми коррупционерами — ошибка.
Сейчас без криптографии не обходится ни один продукт. Если вы пользуетесь стандартными криптоблиотеками (например, openssl) и выполняете сугубо технологические операции, то вам не нужна лицензия.
А вообще, оптимально обратится в ЦЛСЗ ФСБ России и проконсультироваться по интересующей вас проблеме.
Если некая компания сама будет пользоваться своим продуктом, то она делает что хочет.
Если же компания надеется продавать свой продукт другим, то это пограничная ситуация.
Если функция шифрования является основной (например, разработка защищенного мессенджера) — то лицензирование обязательно. Если же, где-то там внутри программы в зашифрованном виде передается технологическая информация (например, пароли гуляют), то нет.
Судя по тому, что в деле Эль Чапо были прецеденты дачи взятки в сотни миллионов долларов, то он даже не ИП или ООО, ему надо акционерным обществом становиться.
С ВЭД действительно вопрос, а вот договор наверно был подписан кровью (Родригеса).
Пароли обычно хэшируются на стороне клиента.
Для усиления статьи стоит упомянуть SESPAKE, благо он подробно расписан на хабре —
habr.com/ru/post/282043
Если в регламенте УЦ написано, что блокировка производится по простому звонку, то оператор ОБЯЗАН выполнить ее. Клиент должен был оценить риски подобных действий до подписания документов.
На практике, все удостоверяющие центры гос. и коммерческие обычно, с которыми я работал, проводят подобные действия по кодовому слову.
Скорее все журналисты столкнулись с преступной халатностью работников УЦ.
И на последок про DoS. Если вы нашли на улице банковскую карту, то вы можете позвонить в банк эмитент сказать им об этом и ее заблокируют просто по вашему звонку…
Если говорить о практике, то варианты есть — кодовое слово, биометрическая идентификация, идентификация через доверенный сторонний сервис и т.д. Ну и в конце концов, можно применять различные методы идентификации для операций различного уровня риска.
Проблема в том, что это будет «усилий» от клиента, но тут уже ничего не поделаешь. Хочешь жить — борись за жизнь.
1) Паспортные данные, СНИЛС используется как аутентификационная информация, но по сути это публичные данные. Нужно искоренять практику, когда для аутентификации личности используется данная информация.
2) У текущей схемы государственного PKI — набора аккредитованных УЦ (63-ФЗ) есть фатальная проблема конфликт интересов УЦ между безопасностью и продажами. УЦ зарабатывают на количестве проданных ЭП (электронных подписей). Для упрощения продаж ослабляются процедуры проверки документов и идентификации личности. Клиенты не хотят заморачиваться и любую «безопасность» воспринимают как бюрократию, в результате чего пойдут в тот УЦ, где «бюрократии» нет. Это не проблема одного УЦ, это системная проблема, решить которую можно только на уровне законодательства. Нужно менять всю схему. Текущая вариант, когда государство периодически проводит проверки качества работы УЦ по факту не решает проблему.
С точки зрения публикации, то тут журналисты совершили уголовку — подделали подпись собственника (заявителя) ЭП, подделали сканы паспорта. Такое может быть даже если документы будут внимательно проверять. По сути работник УЦ ОБЯЗАН был звонить не журналисту «заминать» вопрос, а в полицию и возбуждать 159, 327 УК РФ.
Не стоит забывать, что подделывая бумажную подпись можно бед натворить много больше, нежели с помощью ЭП.
В статье упоминаются только Google Glass и RealWear HMT-1z1, а было ли еще что-нибудь? Ну, например, те же Oculus или Cardboad?
White-list по IP не самая хорошая идея. Разрабы могут не иметь статики (static IP) и выходить в Инет с разных мест.
Если хотите повышать реальную безопасность лучше прислушаться к рекомендациям Microsoft и весь доступ к внутренним сервисам открывать только через remoate access vpn.
С точки зрения практической ИБ тут полно вопросов:
1. Перехват ключей во время передачи. (качество «шифрования» передаваемых данных подобными железками порой вызывает большие вопросы).
2. Несанкционированное использование ключей во время их «хранения в USB хабе» (case: админ вытащил ключ ЭП и подписал платежку в банк).
и многое другое… если интересно угрозы ИБ подобной системы можно посмотреть в публикации.
Единственным более менее безопасным вариантом эксплуатации подобного решения — использования токенов с неизвлекаемым ключом в режиме неизвлекаемого ключа (более подробно тут).
С юридической точки зрения тут вопросов очень много. В некоторых случаях подобное решение вообще не допустимо (внимательно читать договоры об ЭДО).
Единственным правильным вариантом с точки зрения ИБ/юридизма будет использование HSM, о чем писали выше. От себя еще раз добавлю — не размещайте ключи ЭП от клиент-банка в подобной системе.
Настоятельно рекомендую посмотреть в сторону организации резервного копирования, да и другие ИБ контроли общепиту будут не чужды.
Если самописные то, это ближе к понятию разработка СКЗИ и соответственно лицензионному виду деятельности.
Сейчас у регуляторов сменилось поколение, и во многом они стали ближе к народу. Это можно увидеть, хотя бы на конференции ТБ Форум, где первые лица ФСТЭКа напрямую общались с аудиторией и рассказывали о своих планах. По линии ФСБ таких мероприятий меньше, но и на них можно увидеть, что от жесткого нормативного регулирования идет движение к учету интересов сообщества и деловых кругов (хотя и не так быстро как хотелось бы).
Считать всех работников регуляторов узколобыми коррупционерами — ошибка.
А вообще, оптимально обратится в ЦЛСЗ ФСБ России и проконсультироваться по интересующей вас проблеме.
Если же компания надеется продавать свой продукт другим, то это пограничная ситуация.
Если функция шифрования является основной (например, разработка защищенного мессенджера) — то лицензирование обязательно. Если же, где-то там внутри программы в зашифрованном виде передается технологическая информация (например, пароли гуляют), то нет.
С ВЭД действительно вопрос, а вот договор наверно был подписан кровью (Родригеса).