Кибербезопасность в условиях электронного банкинга. Практическое пособие - Коллектив авторов

наоборот: если человек доверяет плохому продукту, у него возникает ощущение безопасности. Но это плохо – безосновательная успокоенность при реальной незащищенности обычно приводит к печальным последствиям.

Доверие обеспечивается технологией обработки, например применением электронной подписи (ЭП) или специальных каналов доставки. В подлинности купюры, получаемой в банке, можно не сомневаться, хотя ЭП она не содержит. Распоряжение правительства, подписанное подлинной электронной подписью владельца ларька, вряд ли стоит исполнять без дополнительной проверки.

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

Во всех случаях «успешных» хакерских атак банки объясняли своим пострадавшим клиентам, что банк ни при чем, а виноваты они сами. Но как же так? Разве клиент виноват, что банк перепутал его с преступником и отдал преступнику деньги, которые гражданин доверил банку? Зачастую вина клиента в таких ситуациях лишь в том, что он выбрал именно этот банк.

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

Заметим, что эти проблемы существуют объективно в нормальных отношениях банка и клиента. Нужно сказать, что среди клиентов иногда все же попадаются злоумышленники, а среди банков известны случаи, когда имитация хакерских атак использовалась для незаконного вывода денежных средств клиентов со счетов банка.

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

Какое уж тут доверие? Клиенты недовольны банками, банки в каждом клиенте видят потенциального хакера.

Так как быть? Защищать банки от клиентов или клиентов от банков?

Для ухода от крайних позиций целесообразно правильно выставить цели и понять, как сделать информационное взаимодействие клиента и банка безопасным, удобным и при этом недорогим.

Положения Федерального закона от 27.06.2011 № 161-ФЗ «О национальной платежной системе» [51] создали реальные предпосылки для повышения доверия клиентов к ДБО: если деньги клиента со счета в банке исчезнут, то банк должен сначала деньги вернуть, а уже потом разбираться, куда они исчезли и кто в этом виноват. Это достаточно радикальное средство возвращения доверия клиентов к услугам банка. Но риски банков тоже должны быть блокированы – а ведь техническая защита информации никак не может быть профильной для банка. Совсем другой бизнес у банков. Видимо, поэтому за минувшее время почти ничего не изменилось – предпосылки так и остались предпосылками. У сильного всегда бессильный виноват.

В ДБО участвуют две стороны: банк и клиент.

Банк. Функция обеспечения защиты информации, идентификации и аутентификации клиентов не свойственна банку. Но банк вынужден это делать в силу упомянутых особенностей законодательства. Конечно, он делает это плохо. Более того, плохое исполнение этих функций банку выгодно. Имитируя защиту, банк не тратит много денег и всегда может обвинить клиента в недостаточно полном следовании правилам информационной безопасности (ИБ).

Клиент. Клиент (хозяйствующий субъект) приходит в банк потому, что другого способа управлять своими деньгами у него нет. Он исходит из того, что банк его не обманет, и рекомендации банка по ИБ воспринимает как диктуемое ему условие, выполнение которого необходимо для получения услуги от банка.

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

Для банка при выполнении поручения клиента важнейшим элементом является закрепленное клиентским договором положение о том, что банк «выполняет поручения клиента». Клиента, а не хакера.

Для выполнения данного положения в распоряжении банка должны быть средства идентификации и аутентификации, позволяющие однозначно отделять хакерские «поручения» от волеизъявления клиентов, а также надежные средства ЭП. Причем средство ЭП вполне может быть не клиентским, а банковским (с точки зрения размещения). Юридическую значимость имеет волеизъявление клиента, а не его подпись. Подпись может подтверждать волеизъявление, но для этого должны быть обеспечены соответствующие условия – например, собственноручность подписи. Если подпись клиента ставит хакер – является ли это отражением волеизъявления клиента? Думается, что нет.

Таким образом, нужно рассмотреть требования к идентификации и требования к ЭП.

Электронная подпись – это всегда набор данных, основанных на преобразовании исходного сообщения. Отдавая себе отчет в том, что каждая формула уменьшает аудиторию читателей книги в два раза, а распоряжаться таким образом аудиторией коллективной монографии как минимум легкомысленно, постараемся минимизировать обозначения разного рода, ограничившись только теми, что призваны сократить текст, а не ввести в него какую-либо математику. Ознакомиться со схемой ЭП в общем виде можно, например, в [85, с. 211–217].

Анализируя ту или иную схему ЭП, обычно ставят вопрос так: «Можно ли быстро подобрать два различных (осмысленных) сообщения, которые будут иметь одинаковые ЭП?». Ответ здесь обычно отрицательный: трудно это сделать. Если используется хорошая хэш-функция, для которой не найден эффективный механизм поиска коллизий, такая атака практически всегда обречена на провал. Михаил Грунтович [116] поставил вопрос по-другому: «Можно ли, имея два сообщения, подобрать ключи подписи так, чтобы подписи совпадали?». И оказалось, что сделать это чрезвычайно просто! А вот последствия могут быть очень непростыми.

Вот пример действий злоумышленника:

1) подготовить две платежки:

– на 10 млн руб.;

– на 3 руб.;

2) выбрать ключ подписи и рассчитать второй ключ подписи так, чтобы ЭП платежек совпали;

3) зарегистрировать ключи проверки подписи, соответствующие ключам подписи;

4) отправить в банк требование на 10 млн руб. с подписью на первом ключе;

5) дождаться выполнения банком поручения;

6) предъявить банку претензию, состоящую в том, что клиент якобы посылал требование о переводе 3 руб. (на втором ключе), а не 10 млн руб. (на первом ключе), а то, что кто-то подобрал текст сообщения, не изменяющий ЭП, – дело не его. Пусть платит банк, удостоверяющий центр, страховая компания – кто угодно, только верните деньги! И главное, что придется вернуть!

В чем же источник