Многие АБС построены на базе СУБД, работающей под ОС *nix семейства. Далеко не факт, что технически будет возможно установить на сервер АБС СКАД Сигнатуру, а с учетом того, что в больших АБС серверов значительно больше 1, то идея установки «СКЗИ на АБС» превращается в сложно реализуемую.
Таким образом в большинстве случаев криптография будет реализовываться внешним отношению к АБС модулем. В данном исследовании мы их называем модуль интеграции АБС-АРМ КБР. То есть то, о чем вы и сказали — «кроилово».
В данном случае незащищенный канал АБС-АРМ КБР, может поменяется на незащищенный канал АБС-модуль интеграции АБС-КБР. Плюс к этому появятся дополнительные угрозы свалянные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.
Конечно можно сделать все и по уму — защищая канал АБС-модуль интеграции АБС-АРМ-КБР. Все будет зависеть от конкретной реализации.
Угрозы ИБ будут рассмотрены в следующих частях. Забегая вперед можно сказать что АРМ КБР-Н увеличит безопасность только при ОЧЕНЬ качественной реализации функций подписи в модулях интеграции АБС. Если все будет как обычно, то станет только хуже.
В целом мы говорим об одном и том же. То что вы называете «деловым общением с клиентом», я в статье называю «договоренностью» или «согласием клиента на возврат платежа».
Следите за следующими публикациями, в них будет рассказано, как с помощью этого «глупого» вектора из «мегазащищенных» объектов уходят сотни миллионов рублей.
Если было бы все так хорошо, то Банк России не стал бы выпускать 552-П, но об этом в следующих сериях.
Выписка — юридически значимый документ, который может быть представлен, как в бумажном, так и электронном виде. Бумажные выписки ЦБ не отменял, а разрешил предоставлять должным образом заверенные (ЭП или АСП) выписки в виде электронных документов.
Если у клиента на руках есть выписка в виде электронного документа заверенного усиленной электронной подписью (банк не сможет изменить содержащуюся в ней инфу, в отличии от выписки в виде заверенной АСП), и в котором указано что ему на счет поступил платеж, то банк «откатить» платеж может только по согласованию с клиентом. В противном случае любой суд встанет на сторону клиента. Хотя конечно есть нюанс связанный с ошибочными платежами и требованиями ГК РФ по возврату «необоснованного обогащения».
При «межбанке», в какой-то мере даже проще, если банк-отправитель быстро очухался то платеж может быть завешен на «не выясненные» и с минимальными издержками возвращен отправителю.
А то, что банки гоняют платежи «туды-сюды», так и некоторые из них и вклады только в тетрадку записывали. Это вовсе не говорит о том, что они действуют в рамках правового поля.
Согласен с вами на 100%, но угрозы связанные с кредитованием, все таки это отдельная песня. Если будут желающие можно расписать и о них, но текущая наша цель — безопасность платежей в общем случае и АРМ КБР в частности.
Описание безналичных расчетов приведенное в посте максимально упрощено. Для того, чтобы дать полное описание того, как есть на самом деле, пришлось бы несколько Положений Банка России сюда впихнуть, что было бы крайне сложным для восприятия.
Основная цель этой части дать базовые понятия, чтобы было понятно дальнейшее описание функционирования безналичных платежей, информационной инфраструктуры, угроз и атак с ними связанных.
Добрый день.
Хотелось бы задать несколько вопросов для саморазвития.
1) Можете поделиться с общественностью составом применяемых средств защиты информации? Особенно интересуют опыт применения решений для защиты гипервизоров.
2) В приведенных схемах защита от DDoS применена только для защиты каналов обеспечивающих работу ВМ заказчиков, для канала управления (ваши админы) такой защиты нет. Почему?
Подскажите, как с точки зрения информационной безопасности вами оценивается использование инженерами планшетов с подключением к внешним сервисам для своей работы?
Если посмотреть на последнюю картинку то можно предположить что обходы совершаются/логируются с помощью сервиса docs.google.com. Кроме того планшеты используются сотрудниками для личных целей, о чем могут говорить наличие в избранном ссылки на Ютюб, Кубики и т.д.
С одной стороны явной дыры в этом конечно нет, но создаются предпосылки постороннего вмешательства в процесс мониторинга (взлом аккаунта docs.google.com, кража планшета и т.д.), а также зависимость бизнес-процесса от доступности сервисов google.
Интересно, почему для этих целей была выбрана именно такая схема, а не был разработан собственный изолированный корпоративный сервис?
В статье даны универсальные рекомендации, которые подойдут практически для любых случаев. Для читателей интересующихся подобными документами можно порекомендовать посмотреть лучшие практики ИБ в SANS Best practice.
Возвращаясь к политике безопасности следует отметить что кроме мероприятий по защите инфраструктуры необходимо также выстраивать бизнес-процессы управления безопасностью включая: управление доступом, ведение учета, повышения осведомленности и т.д.
О составе подобных бизнес-процессов можно узнать например из комплекса стандартов СТО БР ИББС
При совершении операций внутри страны банки крайне редко запрашивают подтверждение (разве что по очень крупным сделкам). Вы можете перевести деньги контрагенту без каких-либо оснований – требуется лишь отправить в банк поручение осуществить платеж (платежное поручение).
Тут конечно вопрос, что считать очень крупной сделкой. А вообще ПОД/ФТ (115-ФЗ) никто не отменял и там есть критерии обязательного контроля сделок. Если сумма перевода в них попадет, то без доказательств законности перевод не сделают (разрешительная система).
В России установлены определенные требования к организации и функционированию СКЗИ. Эти требования более жесткие нежели, та модель которую предлагает CryptoAPI. Некоторые вопросы вообще не стандартизированы и каждый производитель делает как хочет, например, форматы и способы хранения закрытых ключей. Для инфо в ГОСТ 28147-89 узлы замен отнесены к «долгоиграющему» ключевому материалу, в то время как в импортных стандарты они захардкожены в сам стандарт.
Что я хочу как потребитель — чтобы ключи сделанные на одном СКЗИ могли работать на другом, чтобы для доступа к госсайтам можно было использовать любой сертифицированный криптопровайдер, чтобы производители СКЗИ конкурировали между собой качеством продуктов и поддержкой, а не тем что один сидит на одной «кормушке», а другой на другой.
Но для этого нужна стандартизация, как API, так и форматов. Первые шаги подобной стандартизации сделаны через RFC 4357 с ним появились стандартные узлы замен (S-box). Но этого мало. В статье автор справедливо замечает, что госсайты навязывают определенные СКЗИ.
Но разработчиков тоже можно понять, они делают под определенное СКЗИ, потому что нет универсального API.
Если вы скажете: «А как же MS Crypto API?' Оно не покрывает всех вопросов связанных с работой отечественными СКЗИ. Ради интереса почитайте Руководство программиста для нескольких криптопровайдеров различных производителей.
Без „русского болта“, не обойтись.
P.S. Создание универсального API под любые криптоалгоритмы и любые криптопримитивы это миф, который разбивается об разнообразие выдумок разработчиков систем шифрования.
В этом случае речь уже будет идти не об MS Windows, Interner Explorer и CSP, а о браузерах или других программ с поддержкой https с российскими шифрсьютами
То что вы предлагаете требует переделки практически всего Российского законодательства и подзаконных актов в части регулирования ИБ, электронной подписи и СКЗИ.
«Госсайты» используют квалифицированную ЭП. Требования к квалифицированной ЭП по закону (63-ФЗ) включают в себя использование сертифицированных СКЗИ.
СКЗИ сертифицируется под определенные требования безопасности для применения в конкретной среде функционирования. Сертифицированные экземпляры СКЗИ должны использоваться неизменными, то есть контрольная сумма того, что стоит и того что сертифицировано должна совпадать. Сертифицированные СКЗИ за редким исключением (КриптоПРО CSP 3.8) нельзя вывозить за рубеж.
А теперь вернемся к браузеру и облачному токену предлагаемыми вашей компанией. Они не плохие с точки зрения пользователя. Но с точки зрения действующей законодательной схемы, они в нее не вписываются, нет сертификатов ФСБ. Их применение порождает юридические риски для пользователя в части опротестования электронной подписи.
Нет у нас понятия шифросьюты, у нас есть понятие СКЗИ. Написать програмулину реализующую ГОСТ шифрования могут студенты 3+ курса нормального ВУЗа. Но то что результат ее работы будет совпадать с результатом работы серт. СКЗИ не является основанием для применения ее в гос. органах.
Вырастет компьютерная грамотность населения России, работы у ФАС России станет меньше, никто больше не будет говорить (а точнее навязывать) об использовании конкретных средств, речь будет идти только о стандартных интерфейсах и протоколах
В теории звучит здорово.
На практике, Российские банки сдают отчетность в американскую налоговую (FATCA), там нет ни каких требований по конкретным средствам, есть требования по стандартам, делай чем хочешь, хоть сам пиши.
Но по факту сформировать сообщение это такой квест, по сравнению с которым подобрать нужный браузер для доступа к госсайту, это просто детский лепет. Звонить в Америку узнавать как сделать в итоге приходится не один раз. В том же удостверяющем центре, занимающимся выпуском ключей для госзакупок приходят люди и приносят на флешках вместо сертификатов закрытые ключи, хотя там все четко «навязано» чем пользоваться надо.
Так что свобода, это не значит быстро и просто.
Лично я за то, чтобы навязывания не было.
Начать можно с простого, через ТК-26 сформировать модель CSP, которая бы не зависела от конкретного производителя криптосредств эдакий «Русский CSP».
Хочешь работать с госсайтом твой криптопровадер должен уметь функционал «Русский CSP 1.0» и т.д., а вот кто напишет этот провайдер компания LISSI, КриптоПРО, МО ПНИЭИ,… без разницы.
Начать можно с простого — стандартизировать модель и формат хранения закрытого ключа, чтоб закрытые ключи выпущенные одним СКЗИ подходили для других СКЗИ. Подкиньте идею в ТК-26, обычных смертных (не разработчиков СКЗИ) они не слушают.
Кроме аудита железа и софта надо не забывать про аудит ИБ.
По крайней мере узнать где какие есть криптоключи и когда они заканчиваются. Методику проведения подобного аудита глянуть в статье Аудит СКЗИ и криптоключей
Все это уже проходили, правда не из углекислого газа, а из нефти и иногда из биогаза (метана) — гаприн (http://masterok.livejournal.com/2720715.html)
Сначала тоже говорили как все хорошо, потом как начали делать мнение поменялось и производство вредное и продукт не очень… Хотя сейчас есть попытки возродить. Здесь будет тоже самое думаю.
Но с *nix тема в том, что СКЗИ может не подойти именно под ваш *nix.
Таким образом в большинстве случаев криптография будет реализовываться внешним отношению к АБС модулем. В данном исследовании мы их называем модуль интеграции АБС-АРМ КБР. То есть то, о чем вы и сказали — «кроилово».
В данном случае незащищенный канал АБС-АРМ КБР, может поменяется на незащищенный канал АБС-модуль интеграции АБС-КБР. Плюс к этому появятся дополнительные угрозы свалянные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.
Конечно можно сделать все и по уму — защищая канал АБС-модуль интеграции АБС-АРМ-КБР. Все будет зависеть от конкретной реализации.
Если было бы все так хорошо, то Банк России не стал бы выпускать 552-П, но об этом в следующих сериях.
Если у клиента на руках есть выписка в виде электронного документа заверенного усиленной электронной подписью (банк не сможет изменить содержащуюся в ней инфу, в отличии от выписки в виде заверенной АСП), и в котором указано что ему на счет поступил платеж, то банк «откатить» платеж может только по согласованию с клиентом. В противном случае любой суд встанет на сторону клиента. Хотя конечно есть нюанс связанный с ошибочными платежами и требованиями ГК РФ по возврату «необоснованного обогащения».
При «межбанке», в какой-то мере даже проще, если банк-отправитель быстро очухался то платеж может быть завешен на «не выясненные» и с минимальными издержками возвращен отправителю.
А то, что банки гоняют платежи «туды-сюды», так и некоторые из них и вклады только в тетрадку записывали. Это вовсе не говорит о том, что они действуют в рамках правового поля.
Основная цель этой части дать базовые понятия, чтобы было понятно дальнейшее описание функционирования безналичных платежей, информационной инфраструктуры, угроз и атак с ними связанных.
Хотелось бы задать несколько вопросов для саморазвития.
1) Можете поделиться с общественностью составом применяемых средств защиты информации? Особенно интересуют опыт применения решений для защиты гипервизоров.
2) В приведенных схемах защита от DDoS применена только для защиты каналов обеспечивающих работу ВМ заказчиков, для канала управления (ваши админы) такой защиты нет. Почему?
Подскажите, как с точки зрения информационной безопасности вами оценивается использование инженерами планшетов с подключением к внешним сервисам для своей работы?
Если посмотреть на последнюю картинку то можно предположить что обходы совершаются/логируются с помощью сервиса docs.google.com. Кроме того планшеты используются сотрудниками для личных целей, о чем могут говорить наличие в избранном ссылки на Ютюб, Кубики и т.д.
С одной стороны явной дыры в этом конечно нет, но создаются предпосылки постороннего вмешательства в процесс мониторинга (взлом аккаунта docs.google.com, кража планшета и т.д.), а также зависимость бизнес-процесса от доступности сервисов google.
Интересно, почему для этих целей была выбрана именно такая схема, а не был разработан собственный изолированный корпоративный сервис?
Возвращаясь к политике безопасности следует отметить что кроме мероприятий по защите инфраструктуры необходимо также выстраивать бизнес-процессы управления безопасностью включая: управление доступом, ведение учета, повышения осведомленности и т.д.
О составе подобных бизнес-процессов можно узнать например из комплекса стандартов СТО БР ИББС
Тут конечно вопрос, что считать очень крупной сделкой. А вообще ПОД/ФТ (115-ФЗ) никто не отменял и там есть критерии обязательного контроля сделок. Если сумма перевода в них попадет, то без доказательств законности перевод не сделают (разрешительная система).
Что я хочу как потребитель — чтобы ключи сделанные на одном СКЗИ могли работать на другом, чтобы для доступа к госсайтам можно было использовать любой сертифицированный криптопровайдер, чтобы производители СКЗИ конкурировали между собой качеством продуктов и поддержкой, а не тем что один сидит на одной «кормушке», а другой на другой.
Но для этого нужна стандартизация, как API, так и форматов. Первые шаги подобной стандартизации сделаны через RFC 4357 с ним появились стандартные узлы замен (S-box). Но этого мало. В статье автор справедливо замечает, что госсайты навязывают определенные СКЗИ.
Но разработчиков тоже можно понять, они делают под определенное СКЗИ, потому что нет универсального API.
Если вы скажете: «А как же MS Crypto API?' Оно не покрывает всех вопросов связанных с работой отечественными СКЗИ. Ради интереса почитайте Руководство программиста для нескольких криптопровайдеров различных производителей.
Без „русского болта“, не обойтись.
P.S. Создание универсального API под любые криптоалгоритмы и любые криптопримитивы это миф, который разбивается об разнообразие выдумок разработчиков систем шифрования.
То что вы предлагаете требует переделки практически всего Российского законодательства и подзаконных актов в части регулирования ИБ, электронной подписи и СКЗИ.
«Госсайты» используют квалифицированную ЭП. Требования к квалифицированной ЭП по закону (63-ФЗ) включают в себя использование сертифицированных СКЗИ.
СКЗИ сертифицируется под определенные требования безопасности для применения в конкретной среде функционирования. Сертифицированные экземпляры СКЗИ должны использоваться неизменными, то есть контрольная сумма того, что стоит и того что сертифицировано должна совпадать. Сертифицированные СКЗИ за редким исключением (КриптоПРО CSP 3.8) нельзя вывозить за рубеж.
А теперь вернемся к браузеру и облачному токену предлагаемыми вашей компанией. Они не плохие с точки зрения пользователя. Но с точки зрения действующей законодательной схемы, они в нее не вписываются, нет сертификатов ФСБ. Их применение порождает юридические риски для пользователя в части опротестования электронной подписи.
Нет у нас понятия шифросьюты, у нас есть понятие СКЗИ. Написать програмулину реализующую ГОСТ шифрования могут студенты 3+ курса нормального ВУЗа. Но то что результат ее работы будет совпадать с результатом работы серт. СКЗИ не является основанием для применения ее в гос. органах.
В теории звучит здорово.
На практике, Российские банки сдают отчетность в американскую налоговую (FATCA), там нет ни каких требований по конкретным средствам, есть требования по стандартам, делай чем хочешь, хоть сам пиши.
Но по факту сформировать сообщение это такой квест, по сравнению с которым подобрать нужный браузер для доступа к госсайту, это просто детский лепет. Звонить в Америку узнавать как сделать в итоге приходится не один раз. В том же удостверяющем центре, занимающимся выпуском ключей для госзакупок приходят люди и приносят на флешках вместо сертификатов закрытые ключи, хотя там все четко «навязано» чем пользоваться надо.
Так что свобода, это не значит быстро и просто.
Лично я за то, чтобы навязывания не было.
Начать можно с простого, через ТК-26 сформировать модель CSP, которая бы не зависела от конкретного производителя криптосредств эдакий «Русский CSP».
Хочешь работать с госсайтом твой криптопровадер должен уметь функционал «Русский CSP 1.0» и т.д., а вот кто напишет этот провайдер компания LISSI, КриптоПРО, МО ПНИЭИ,… без разницы.
Начать можно с простого — стандартизировать модель и формат хранения закрытого ключа, чтоб закрытые ключи выпущенные одним СКЗИ подходили для других СКЗИ. Подкиньте идею в ТК-26, обычных смертных (не разработчиков СКЗИ) они не слушают.
По крайней мере узнать где какие есть криптоключи и когда они заканчиваются. Методику проведения подобного аудита глянуть в статье Аудит СКЗИ и криптоключей
Сначала тоже говорили как все хорошо, потом как начали делать мнение поменялось и производство вредное и продукт не очень… Хотя сейчас есть попытки возродить. Здесь будет тоже самое думаю.