Применение процессного подхода при обеспечении безопасности систем дистанционного обслуживания

Мирослава Бондаренко.
Заместитель начальника департамента ИТ
ООО КБ ”Альба Альянс”, CIO-14

Сергей Тихонов.
Начальник департамента ИТ
ООО КБ ”Альба Альянс”, CIO-14

Аннотация
Статья посвящена вопросам применения процессного подхода для управления рисками информационной безопасности. Для иллюстрации используется пример активной атаки путем внедрения ложного объекта в систему дистанционного банковского обслуживания.

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

Постановка задачи
Начнем с определений. Процитируем отдел К ГУ МВД России [1]: ”Дистанционное банковское обслуживание (ДБО) - общий термин для технологий предоставления банковских услуг на основании распоряжений, передаваемых клиентом удаленным образом (то есть без его визита в банк), чаще всего с использованием компьютерных и телефонных сетей”.

            Безопасны ли системы ДБО? Скорей нет, чем да. Последние исследования содержатся в недавних публикациях [2], [3], [4]. И эта особенность систем дистанционного обслуживания свойственна не только российским банкам [5], [6], [7]. Каковы же основные ошибки в системах дистанционного банковского обслуживания?

1. Начнем с элементарных ошибок ”welcome hackers”.  Об этом уже писали не раз, но инциденты повторяются с завидной регулярностью [8].
• Легко угадываемый пароль доступа. Даже если ввести контроль сложности пароля, пользователь найдет способ “облегчить” себе жизнь – в конце концов, напишет на бумажке, которую приклеит на видном или легкодоступном месте
• Использование незащищенных и неконтролируемых каналов передачи данных, например общественной сети WiFi, при совершении операций со своим банковским счетом.
• Размещение слишком большого количества личной информации в социальных сетях, что позволяет угадать даже не легкий пароль с помощью персональных данных клиента
• Работа на компьютере с устаревшими сигнатурами, либо с устаревшей сборкой антивируса, либо вообще без антивирусной защиты
• Пренебрежение регулярной проверкой движения по счетам. Регулярная проверка остатков и операций по своим банковским счетам, чтобы убедиться в отсутствии подозрительной активности, поможет вовремя предотвратить инцидент.
2. Предположим, произошел инцидент, проведено расследование, установлены виновные и причины. Но такая информация закрыта. Нет статистики уязвимостей в системах дистанционного банковского обслуживания российской разработки, нет рынка устранения уязвимостей ([9], [10]). Возможно потому, что банк скорей будет разбираться силами собственной безопасности, чем обратится в компетентные органы.
3. Рынок устранения уязвимостей. Есть консультанты, есть специальное программное обеспечение. Есть публикации о большом количестве уязвимостей во многих российских системах банк-клиент [19]. Нет рынка, все закрыто. Аргументы за закрытие понятны – чтобы хакеры меньше знали. Но не проще ли устроить для хакеров конкуренцию, чем top secret?
4. Защита периметра. Не проследили за своевременным обновлением программного обеспечения, установленном на коммуникационном оборудовании; поставили слабый пароль – и хакер вполне может искать рабочее место, на котором установлено ДБО.
5. Элементарное качество кода. Банальные ошибки программирования, особенно в клиентских частях [11]. Тестеры, проверяющие ошибки в коде по формальному, не очень часто обновляемому плану. Консультанты, проверяющие системы дистанционного банковского обслуживания с помощью обычных тестов на проникновение [12]. Возникает простой вопрос – а просто код проверить не пробовали? Не говоря уже о безопасном программировании [13].

Возникает вопрос – если ошибки в системах ДБО хорошо известны, если о них пишут уже не первый год ([9],[19]), почему мало что меняется? Потому что затраты на изменения невыгодны разработчикам ”коробочных” систем ДБО? Ведь расследование инцидентов информационной безопасности, а тем более модификация систем ДБО в сторону большей защищенности – занятие недешевое. Или потому что банки предпочитают избавиться от затрат, переложив риски на клиентов? Или потому что клиенты банков не тратятся на информационную безопасность, в том числе не соблюдают элементарных правил работы с такими системами? Что нужно менять в первую очередь – продукты, сотрудников или процессы?

Чтобы понять это, предположим, что создана практически идеальная система, с которой работают почти идеальные сотрудники. Основные ошибки в системе ДБО исправлены. “Идеальная система” защищена во всех отношениях. Написаны инструкции, ”построены” сотрудники. Достаточно ли этого?

Модель “идеально защищенной” системы

