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

Проблемы доверия к результатам идентификации и аутентификации в финансовых организациях 

Доверие является фундаментальным понятием безопасности (защищенности). Это связано с человеком как субъектом безопасности. Любая защита, сколь бы надежной она ни была, не создаст ощущения безопасности, если человек ей не доверяет.

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

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

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

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

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

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

Какое уж тут доверие?

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

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

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

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

Положения Федерального закона от 27 июня 2011 года № 161-ФЗ «О национальной платежной системе» (161-ФЗ) создали реальные предпосылки для реализации повышения доверия клиентов к ДБО - если деньги клиента со счета в банке исчезнут, то банк должен сначала деньги вернуть, а уже потом разбираться, куда они исчезли, и кто в этом виноват. Это достаточно радикальное средство возвращения доверия клиентов к услугам банка. Но риски банков тоже должны быть блокированы – а ведь техническая защита информации никак не может быть профильной для банка. Совсем другой бизнес у банков.

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

Банк.

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

Клиент.

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

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

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

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

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

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

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

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

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

Принципиально важным является обеспечение целостности, однозначности связи «человек – ключ подписи».

Эта связь может быть обеспечена либо тем, что человек хранит свое персональное средство ЭП у себя, и полностью за него отвечает, либо СЭП хранится в банке («облачная подпись»), а средства идентификации клиента надежны настолько, что позволяют идентифицировать клиента однозначно.

Рассмотрим эти варианты.

Персональное СЭП. Надежное и традиционное решение. Должно быть сертифицировано, отчуждаемо от компьютера, соответствовать принципу локальной реализации, иметь либо собственные средства отображения, либо использоваться совместно с доверенным компьютером, иметь вирусный иммунитет [1] или мощную и постоянно обновляемую систему антивирусной защиты.

СЭП для ДБО у клиента должно иметь определенные особенности. Главная особенность СЭП - оно должно быть ненастраиваемым - работать «в одно касание», «one touch». Настройки безопасности - дело достаточно сложное и тонкое, и лучше его доверить профессионалам[2].

Такие решения есть, стоимость такого решения порядка 500 – 1000 долларов, и поэтому может рекомендоваться юридическим лицам, но представляется дороговатым для клиентов-физических лиц.

При этом, конечно, со стороны банка доверенность информационной системы должна быть обеспечена в полном объеме.

Облачное СЭП. Такие решения только разрабатываются, но разрабатываются активно. И камень преткновения здесь – обеспечение надежной идентификации клиента. Действительно, если осуществлять надежную криптографическую идентификацию/аутентификацию, то требования доверенности среды, локальной реализации СЭП, работы с КП все-равно нужно выполнить. В этом случае цена решения никак не снизится, и никаких препятствий для установки на те же технические средства (уже доверенные) еще и СЭП не будет. То есть – выигрыш здесь недостижим.

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

Некоторые черты такого решения уже вырисовываются – это, видимо, будет мультимодальная биометрия с обратной когнитивной связью. Если получится – то для идентификации достаточно будет смартфона. И, конечно, и в этом случае тоже со стороны банка доверенность информационной системы должна быть обеспечена в полном объеме.

Заметим, что рассмотренное выше требование использовать ненастраиваемое средство идентификации является единым для всех клиентов.

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

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

Рационально ли это? Есть ли другой путь?

Клиент хорошо понимает, что он не специалист по ИБ, наслышан об активности хакерских группировок, надеется, что конкретно его это не коснется, но хочет эти риски передать кому угодно. В цепочке взаимодействия Клиент-Банк нет третьего, поэтому клиент хочет риски передать банку, и даже не сделав это, верит, что так и есть.

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

Как мы видим, все участники информационного взаимодействия хотят расстаться со своими рисками. Но в текущей конструкции взаимодействия клиент-банк такой возможности нет. Противоречие выглядит неразрешимым.

Для его разрешения нужно изменить саму конструкцию. Например, создать единого для всех Национального оператора идентификации (НОИ), который возьмет на себя предоставление доверенной услуги идентификации клиента для всех банков и ответственность за данное представление, тем самым снимая с банков несвойственные им функции и блокируя риски. А НОИ, в свою очередь, свои риски сможет застраховать.

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

Литература:

  1. Конявский В. А. Компьютер с «вирусным иммунитетом». Информационные ресурсы России. 2015. №6. с. 31- 34

 

[1] В сертификатах на СКЗИ это требование формулируется как аксиома («...при сохранении в тайне ключа подписи»).

[2] Не следует ожидать, что в ближайшее время нам удастся в достаточной степени подготовить в области информационной безопасности всех наших сограждан - а именно они и являются клиентами банков. Банкиров бы подготовить... .