Что такое Банковские сервисы, в чем их специфика? Что нужно для того, чтобы они стали доступны, универсальны и безопасны? Для ответа на эти, казалось бы легкие вопросы, нужно провести огромную работу. Давайте начнем с анализа текущей работы банков. Исторически так сложилось - банки обладают собственной ИТинфраструктурой и сами несут ответственность за ее работоспособность. Как правило, это взаимно интегрированные разные решения от разных вендоров ПО и оборудования. Также необходимо учитывать, что банки зачастую работают на определенных сегментах финансового рынка и соответственно обладают той или иной спецификой бизнеса (обслуживание физических и(или) юридических лица, отраслевые банки, авто-банки, и т.п.). Как следствие такие банки оперируют своим набором бизнес процессов, который необходимо автоматизировать соответствующим банковским ПО. Субъекты рынка, с опорой на свое видение, имеют разные представления, тех или иных процессов или отчетных форм, которые в итоге отражаются в виде «кастомизированных под себя» доработках банковского ПО. Подстраиваясь под запрос рынка, вендоры банковского ПО построили свой бизнес таким образом, что у них нет единого коробочного решения. На сколько мне известно, многие крупные банки занимаются выкупом исходного кода платформы и самостоятельно доработают его под себя, поддерживают собственными силами, но это исключение из правил. Ситуация стала меняться с момента, когда ЦБ стал активно регулировать и контролировать банки (последние 3-4 года). Причем это касается не только банковского ПО, но и требований к бизнес процессам, формам отчётности, которые банки обязаны соблюдать. Основное затруднение многообразие требований и их постоянное обновление. С одной стороны, вроде все логично: ИТ развивается, а с развитием ИТ возникают новые угрозы ИБ и банки должны от них защищаться. Как показал мой опыт взаимодействия с банками, имеется следующая картина уровня развития ИБ: Крупные банки обладают ресурсами, компетенциями, большим штатом специалистов ИБ (аналитики, инженеры), которые , в свою очередь работают по разным направлениям: внутренние задачи ИБ банка, ИБ в ИТ и ИБ у Руководителей продуктов ИТ. Чаще всего они осознают свои бизнес и репутационные риски и уделяют должное внимание вопросам ИБ. Еще с выходом первой редакции 152-ФЗ, многие из них пошли реализовывать первую версию требований от ФСТЭК России (согласно 4 документам ДСП), а спустя некоторое время эти требования трансформировались в Приказ 21 ФСТЭК России. Параллельно у банков действовал стандарт СТО БР ИББС, который в принципе функционально перекрывал требования Приказа 21. Средние банки также обладают ресурсами, компетенциями, но значительно в меньшей степени и не всегда до конца осознают свои риски и уделяют должное внимание вопросам ИБ. Чаще закрывают наиболее критичные для себя угрозы ИБ, по мере их выявления. Маленькие банки не обладают ресурсами, компетенциями и решают вопросы ИБ в большей степени только тогда, когда это прямо и адресно потребует регулятор. У них почему-то сложилось впечатление, что на них требования и законы не распространяются по каким-то не понятным причинам. Очевидно, из-за такого дисбаланса и объективному наличию рисков ИБ, ЦБ был вынужден выпустить ряд требований. Кратко рассмотрим какие требования и каких регуляторов Банки должны будут выполнить в 2021, приведены в таблице 1. Также следуют напомнить очень важный момент: банк является по сути таким же юридическим лицом, на которое распространяется нормы действующего законодательства, а именно: 149-ФЗ, 152-ФЗ и, самый интересный, 98-ФЗ «О коммерческой тайне». Также есть кончено и «банковская тайна», которая по сути растворяется в 152-ФЗ и банковской тайне. Банк, как любое другое юридическое лицо, обязано обеспечить безопасность персональных данных своих клиентов и работников, а если еще переживает за свои активы, то и внедрить и режим защиты коммерческой тайны. Основываясь на своем опыте, я могу припомнить лишь пару банков, которые свою систему ИБ строили правильно: начинали с изучения юридической стороны вопроса, затем двигались в сторону перестройки бизнес процессов и ИТ-инфраструктуры, анализу рисков и лишь потом переходили к ИБ. И именно такие банки осознавали и понимали, что для них является ценной (business critical) информацией и как ее необходимо защищать. И, как ни парадоксально может звучать, требования, выпускаемые ЦБ и иными регуляторами, порой сильно мешали, т.к. требования отнюдь не гибкие и нужно обеспечить формальную безопасность по букве закона единым стандартом, без учета специфики. Таблица 1 – Основные требования ИБ распространяющейся на кредитные организации Федеральные законы ФСТЭК ФСБ ЦБ Импортозамещение 97-ФЗ и 115ФЗ 152-ФЗ 149-ФЗ 187-ФЗ Приказ №21 Приказ №17 Приказ №239 и №235 ПКЗ-2005, № 378, ПКЗ-2005, Приказ № 796 ПКЗ-2005 ПКЗ-2005 719-П ГОСТР 57580.12017, 683-П, 672П, 719-П. 98-ФЗ На свое усмотрение ПКЗ-2005 Проект постановления Правительства «Об утверждении требований к программному обеспечению и оборудованию, используемому на объектах критической информационной инфраструктуры и порядка перехода на преимущественное использование российского программного обеспечения и оборудования» На первый взгляд требований не так много, но на деле есть еще требования, которые вытекают из обозначенных выше, при этом такие требования не очевидны, для их выявления необходимо обладать компетенцией. Ключевая проблема: понять суть требований и попробовать их выполнить (реализовать предусмотренные мероприятия) на конкретной «живой» информационной системе. На этапе реализации выявляются затруднения, проявляются противоречия, разночтения в понимании что именно делать, какие альтернативы использовать. ФСТЭК и ФСБ пишут требования в общем виде, стараются уходить от конкретных требований, переложить бремя формирование конкретных требований на плечи владельцев защищаемой информации или отраслевых регуляторов. Существенное отличие регуляторов по составу требований: ФСБ пишет требования к СКЗИ, иногда к КИИ как к системе, ФСТЭК имеет в своем арсенале требования к различным классам Средств защиты информации, и к объектам информатизации (АС, ИС), которые обрабатывают конфиденциальные данные, требующие защиту. Требований ФСБ не так много, они возникают только тогда когда появляется необходимость примирения СКЗИ для защиты каналов связи и ЭП, участники рынка их изучили, затруднения с реализаций в основном отсутствуют. Требования ФСТЭК с каждым годом становятся более понятными, гибкими и зрелыми, регулятор работает над совершенствованием нормативной базы, и за последние 10 лет она существенно преобразилась в лучшую сторону. ФСТЭК всегда готов к диалогу и выступает за разработку отраслевых требований (моделей угроз), если в этом есть необходимость для снятия противоречий между требованиями Приказов и реальной картиной ИБ. Перейдем к ЦБ, который выпустил общие требования к банковским ИС в виде ГОСТ Р 57580.1-2017, а отдельные требования, применяемые к программному обеспечению или части ИС отразил в своих Положениях. Вот тут возникает основное затруднение, так как бумаге их еще можно попробовать реализовать, а вот на практике это практически невозможно, так как банковская ИС (АБС) чаще всего представляет собой совокупность различных решений, возможно взять какую-то из этих частей и выдрать из общей системы и обеспечить выполнение требований ИБ лишь для нее. Более детально написано об этом тут (https://www.banki.ru/news/columnists/?id=10926253) Вернемся к требованиям ГОСТ Р 57580.1-2017, требования представляют собой базовый состав мер, направленный на защиту информации финансовых операций. В числе прочего, банки обязаны приобрести (использовать) ряд дорогих решений ИБ (DLP, SIEM, САЗ) помимо классических средств ИБ (МЭ, СКЗИ). Также не стоит забывать о более сложном требовании сертифицировать определенный состав ПО или провести его оценку по ОУД4, а также обеспечить безопасный цикл разработки ПО. Ситуацию усугубляет то, что теперь ряд кредитных организаций являются субъектами КИИ с присвоенной категорией значимости и дополнительно должны реализовать ряд новых требований. А с учетом проекта по импортозамещению, не понятно, что сейчас делать банкам - начинать проект по выполнению требований ИБ сейчас или после принятия ПП по имортозамещению? Т.к. есть большой риск того, что в связи с имортозамещением банкам, прежде всего необходимо будет вложить огромную сумму на замену всего ландшафта ИТ-инфраструктуры (начиная от сетевых устройств, заканчивая серверами, операционными системами, СУБД и новым банковским ПО). И как следствие если сейчас вложиться в один набор средств ИБ, которые привязаны будут к текущей ИТ-инфраструктуры то есть большой риск потом еще раз вложиться в другой набор средств ИБ. А это не маленькие суммы подобные затраты на такие проекты могут доходить 100 млн.р. С учетом всех факторов, большая часть банков осознало, что они не готовы и не смогут выполнить в установленный срок данные требования. По этой причине банки начинают искать альтернативы, которые порой доходят до абсурда: банки просят предоставить им средства ИБ по подписки для их ИТ-инфраструктуры, которая находиться совершенно в другом месте. С учетом текущей ситуации наиболее правильным решением будет проработка возможности вывода на рынок ряд защищенные банковских сервисов по модели SaaS и BaaS. Очевидно, что не все банковские продукты можно будет быстро, легко и безопасно перевести в SaaS и BaaS. Для этого потребуется как минимум разработка соответствующих требований со стороны ЦБ, ФСТЭК и ФСБ. Как максимум создание отдельного закона и (или) в виде дополнений в существующие законы (149ФЗ, 152-ФЗ и д.р.) новой сущности и термина «облака» для финансового рынка (сервисы SaaS, BaaS, PaaS, IaaS с учетом специфики требований ИБ, включая хранению огромного кол-во разных УКЭП), а также особых требований к провайдеру такой услуги как гаранта. На текущей момент облако деюре ничем не отличается от обычный ИС (АС). Также не менее важная задача: провести гармонизацию всех требований ИБ, которые распространяются на банк и выявить (создать) требования которые покрывают (или будут) требования всех регуляторов автоматически. Мне в принципе тяжело давать предложения по созданию развитию новых продуктов или сервисов, т.к. я всегда на них смотрю под призмой моего опыта, прежде всего связанного с ИБ и в котором я объединяю несовместимые между собой роли: заказчика, интегратора, регулятора, конечного потребителя в одном лице. К этому необходимо добавить и финансовые показатели и рентабельность проекта и оценить шансы проекта быть успешным. А с учетом текущей постановки задачи, попробовать забыть, что есть какие-либо ограничения (законодательные, финансовые) становиться еще сложнее, т.к. я вынужден продумывать все варианты практической реализации успешного вывода готового решения на рынок, принимая во внимание, что такие ограничения де-факто уже есть. Ниже представлен результат, который у меня получился. Проблема: Публичные облачные решения (Сервисы) в финансовом секторе практически не развиваются. Чаще всего представлены в виде вспомогательных сервисов по взаимодействию с ФНС, ПФР, общедоступными источниками, ЕБС и т.п. Текущая картина: 1. Действующее законодательства не запрещает создавать Сервисы, но есть определенные факторы, которые блокируют развитие. 2. Все доступные на рынке «облачные сервисы» присутствуют в виде вспомогательных не финансовых сервисов либо в виде приватных облаков в рамках одного банка (группы банков). 3. Банки не торопятся переходит на Сервисы имея ряд рисков, которые они не могут переложить на оператора таких услуг. 4. Банки не понимают всех плюсов и минусов в случае переезда на сервис. Основные ограничения и риски: 1. Прямые бизнес риски банка заключаются в: необходимости иметь денежные гарантии на покрытие прямых убытков в случае отказа облачного сервиса и(или) его взлома, который привел к разглашению Банковской тайны и персональных данных клиентов банка; не готовности передавать свои БД клиентов на сторону и делить единую ИТинфраструктуру с другим банком; не готовности предоставлять постоянный доступ к своей БД ЦБ; непонимание того, как будет реагировать на это ЦБ при проверках. 2. Отсутствие на рынке Оператора такого облака, который: взял бы на себя указанные риски; разбирается в банковской специфики, требованиях и законодательстве и в вопросах ИБ; стал бы гарантом надежности и безопасности (для этого необходима некая форма сертификация с рядом требованием для такого оператора, например в ЦБ). 3. В случае если у такого Оператора облачных Сервисов будет подключено большое количество банков с критичными сервисами то это создает большой риск для финансового рынка и безопасности РФ в случае остановки, сбоя или атаки на такой сервис (даже если будет обеспечена отказоустойчивость с 2 ЦОД). 4. В страховых компания отсутствует продукты по страхованию ИТ и ИБ активов и рисков (остановка ИТ системы, взлом, разглашение или уничтожение информации). 5. Отсутствие на рынке единого поставщика банковского ПО, который сможет доработать свои продукты под Сервис и будет заниматься их сопровождением. 6. В законодательстве отсутствует термин «облако» и требований к нему. 7. В РФ нет практики прохождения проверок с публичными Сервисами или она скрыта. Что нужно сделать: 1) Провести анализ потребностей заказчиков и утвердить перечень востребованных облачных сервисов; 2) Провести категорирование сервисов, по следующим параметрам: Критичные и не критичные для бизнеса; Частота запросов и объём информации в день Попадающие под требования ИБ ЦБ (382П, 683П, 672П, 719П, ГОСТ Р 57580); Попадающие под требования ИБ ФСТЭК, ФСБ, КИИ Попадающие под международные требования PCI DSS или платежных систем. 3) Для каждого категорированного сервиса провести анализ (в т.ч. юридической базы, управлению риску) возможности его размещения в публичном облаке сразу для нескольких банков. 4) Проработать архитектуру (целевую платформу) для Сервисов с учетом вопросов (балансировки нагрузки, отказоустойчивости, требований ИБ и безопасному хранению и использованию УКЭП (для СКЗИ Сигнатуры 6, СМЭВ, Налоговой, систем сдачи отчетности в ПФР, ФФОМС и т.п.). 5) Сформировать и согласовать единые требования к таким облачным сервисам в зависимости от категории сервиса. 6) Разработать бизнес модель для облачного сервиса и квалификационные требования к участникам. 7) Оператор облачных услуг должен будет получить доступ к СМЭВ (не будучи УЦ, банком или образовательной организаций доступ он не может получить). 8) Провести тестирования: доработки банковского ПО и средств ЭП с целью их адаптации под облачный сервис; расчёты реальных показателей (сетевого оборудования, серверов, оборудования ИБ) под определённую допустимую нагрузку (воронку банков) и сделать вывод возможности использования Сервиса не более чем для N клиентов и какие есть технические ограничения; Мои общие предложения – чтобы бы я изменил: 1. В первую очередь необходимо внести изменения в уголовной кодекс в части норм связанных с преступлениями и кражами информации. ЦБ и МВД поддержали инициативу Банков и движение началось в этом направлении. Текущие нормы не работают, тогда возникает вопрос - а зачем тратить гигантские бюджеты на ИБ, когда закон не защищает владельцев конфиденциальной информации и нарушители уходят от ответственности или получают несоизмеримое маленькое наказание. 2. Существенно пересмотрел бы подход регуляторов к вопросам ИБ в целом. Нужно: полностью поменять текущий подход по дублированию ЦБ функций ФСТЭК и ФСБ с ужесточением требований и собственной их трактовкой; перейти к риск-ориентированному подходу, в котором банки должны разработать модель угроз ИБ для себя, выбрать меры по нейтрализации и связать это со своими риск менеджментом и вероятными денежными потерями и согласовать такие документы с регуляторами. Сделать так, чтобы все траты на ИБ были целесообразными и закрывали реальные риски, а не были в виде одинакового набора для всех участников в виде «кирпича». Банк сам должен принимать решения вкладывать деньги в ИБ для минимизации риска, или положить деньги на депозит для покрытия ущерба. Начать с ЦБ, т.к. это сейчас ключевой стоп фактор, который мешает активному развитию цифровизации в финансовой сфере. Мало того, что новых разработчиков банковского ПО не появляется, так и текущим поставщикам банковского ПО становиться очень тяжело развивать новые продукты с учетом новых требований ИБ в виде требований (сертифицировать ПО и сделать безопасный цикл разработки, дублирование и ужесточение требований ФСТЭК по обязательному наличию дорогих и сложных подсистем ИБ) и большинство интересных проектов остаются не реализованными именно из-за наличия новых требований ИБ, реализация которых стоит в несколько раз дороже чем затраты на продукт. 3. Целый ряд законов нуждается в обновлении и добавлении новых «облачных» сущностей, систем и подходов к реализации. Для начала ввести понятия облачных сервисов, типов, бизнес моделей, перечня участников. Это сразу же создаст негативную реакцию и фундаментальные вопросы со стороны ФСБ и ФСТЭК. Например: как обеспечить единую контролируемую зону для всех участников? Как доверить ИБ одному участнику (оператору системы)? Как расшарить общие средства ИБ, которые должны принадлежать владельцу информации, а не третьей стороне? И пожалуй самый сложный и главный вопрос как применить текущие требования ИБ распространяемые на ИС (АС) на новую общую сущность? Внести изменения во все текущие требования ИБ или создать новые под эту сущность? По первому сценарию потребуется огромная работа и время, по второму скорее регуляторы будут против или это будет лишь дополнительные требования, которые еще больше усложнять процесс выводу новых безопасных облачных сервисов. Тут ЦБ должен будет занять активную позицию и быть «мостом». 4. Менять нормативные акты необходимо в несколько этапов по мере понимания и погружения в особенности реализации Сервиса. Самое забавное, что без вложения денежных средств в создание такого готового решения, не получиться подготовить, согласовать и изменить правильную нормативную базу, т.к. не получиться спрогнозировать и выявить все бизнес процессы, риски и нюансы при бумажном проектировании системы. И наоборот, без изменения нормативных документов и наличие существующих рисков никто из игроков не рискнет вкладывать в данное направление. Необходимо как раз физически пройти все этапы от идеи до внедрения, чтобы можно было эффективно и зрело вносить предложения по изменению нормативной базы с участием (разработчика банковского ПО, интегратора, ЦОД, заказчика, регуляторов). Т.к. большую часть проблем и рисков лежит и выявиться на их стороне. Я понимаю, почему ФСТЭК и ФСБ работают в своей манере и существующих ограничениях. Они прежде всего отвечают за сохранность информации, которая под грифами. А защитой «конфиденциальной информацией» занимаются по принципу «докучи». Но почему ЦБ принял такой же подход мне и рынку не очень понятно. Если не изменить подход ЦБ к ИБ, боюсь, что все цифровые проекты так и останутся проектами и это относиться ко всем облачным сервисам, и наверное к цифровому рублю, если они конечно не будут реализованы самим ЦБ на своей инфраструктуре. Краткий вывод: Если даже снять ряд рисков и ограничений для рынка по облачным сервисам, думаю, что ситуация не сильно измениться. Сейчас просто нет единой компании или группы компаний из Разработчика банковского ПО, Оператора, Интегратора, ЦОД готовой инвестировать в такой неопределённый проект несколько десятков миллиард рублей и еще гарантировать покрытие рисков связанных с прямыми убытками банков. Со сроком окупаемости таких инвестиций в 3-5 лет с зависимостью от количество банков, которые будут готовы подключиться. Конечная стоимость такого Сервиса напрямую зависит от количества банков готовых подключиться к сервису и чем больше количество таких Банков тем доступнее будет стоимость подключения для всех. Также нужно понимать, что есть порог выше которого невозможно будет подключать новых банков и придётся дублировать решение для новой группы банков желающих подключиться или которым требуются дополнительные мощности. Если получиться привлечь такие компании, то им потребуется еще 1-2 года, чтобы доработать свои продукты, сертифицировать их в ФСТЭК и ФСБ. В итоге такое решение может появиться не ранее чем через 3-4 года. Могу конечно ошибаться, но я в свое время активно участвовал в нескольких похожих проектах связанных с появлением защищенных облаков «по требованиям 152-ФЗ» для юридических лиц. Все они в итоге не развились массово от части из-за своей высокой стоимость размещение ИС за 1 год стоила столько же, как приобрести себе in-house решение со всеми средствами ИБ. Тогда и Ростелеком обращался и хотел в своем публичном облаке использовать для размещения в нем ГИС и ПДн спец. категории. Сейчас Dataline предлагает такие приватные облака и стоимость по прежнему отталкивающая. На мой взгляд, рынок бы доверился, если такой облачный сервис развернул бы ЦБ от своего имени и за бюджетные или собственные средства. Возможно стоит дать возможность крупным банкам «расшарить» свои мощности и продавать такой облачный Сервис другим банкам. Это бы сняло часть вопросов описанных выше, но создало бы новые риски для банка владельца ИТ-инфраструктуры. https://cbr.ru/content/document/file/59559/consultation_paper_181218.pdf