Допустим, сеть клиента корректно защищена фаерволом. Сотрудники клиента получают доступ в Интернет через корпоративные средства защиты. На компьютере сотрудников клиента установлена корпоративная конфигурация Windows. Запрещен доступ к непроизводственным Интернет-ресурсам. Регулярно устанавливаются обновления Windows, регулярно обновляется антивирус. Реализованы требования корпоративной политики информационной безопасности клиента.

Допустим, клиентский модуль системы - ”толстый клиент”, без использования браузера. Клиент пользуется защищенной ИТ-инфраструктурой – защищенной системой ДБО и защищенной корпоративной сетью. Из корпоративной сети пользователи имеют возможность серфинга в Интернет. На рис.1 изображена модель идеально защищенной системы дистанционного банковского обслуживания со стороны клиента.

Рис.1. ”Идеально защищенная” система. Вид со стороны клиента.

Организация-клиент дисциплинирована, ее сотрудники обучены. Такое вряд ли реально, но допустим. В режиме работы с системой дистанционного банковского обслуживания устанавливается VPN. VPN обеспечивает криптозащиту сеанса связи. На рис.2 схематически изображено такое взаимодействие

Рис.2 Взаимодействие клиентского модуля системы ДБО с операционным сервером банка

Средства криптозащиты сертифицированы ФСБ. Порядок обмена электронными платежными документами соответствует требованиям законодательства в части ЭЦП. Средства наложения электронной цифровой подписи сертифицированы ФСБ.

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

Казалось бы, чего же больше?

Модель нарушителя

Существуют разные варианты предполагаемых нарушителей. Это и супер-хакер; и внешне легальный пользователь с хотя бы одним легальным именем доступа в систему; и внутренний нарушитель; и “олдскульный программер” [14]. Но только относительно недавно [15] стали появляться признаки того, что серьезный нарушитель – это скорей бизнес-проект, состоящий в

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

А если так, то и подход проектный.

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

Рис.3. Один из вариантов взлома защищенной системы. Шаг 1. Архитектура аналог Team Viewer [21]. Тем более что исходные тексты подобных программ доступны в профессиональном сообществе. Кэширование программой-агентом ключевой информации. Работа из-под пользовательской учетной записи

Понятно, что и банк, и производитель систем ДБО рекомендуют подключать ключевой носитель только на сеанс подписи платежа. Но даже если клиент не оставляет ключевой носитель постоянно подключенным к USB-порту компьютера, программа-агент во время сеанса передачи ЭПД украдет образ ключевого носителя и пароли, а когда Интернет появится – предаст на свой сервер.

Архитектура подобных систем известна. Подобные системы используются для видеоконференцсвязи, командной работы и удаленного администрирования. Работает через NAT и фаервол. Примеры - тот же SkyPE или Team Viewer.

Атака осуществляется по типу ”man in the middle”, модификация потока данных путем изменения содержимого пересылаемого сообщения (Рис.4).

Рис.4. Один из вариантов взлома защищенной системы. Шаг 2. Использование нюансов в клиентской части ДБО. Работа в offline, наличие у агента копии ключевых носителей даже при переходе в режим VPN

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

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

Защита не документов, а транзакций. Процессный подход.

Каков же выход?  Посмотрим, что происходит в подобных случаях с платежными системами. В платежной системе защищается не электронный документ, а целиком транзакция. Клиент видит перед собой тот документ, который он авторизует.

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

Можно использовать разные варианты защиты электронной транзакции:

• Альтернативный канал для подтверждения платежа [16]
• Код авторизации платежа, зависящий от содержания платежного документа
• Отдельные доверенные устройства для считывания тех параметров платежа, которые клиент видит перед глазами
• Использование доверенных провайдеров, доверенных каналов

Главное – получить от клиента подтверждение основных деталей транзакции независимым способом. Аналогично принципу второй руки при ручном вводе документов.

Иллюстрацией могут служить представленные на CeBIT 2012 персональные картридеры, Vasco Digipass 837, 736. Как и ранее выпущенные Digipass 835. Главный принцип – what you see is what you sign. Устройства адаптированы для немецкого рынка. Реализуют симметричные алгоритмы защиты, 3 DES или AES 256. Специалисты Vasco обращают внимание на особенности терминологии. А именно, что не нужно путать электронную подпись и цифровую подпись. Цифровая подпись на основе асимметричного алгоритма с их точки зрения защищает электронный платежный документ. Электронная подпись на основе симметричного алгоритма с их точки зрения защищает транзакцию. С этим трудно спорить.

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

