Сервер платежной системы Hitachi Payment Systems инфицировал банкоматы Индии вредоносным кодом
В середине 2016 года сервер Hitachi Payment Systems подвергся атаке вредоносного кода, с помощью которого преступники получили данные платежных карт с банкоматов таких банков как State Bank of India, HDFC Bank, ICICI Bank, Yes Bank и Axis Bank. В настоящий момент только 19 банков и 641 клиентов заявили о выявленных мошеннических действиях с картами. Чтобы уменьшить риски банки заблокировали карты и посоветовали своим клиентам сменить пин-код.
В заявлении, сделанном Hitachi Payment Systems, сказано, что после внедрения вредоносная программа работала незаметно, уничтожая всякие следы своего существования. Выявить ее активность позволил аудит, проведенный компанией SISA Information Security.
«Причина, по которой сегодня происходят такие атаки, заключается в неэффективном внедрении стандартов, обеспечивающих безопасность платежей», - отметил в своем отчете Даршан Шанефмёрфи (Dharshan Shanthamurthy), генеральный директор SISA. – «С увеличением количества цифровых платежей такие атаки будут становиться масштабнее и губительнее. Во имя инноваций компании выбирают «короткий путь», пренебрегая безопасностью, что вызывает серьезную озабоченность».
Само получение очередного сертификата соответствия стандартам является точкой старта для проектов по выводу новых карточных продуктов на рынок. Это неизбежно связано с внедрением нового функционала в платежные приложения, развертыванием нового ПО, внесением изменений в конфигурацию сети. При этом, сама практика подготовки к аудиту как к ежегодному приему гостей: «генеральная уборка – перестановка мебели - торжественный прием» скрывает в себе опасные последствия. Дизайн защиты, спроектированный для периодической демонстрации аудитору, зачастую, не имеет достаточных степеней свободы. В первую очередь во время аудита смотрят на способность противостоять воздействию и сохранять целостность системы.
Но бизнес требует внесения изменений, и тогда на время удаляют элементы жесткости – отключают защиту. После этого приведение новой системы в защищенное состояние требует адаптации инструментов ИБ, что невозможно без высокой квалификации специалистов и понимания принципов работы системы защиты. Желая сократить издержки на технический персонал и быстро выводить новые продукты на рынок, финансисты провозглашают: «сначала бизнес, потом безопасность». Статистика показывает, что атаки на новые системы банка реализуются уже через 2-3 месяца с момента прохождения очередного аудита. Запуск нового банковского продукта в среде злоумышленников является сигналом к тому, что «есть чем поживиться там, где плохо лежит».
Важно не просто обеспечить статичное состояние защищенности системы. Важно реализовать постоянный процесс безопасного внесения изменений в защищаемую систему, сохранить систему в защищенном состоянии в ходе эксплуатационных воздействий на всех этапах жизненного цикла ПО:
Проверять дистрибутивы на наличие заражений известными «мусорными» зловредами. Часто зараженные файлы в дистрибутивы добавляются при разработке ПО и подготовке дистрибутивов к поставке. Библиотеки, загруженные из недоверенных источников, кодеки и проигрыватели рекламного контента, драйвера, сторонние сервисные утилиты часто являются источниками заражений.
Все более актуальной и доступной становится возможность проверки приложений на наличие уязвимостей в программном коде. Стоит привлечь специализированные лаборатории либо своими силами использовать специализированный инструментарий и методики.
И только после этого распространять ПО, жестко обозначив использование только доверенных инсталляторов и способов установки.
При защите инфраструктуры необходимо уделить внимание не только критически важной «центральной» системе, но и безопасному функционированию каждого элемента сети. Вектор атаки, источник заражения в сети могут быть совершенно неожиданными.
В 2015 году мы наблюдали последствия инцидента, где атака на устройства банковского самообслуживания происходила с сервера в процессинге банка. После атаки зловред самоуничтожился, и определить источник заражения удалось благодаря наличию легенды обслуживания на одном из атакованных устройств. После неудачного «отскока» зловреда на одном из устройств проявились признаки некорректной работы ПО. Инженер «перезалил» устройство с «золотого образа». Однако в течение часа после переподключения терминала к процессингу атака на устройство возобновилась. Это позволило понять, что атака идет с одного из серверов.
Источником заражения могут быть и доверенные поставщики ПО, и недосмотр в технологии распространения нового ПО и обновлений на сети.
Одним из вариантов выхода из сложившейся ситуации является интеграция механизмов защиты на этапе разработки онлайн-сервисов. Этот подход сейчас особенно популярен в странах Ближнего Востока и Азии, потому что когда технологии безопасной эксплуатации приложений программно и методически закладываются в основу новых сервисов, это позволяет оперативно выводить на рынок новые продукты, не снижая уровень защиты. В России этот подход еще не так распространен, так как трудно отказаться от «навесной» защиты. Но с ростом атак и увеличением размера ущерба ситуация должна измениться.
