Самые громкие хищения денежных средств за последние пару лет стали следствием атак на АРМ КБР (автоматизированное рабочее место клиента Банка России). Злоумышленники захватывали контроль над IT-инфраструктурой банка и машинами, задействованными в платежных процессах, формировали поддельные или модифицировали существующие поручения и выводили с корсчетов сотни миллионов рублей.

Параллельно с этим приходили новости о новых атаках, связанных с выведением денег через SWIFT, изощренных таргетированных атаках, приводящих к хищению средств клиентов, новых типах карточного мошенничества. Во многих случаях эти атаки принципиально не отличались от атак на АРМ КБР. Компрометируется IT-инфраструктура, идет кропотливое изучение банковских процессов, а затем одним ударом выводятся максимально доступные суммы.

Для специалистов мифа о заоблачно высоком уровне безопасности российских банковских систем никогда не существовало. Почему же эти атаки произошли только сейчас? На наш взгляд, это классический пример security through obscurity (в пер. с англ. — безопасность через неясность). Злоумышленников останавливала запутанность банковских систем, на изучение возможностей атаки потребовалось время (очевидно, что здесь не обошлось без бывших и действующих банковских служащих). А ведь это время можно было потратить на укрепление IT-рубежей. Но осознать величину рисков смогли лишь единицы.

Сложность банковских платежных процессов создает проблемы не только злоумышленникам. ИБ-подразделения сами зачастую с трудом разбираются в особенностях работы этого объекта защиты. Как внедрить первичные меры даже не безопасности, а «компьютерной гигиены», такие как межсетевое экранирование, усиленная аутентификация, антивирусная защита, ясно. Но как заблокировать потенциально опасные воздействия на системы, не навредив их нормальной работе, организовать мониторинг, разделить права, — понять сложнее.

АРМ КБР

Практически каждый российский банк использует для обмена электронными сообщениями (ЭС) с расчетным центром ЦБ РФ программный комлпекс АРМ КБР. Он представляет собой набор компонентов, основным из которых является ПК «Шлюз», обеспечивающий прием, контроль и отправку ЭС. Он может работать в различных режимах, но чаще всего настроен, как «автоматический шлюз», выполняющий операции с ЭС без участия оператора. Типовая схема взаимодействия АРМ КБР с автоматизированной банковской системой банка, где формируются платежные документы, реализована через файловые каталоги. Именно интеграционный уровень является наиболее уязвимым звеном платежного процесса.

В самом АРМ КБР предусмотрены два уровня защиты исходящих платежных сообщений: постановка защитного кода, обеспечивающего неизменность ЭС, и кода аутентификации, обеспечивающего авторство отправителя. Между этими этапами преду­смотрена процедура сверки отправляемого документа с данными в самой АБС, однако эта стадия контроля, как правило, пропускается, поскольку ее реализация требует поддержки со стороны АБС. Таким образом, при работе в режиме «автоматического шлюза» загруженные платежи никем не проверяются, и после автоматической постановки кода аутентификации благополучно отправляются в ЦБ.

Есть и еще один существенный риск. Криптографические ключи, используемые для защиты исходящих ЭС, чаще всего хранятся на незащищенном носителе. Даже если используется аппаратный токен, ключи все равно могут быть извлечены из его памяти, если его микропроцессором не поддерживаются алгоритмы ГОСТ. В настоящее время на рынке представлены ключевые носители, обеспечивающие неизвлекаемость ключей и совместимые со СКАД «Сигнатура» последней версии, применяемой в составе АРМ КБР, однако степень их распространенности пока мала.

Отметим, что в текущем году ЦБ РФ разработал положение, устанавливающее строгие требования к мерам обеспечения информационной безопасности АРМ КБР. К сожалению, в нем практически не упомянуто требование контроля целостности ЭС, передаваемых внутри сети банка.

SWIFT

SWIFT — вторая по распространенности платежная система в российских банках. Кроме валютных платежей SWIFT используется для рублевых переводов между российскими банками, установившими корреспондентские отношения. Программное обеспечение SWIFT включает в себя набор программных продуктов, центральным из которых является SWIFT Alliance Access (SAA), реализующий множество функций по управлению очередями электронных сообщений. SAA предлагает различные методы интеграции с бэк-офисными системами, однако наиболее распространен из них File Transfer, обеспечивающий файловый обмен по протоколу SMB. Интеграционный механизм Message Partner, реализованный в SAA, выполняет перенос ЭС между файловыми каталогами и очередями сообщений в SAA в соответствии с заданными профилями. Каждая очередь в SAA предполагает выполнение определенных операций с ЭС: верификацию, авторизацию, пересылку и т.д. Гибкость настройки профилей Message Partner позволяет создать очередь, в которой исходящее ЭС не будет проходить никакого контроля со стороны оператора. В банках с большим объемом платежей через SWIFT такие очереди — не редкость.

Как и в АРМ КБР, в SAA предусмотрен механизм контроля подлинности ЭС, загружаемых из бэк-офисной системы, — Local Authentication Method (LAU). Однако он требует вычисления сигнатуры ЭС по определенному алгоритму на стороне АБС, поэтому в подавляющем большинстве случаев не применяется.

Как можно убедиться, ЭС платежной системы SWIFT тоже подвержены угрозе подделки. Факт подделки может оставаться незамеченным длительное время, вплоть до выполнения очередной сверки остатков по счетам, когда денежные средства с банковских счетов уже списаны.

В 2016 году SWIFT актуализировал руководство по обеспечению информационной безопасности своих продуктов. Документ похож на упомянутое выше положение ЦБ РФ и включает в себя технические и организационные меры защиты.

Пять шагов к безопасности

Выполнение пяти ключевых действий может существенно снизить риск подделки платежных сообщений при их передаче в сети банка:

1. Изолируйте в отдельные сегменты сети платежные компоненты АРМ КБР, SWIFT и рабочие станции операторов и администраторов. Ограничьте к ним доступ при помощи межсетевых экранов.

2. Выделите отдельный файловый сервер, предназначенный для обмена ЭС, хранения профилей, настроек, а также других данных, относящихся к платежным процессам. Ограничьте сетевой доступ к этому серверу и права доступа к каталогам.

3. Исключите из общего домена файловый сервер, рабочие станции администраторов и операторов платежных систем, если они работают под управлением Windows. Создайте уникальные учетные записи. Обновляйте ПО регулярно.

4. Используйте аппаратные токены, обеспечивающие неизвлекаемость ключевой информации (рекомендация относится к АРМ КБР, так как SWIFT требует применения HSM).

5. Используйте средства выявления подозрительного трафика внутри локальной сети банка. Даже если какой-то узел был скомпрометирован, злоумышленник /вредоносный код себя обязательно проявит. Средства антивирусной защиты на данном этапе уже неэффективны.

К сожалению, даже этот базовый набор во многих банках не выполняется.

Внедрение пожарных мер не дает повода расслабляться. Защитой сердца банковского IT необходимо заниматься непрерывно: проводить аудиты, пентесты, адаптировать средства защиты, обмениваться опытом с коллегами. Сделать 100%-ную защиту невозможно. Однако, чтобы убежать от медведя, зачастую нужно бежать не быстрее медведя, а быстрее самых медленных своих товарищей. Практика показывает, что это правило действует и для атак на банковские системы.