Корректируя стратегию защиты платежных технологических процессов после нашумевших инцидентов с выводом сотен миллионов рублей с банковских корсчетов, многие банки задаются закономерным вопросом – с чего начать? Что нужно сделать в первую очередь? Каковы те 20% мер, которые дадут 80% эффекта? Руководства по безопасности, разработанные в 2016 году Центробанком – «О требованиях к защите информации в платежной системе Банка России» (пока в стадии проекта) и SWIFT (Alliance Security Guidance) – не дают ответа на этот вопрос, поскольку содержат широкий свод требований, охватывающих все возможные аспекты безопасности. Разработать документ, определяющий приоритетный подход к решению этой задачи, как это сделал Совет по безопасности в индустрии платежных карт (PCI SSC), никто почему-то не потрудился. 

Попробуем разобраться в сложившейся ситуации, чтобы выделить задачи, которые предстоит решить в первую очередь. 

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

Здесь нужно сделать оговорку. Вектор атаки на файловые каталоги не самый надежный, поскольку поддельные платежи могут быть обнаружены при ближайшей сверке, что повышает шансы банка остановить их исполнение. Второй путь более сложный, но и более надежный. Если удастся получить административный доступ к самому платежному ПО, можно не только изменять правила обработки платежных документов, но и блокировать механизмы контроля, выиграв время на вывод денег. 

Уже на стадии анализа сценариев атаки просматриваются уязвимые места платежного процесса, которыми надлежит заняться в первую очередь.

Абсолютная необходимость

Первостепенная задача – обеспечить контроль достоверности электронных документов, загружаемых в платежное ПО из АБС. Соответствующие механизмы контроля, как правило, уже встроены в платежное ПО. В АРМ КБР это механизм сверки реквизитов загруженных документов с первоисточником (АБС). Правда, для этого в АБС должна быть реализована соответствующая процедура контроля и создана отдельная роль пользователя. Кроме того, разработчики АРМ КБР не предлагают никаких механизмов защищенной коммуникации при сверке реквизитов электронных документов, поэтому сама процедура сверки тоже может оказаться скомпрометированной. В альтернативном ПК «КБР-С» реализовано больше возможностей по безо­пасной передаче данных. Например, поддерживается технология управления очередями сообщений (MQ) для более безопасного обмена данными с АБС. 

В отличие от АРМ КБР, в SWIFT уже «из коробки» реализован механизм контроля целостности сообщений, который предусматривает использование закрытого криптографического ключа. При помощи него на стороне АБС подписываются все передаваемые в SWIFT платежные файлы (Keyed-Hash Message Authentication Code). Однако такой метод требует поддержки соответствующей технологии на стороне АБС. И хотя многие АБС поддерживают постановку электронной подписи (ЭП) на создаваемые в АБС документы, это не снимает задачи по доработке функционала. Как и «КБР-С», SWIFT Alliance Access может интегрироваться с АБС при помощи MQ для обмена данными. Но защита протоколов обмена – это в любом случае полумеры.

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

Будет ли проще доработать АБС или внедрить антифрод-систему, зависит от конкретного банка. Ясно одно – это стратегическая мера и она должна быть реализована. Вероятно, что со временем Центральный Банк обяжет все банки защищать платежные документы уже на стадии их создания. А пока эта работа неспешно ведется, необходимо принимать меры более срочного характера. 

Безопасность сети как панацея

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

Больше факторов, хороших и разных

Задачей номер три является строгая аутентификация пользователей при доступе к платежному ПО. Стандартной схемы аутентификации на базе логина/пароля сегодня уже недостаточно, поскольку, захватив контроль над рабочей станцией банковского сотрудника, злоумышленнику не составляет труда получить используемые им пароли. На помощь приходит многофакторная аутентификация (MFA), которую необходимо использовать как минимум для учетных записей администраторов платежных систем. Основным препятствием для широкого внедрения MFA является отсутствие необходимой инфраструктуры. Если SWIFT Alliance Access «из коробки» поддерживает технологию RADIUS, то АРМ КБР опирается на механизмы безопасности ОС Windows, что требует использования накладных решений MFA, работающих через RDP. Но можно снова прибегнуть к схеме изоляции платежной инфраструктуры в отдельном сетевом сегменте, реализовав при этом двухфакторную аутентификацию на уровне сети и разрешая доступ в определенные сегменты только после подтверждения подлинности. Стоит иметь в виду, что требование многофакторной аутентификации, присутствующее и в стандарте PCI DSS, вступает в силу в 2018 году. Стратегически правильным будет продумать и реализовать единое решение, применимое для всего прикладного ландшафта.

Перечисленные защитные меры являются первостепенными, поскольку именно эти векторы атак фигурируют в большинстве зафиксированных инцидентов. Но не стоит сбрасывать со счетов упорство и изобретательность злоумышленников, ведь игра определенно стоит свеч. Огромный пласт угроз лежит на стороне АБС, где создаются платежные документы. Можно с уверенностью прогнозировать, что в ближайшем будущем основным вектором атаки на платежные процессы станут не только сами АБС, но и интеграционные шины, используемые для обмена данными между банковскими информационными системами.