Получается, в российских условиях нужно адаптировать логику защиты транзакции к особенностям национального контекста. Учитывать правовые риски [17] в нормативно-распорядительной документации. Четко прописывать распределение полномочий, прав и обязанностей на всех шагах процесса обработки электронного платежного документа.
Использовать в технической реализации и симметричные алгоритмы, и асимметричные алгоритмы, и многофакторную аутентификацию, и безопасное подтверждение транзакции.

Как могли бы выглядеть процессы в системе ДБО с защитой транзакций

Как правильно замечают в RSA [18], мошенничество – доходный бизнес, защищать только клиента недостаточно, необходимо комплексное решение. Рассмотрим, как мог бы выглядеть процесс передачи платежного документа в банк в системе ДБО, которая смогла бы защитить и клиента, и банк в описанной ситуации (рис.5).

Рис.5 Предполагаемая система ДБО с защитой транзакций

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

1. В начале транзакции клиент формирует на своем рабочем месте средствами клиентского модуля системы ДБО (это может быть и обычный браузер) электронный платежный документ (далее ЭПД). Специфику реализации клиентского модуля системы мы здесь не рассматриваем.
2. Сформированный документ подписывается электронной цифровой подписью (digital signature), которая реализует асимметричный алгоритм. Для наложения ЭЦП клиент использует свой секретный ключ.
3. Следующий фактор защиты – формирование кода авторизации платежа независимыми средствами для противодействия  активным атакам с искажением содержания документа. Для этого нужно получить независимым средством именно ту платежную информацию, которую клиент видит на экране. Можно воспользоваться средствами Vasco Digipass с оптическим считывателем основных реквизитов платежа с экрана, можно Рутокен [20], можно другие устройства. Главное – это использовать доверенное устройство для считывания основных реквизитов платежа по независимому каналу.
4. На основе считанных реквизитов (их клиент видит на экране доверенного устройства и, если они считаны правильно, нажимает на клавиатуре доверенного устройства кнопку ОК) формируется код авторизации платежа (electronic signature), зависящий от содержания ЭПД. Для формирования этого кода используется симметричный алгоритм и ключ, который известен только клиенту и банку.
5. Клиент вводит код авторизации платежа в клиентский модуль системы ДБО. Только после того как
1. ЭПД подписан ЭЦП
2. ЭПД подтвержден кодом авторизации платежа

            возможна его передача в банк.

6. Средствами клиентского модуля банка клиент инициирует передачу документа в банк. Документ принимает операционный сервер банка по криптографически защищенному каналу.
7. Вопросы защиты периметра сети банка мы в этой статье не обсуждаем, но предполагаем, что должна присутствовать штатная сетевая архитектура – Firewall, NAT, демилитаризованная зона, антивирусная защита и др. Хотим обратить внимание на полезность систем мониторинга информационной безопасности и fraud detection. Простое сопоставление деталей может дать наилучший результат. В описанной выше ситуации взлома ”идеальной системы” сработало то, что следом за основным платежом шел “привязанный к основному платежу” платеж комиссионных, сумма которых составляла определенный процент от суммы основного платежа. Злоумышленники изменили основной платежный документ, в том числе и его сумму. Но не подменили платеж комиссии – слишком мала была его сумма. Мониторинг показал несоответствие суммы комиссии сумме основного платежа, что явилось причиной звонка клиенту от сотрудника банка. Если клиент не подтверждает платеж, который система fraud detection классифицировала как рискованный, это является признаком компрометации и основанием для расследования инцидента.
8. Если ЭПД не вызвал вопросов у системы мониторинга, если успешно подтверждена ЭЦП и код авторизации платежа независимыми средствами, то этот документ попадает в АБС.
9. На основе данных, загруженных в АБС, формируется сообщение клиенту о содержании платежа, принятом банком к исполнению. Такое сообщение можно отправлять клиенту как СМС с подтверждением о доставке, хотя данный способ коммуникации не вполне надежен ([22]). Лучше использовать доверенный канал, если возможно.
10. Получив сообщение, клиент имеет возможность проверить основные реквизиты ЭПД, принятого банком к исполнению.
11. Если эти реквизиты не верны, клиент может связаться с банком для выяснения дополнительных обстоятельств, а возможно и дополнительных действий, если клиент предположит признаки компрометации.

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

Выводы

Обсудив на V Форуме ИТ-безопасности для финансового сектора http://www.ahconferences.com/conferences/?conf=619 данную проблему, мы для себя поняли:

• подход "what you see is what you sign" с учетом многофакторности,
• защита транзакции вместо защиты электронного платежного документа,

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

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

