Отсутствие антивирусов, политик безопасности и элементарных мер обеспечения информационной безопасности (таких, к примеру, как «смена предустановленного производителем пароля для входа в BIOS банкомата») — действительно неприемлемая ситуация для безопасности банка. Однако ограничиваться только этими мерами нельзя: векторов атак гораздо больше.

Автор: Рами Мулейс, менеджер по продвижению продуктов PT Application Inspector и Approof, Positive Technologies

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

Об уязвимостях ДБО и интересе киберпреступников

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

Такой сдвиг в сторону CNP-транзакций понятен: мошеннику интереснее красть деньги через интернет, тем более что системы ДБО в большинстве своем все еще уязвимы и эти уязвимости можно эксплуатировать удаленно, вне зоны прямого действия служб безопасности.

Уязвимость ДБО подтверждается и нашей собственной статистикой: лишь в 10% исследованных экспертами Positive Technologies систем ДБО не было обнаружено критически опасных уязвимостей (при этом в них были выявлены как минимум уязвимости средней степени риска).

В половине исследованных систем ДБО (55%) нарушитель может получить контроль над СУБД и доступ к банковской тайне; в каждой четвертой системе — украсть денежные средства банка, обладая пользовательским доступом к клиентскому приложению, еще в 5% случаев — сделать то же без каких-либо привилегий. Нарушитель может полностью вывести из строя систему ДБО, используя контроль над ОС сервера и другие уязвимости (40% систем).

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

Защита приложений как основа безопасности

Новые методы взлома ДБО появляются едва ли не ежедневно, поэтому использование средств защиты приложений — такая же необходимость, как и наличие антивируса на рабочих станциях банка. Это находит отражение и в требованиях к безопасности, которые выдвигает индустрия и регуляторы. Например, стандарт безопасности платежных карт PCI DSS в новой версии 3.0 требует обеспечивать защищенность приложений, проводя периодический анализ их защищенности. Его необходимо проводить не только на этапах разработки и перед вводом приложения в эксплуатацию, но и во время его активного использования клиентами банка на регулярной основе (например, дважды в год).

Второй момент, на который обращают внимание регуляторы (и стандарт PCI DSS 3.0 в частности),— использование средств превентивной защиты: специализированных межсетевых экранов, работающих на уровне приложений (Web Application Firewall; WAF). Не следует путать WAF с обычным сетевым экраном: ФСТЭК России, например, явно вводит различные типы межсетевых экранов, в том числе отдельный тип для экранов, защищающих приложения. К такому типу решений относится PT Application Firewall, сертифицированный ФСТЭК и второй год подряд попадающий в число визионеров квадрата Gartner. PT Application Firewall использует в том числе и технологии «машинного обучения», позволяющие автоматически строить типовую модель поведения пользователей приложения и отслеживать все отклонения от нее, отлавливая все аномальные запросы к ДБО (от ботов до продвинутых мошенников).

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

Запустить приложение быстро или безопасно?

Не так давно, проводя анализ безопасности одной из платформ веб-приложений, которое широко используется в сфере e-commerce, наши эксперты выявили в коде скрытое условие, при срабатывании которого обычный пользователь получал права администратора приложения. Оно заключалось в том, что хэш пароля ( посчитанный с помощью слабого алгоритма md5) должен соответствовать определенному значению. То есть в код был неявно зашит администраторский пароль, дававший доступ ко всей клиентской базе. Разработчик же отметил, что это специальный «бэкдор», позволяющий оптимизировать процесс техподдержки клиентов. То есть эта закладка преследовала вполне благородные цели (если, конечно, верить в благие намерения разработчика). Тем не менее эта закладка могла позволить злоумышленнику (имеющему достаточное время и желание для расшифровки значения) получить полный контроль над любым приложением на базе этой платформы. Что делать в этом случае?

По большому счету подходов также может быть два. Во-первых, как уже отмечалось выше, проводить постоянные аудиты перед каждым релизом приложения. Во-вторых — внедрить процессы безопасной разработки (SSDL — Secure Software Development Lifecycle). Разница между ними заключается в том числе в стоимости. Постоянные аудиты, безусловно надежны, но сопряжены с дополнительными расходами на ручной труд высококвалифицированных исполнителей и требуют времени для последующего исправления разработчиком найденных уязвимостей.

Второй подход — внедрение процессов безопасной разработки, при которых сами разработчики участвуют в процессе поиска и исправления уязвимостей на этапе создания приложения, достаточно давно и активно продвигают Microsoft, Cisco и другие ИТ-гиганты. В этом году к этой истории подключилось и наше государство: разработан ГОСТ Р 56939-2016 «Защита информации. Безопасная разработка программного обеспечения. Общие положения». В качестве основы для внедрения процессов обеспечения информационной безопасности систем ДБО на всех стадиях жизненного цикла могут быть использованы выпущенные в 2014 году рекомендации Банка России — РС БР ИББС-2.6-2014.

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

Поэтому эффективным подходом в этом случае может стать обязательное проведение инструментального аудита на этапе приемки приложения. Для чего стоит использовать решения по анализу кода, максимально автоматизированные и заточенные на поиск уязвимостей с минимальным «шумом». Например, PT Application Inspector автоматически проверяет уязвимости приложения, использует несколько методов анализа, не ограничиваясь статическим. Это позволяет в разы понизить ложные срабатывания и сократить время аудита. А самое главное, он генерирует эксплойты (коды для взлома). Благодаря чему на этапе приемки приложения можно поставить его разработчиков перед фактом выявления уязвимостей и даже продемонстрировать тестовый взлом. А также получить автоматические сигнатуры для экрана уровня приложений, что позволит сразу блокировать атаки и нелегитимные запросы, использующие выявленную уязвимость. Таким образом, связка из двух решений (анализатор кода и межсетевой экран) позволит выкатывать релизы приложений, не дожидаясь, когда разработчики исправят найденные уязвимости, с одной стороны. И сохранить баланс безопасности с другой.

***

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