Наши специалисты — Алексей Зенин, ведущий аналитик, и Виталий Филиппов, ведущий разработчик, — прокомментировали для «Российской Бизнес-газеты» вопрос безопасности систем дистанционного банковского обслуживания. Какие системы ДБО обеспечивают лучшую защиту — вендорские или собственной разработки? В чем заключаются особенности разработки вендорских и inhouse продуктов, способные повлиять на качество защиты? Каким образом злоумышленники могут получить доступ к клиентскому интерфейсу и данным пользователей? Об этом — в материале «Ключ от банка» на сайте и в бумажной версии издания.
Алексей Зенин: Большинство атак на системы ДБО осуществляется при помощи вредоносных программ. Такую программу часто называют «троянским конем» или, сокращенно, «трояном». Как и в деревянном коне, подаренном греками защитникам Трои в античные времена, под внешне невинной оболочкой скрывается опасность. В данном случае это программный код, способный украсть данные с компьютера или смартфона. Некоторые разновидности троянов могут внедряться злоумышленниками скрытно. Вредоносная программа получает доступ к клиентскому интерфейсу системы ДБО, а также к ключам электронной подписи, что позволяет ей перевести деньги с банковского счета жертвы злоумышленникам.
Причина более высокой уязвимости продуктов ДБО, разработанных вендорами, кроется в их широкой распространенности и доступности. Разработка троянской программы — сложная и трудоемкая задача, посильная лишь высококвалифицированным программистам, но одной квалификации здесь недостаточно. Чтобы сделать отмычку к замку, необходим сам замок. Чтобы изготовить программу, взламывающую систему ДБО, злоумышленнику нужна копия системы ДБО «у себя дома» — так значительно проще обнаружить ее уязвимости и протестировать «трояна» перед отправкой в бой. Учитывая, что демонстрационные версии некоторых популярных систем ДБО может скачать любой желающий прямо с сайта поставщика данных ИТ-систем, разработать «отмычку» к широко распространенной системе ДБО значительно проще.
В качестве второй причины более частых взломов популярных систем можно назвать большее количество потенциальных жертв. Так как распространение вредоносных программ обычно происходит «вслепую», то чем больше потенциальных жертв, тем выше потенциальная прибыль злоумышленников.
Таким образом, в случае, когда банк среднего звена с небольшой клиентской базой работает с системой ДБО собственной разработки, подготовка взлома сильно затрудняется отсутствием «тестового стенда» и становится нецелесообразной по экономическим соображениям.
Виталий Филиппов: То, что в системах ДБО, разработанных inhouse, силами собственных разработчиков банков, серьезных уязвимостей меньше, чем в вендорских — безусловно, интересный и неожиданный вывод исследования. Казалось бы, все должно быть ровно наоборот — у вендоров должно быть больше опыта, в том числе и в области обеспечения безопасности, а с учетом того, что их продукт может использоваться не одним, а несколькими банками, требования к его защищенности должны быть более высокими. Однако исследование показывает обратное. Можно предположить следующие причины:
- если вендорские ДБО — это готовые продукты, отягощенные большим объемом старого, унаследованного кода и в целом большим объемом универсального функционала «на все случаи жизни», для всех клиентов, то, возможно, разработки inhouse в среднем современнее, легковеснее и потому менее уязвимы;
- если объем кастомизации готового продукта при внедрении в банке велик, а кастомизацию, то есть адаптацию системы под конкретного заказчика, проводят другие, возможно, менее квалифицированные команды разработки, существенно повышается риск внесения уязвимостей этими командами;
- поскольку код внутренней разработки не может быть закрыт от банка, можно предположить, что аудит его безопасности проводится проще и эффективнее. Также вполне возможно, что аудиту собственных систем банки просто уделяют больше внимания;
- так как inhouse разработка в целом дороже покупки готового продукта, вероятно, при изначально больших тратах на систему в целом банки готовы потратиться и на более квалифицированных разработчиков, и на вопросы безопасности при разработке ПО.
Иными словами, скорее всего, причины кроются где-то в области методологии разработки, внедрения и (или) управления жизненным циклом систем ДБО, хотя без дополнительных исследований точно установить это вряд ли возможно.
Что касается разницы в числе уязвимостей в системах для юридических и физических лиц, представленной в исследовании (7,5 против 8,3 критичных уязвимостей) — она, с моей точки зрения, не является значимой и вполне может объясняться разным набором функционала, например, у юридических лиц не распространен мобильный банкинг.