• клиенты private banking,
• клиенты, которым критично иметь возможность безопасного проведения больших сумм через Интернет-банкинг, и поэтому они готовы платить за качественную информационную безопасность
• клиенты, которые критично важны для банка, и поэтому банк готов оплатить повышенную степень безопасности

Что влечет за собой защищенное решение на основе упомянутых технологий с защитой всей цепочки и надлежащим качеством процессов.

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

Литература

1.  Система ”Банк-клиент” – предотвращение угрозы http://www.cyberpolice-nn.ru/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B4%D0%BB%D1%8F%20%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9/
2. “Эксперты вскрыли многочисленные бреши в информационной безопасности российских банков”, CNews, Мобильная версия, 31.01.12, http://pda.cnews.ru/news/index.shtml?top/2012/01/31/475300
3. Дмитрий Кузнецов. ”ДБО под прицелом”, BIS Journal, 22.03.2012, http://www.ib-bank.ru/bis/p/138
4. Алексей Синцов. “Безопасность банк-клиентов”, PCIDSS.RU, 18.11.2010 http://www.pcidss.ru/articles/24.html
5. Thomas Tjstheim and Vebjrn Moen, Department of Informatics, University of Bergen, Norway. ”Vulnerabilities in Online Banks”, 08.09.2005, http://www.nowires.org/Papers-PDF/OnlineBanks.pdf
6. Kent Lawson. “Huge New HTTPS Vulnerability Found For Online Banking, Retail Stores”, 26.09.2011, https://www.privatewifi.com/online-paranoia-huge-new-https-vulnerability-found-for-online-banking-retail-stores/
7. Daniel V. Hoffman. ” Hacking Online Banking and Credit Card Transactions – And How to Prevent It”, 17.07.2008, http://idpnow.blogspot.com/2008/07/hacking-online-banking-and-credit-card.html
8. Geoff Williams. ” Banking Online? The Five Worst Mistakes You Can Make”. 04.01.2011, http://www.dailyfinance.com/2011/04/01/banking-online-the-five-worst-mistakes-you-can-make/
9. Валерий Васильев. ” Защищенность ДБО в фокусе банковских проблем”, PCWeek, 28.03.2011, http://www.pcweek.ru/security/article/detail.php?ID=129700
10. Daniel G. James. ” Statistical Analysis of Internet Security Threats”, http://www.infosecwriters.com/text_resources/pdf/Statistical_Analysis_Internet_DJames.pdf
11. Алексей Синцов. ”Безопасность банк-клиентов” http://www.dsec.ru/about/articles/bank_client_security/.
12. Build Security In. “Adapting Penetration Testing for Software Development Purposes”, 28.08.2008, https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/penetration/655-BSI.html
13. Stephan Arthur Zdancewic. ” PROGRAMMING LANGUAGES FOR INFORMATION SECURITY”, August 2002,  http://www.cis.upenn.edu/~stevez/papers/Zda02.pdf
14. Jaikumar Vijayan. “Duqu trojan built by 'old school' programmers, Kaspersky says”. ComputerWorld, 19.03.2012, http://www.computerworld.com/s/article/9225319/Duqu_trojan_built_by_old_school_programmers_Kaspersky_says?source=CTWNLE_nlt_pm_2012-03-19
15. Ксения Дементьева, Александр Игорев, “Ограбление в электронной версии”, 28.12.2011, http://bankir.ru/tehnologii/s/ograblenie-v-elektronnoi-versii-10001020/
16. Щит и Меч в системах ДБО. http://habrahabr.ru/post/134026/
17. Юридическая работа в кредитной организации. “Компоненты правового риска в условиях электронного банкинга.“  2/2011, http://www.reglament.net/bank/legal/2011_2_article_7.htm
18. Чигвинцев Александр. Комплексная защита систем дистанционного банковского обслуживания на базе решений RSA. http://www.cnews.ru/reviews/ppt/2011_09_14/5_Chigvincev.pdf
19. ” Эксперты вскрыли несметные бреши в информационной безопасности российских банков”. 26.03.2012. http://airsound.ru/port/safe/news_2012-02-01-04-37-58-824.html
20. “Щит и Меч в системах ДБО” http://habrahabr.ru/post/134026/
21. “Специалисты ESET и Group-IB обнаружили новую угрозу для систем ДБО” http://www.group-ib.ru/list/176-news/?view=article&id=183
22. Хакеры используют похищенные номера IMEI для банковских мошенничеств. МОСКВА, 13.03.2012, РИА Новости, http://digit.ru/technology/20120313/390027503.html