Кто ответит за «дыры»

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

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

Финансовый регулятор собирается навести порядок в этой области, для чего в рамках Технического комитета № 122 разрабатывает документ под названием «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем». Столь громоздкая словесная конструкция озаглавливает стандарт, призванный указать разработчикам четкие рамки, в которые им следует вписать свои процессы производства финансовых приложений.

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

Разработка технического задания

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

По словам директора департамента аудита защищенности компании Digital Security Алексея Тюрина, фатальные ошибки в ТЗ встречаются очень часто, даже при разработке важнейших финансовых систем: «В одном ТЗ для регистрации в системе требовалось предоставить в электронном виде ксерокопию паспорта. Таким образом, вне зависимости от корректности архитектуры и внедрения такой системы, она оставалась бы уязвимой. Другой пример: как-то мы анализировали внутренний сервис в банке, предоставляющий любому пользователю без аутентификации полный доступ к информации обо всех клиентах кредитной организации. То есть потенциально можно было изменить паспортные данные клиента, прийти в банк и забрать деньги по другому паспорту. О необходимости аутентификации на внутреннем техническом сервисе, который должен был использоваться как информационный каталог для других внутрибанковских систем, никто не подумал.

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

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

Проектирование

На этом этапе также часто встречаются некорректные архитектурные или технические решения. Даже грамотно написанное ТЗ не спасает от сомнительных решений при проектировании.

Как рассказал Александр Тюрин, «плохой пример с точки зрения архитектуры — автоматизированное рабочее место одного из отечественных вендоров АБС. Оператор банка для доступа в СУБД (система управления базой данных. — Прим. ред.) использует специальное программное обеспечение — автоматизированное рабочее место, АРМ. У оператора есть логин и пароль, вот только ограничения проявляются лишь визуально (в интерфейсе), фактически оператор подключается к СУБД с полными правами. Зашифрованный пароль от этой учетной записи (под которой происходит реальное подключение к СУБД) хранится в файле, а ключ зашит в само программное обеспечения АРМ. Но главная проблема в том, что ключ шифрования один для всего ПО компании, в том числе клиентского. Таким образом, любой оператор может расшифровать пароль от привилегированной учетной записи, подключиться в СУБД и проводить напрямую любые операции от имени любого клиента».

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

Создание и тестирование

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

Алексей Тюрин поделился опытом испытаний одной из отечественных систем ДБО: «Ломали ДБО изнутри. С боевой ДБО все было не очень плохо, но в тестовой системе нам удалось получить доступ к СУДБ, а уже из нее получили ряд учетных записей, которые подошли к боевой ДБО.

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

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

Приемка и внедрение

Как ни странно, вне зависимости от качества проекта, умений программистов и качества анализа кода, есть ряд уязвимостей, которые можно увидеть лишь на созданной системе.

«Для защиты от CSRF-атак (когда мы можем заставить браузер клиента отправить какой-то критичный запрос в ДБО) используют специальные токены (случайный набор символов) для каждого запроса. Как ни странно, мы видели несколько случаев, когда защита была внедрена в систему, но по каким-то причинам отключена (то есть, токены были, но не проверялись серверной стороной), — рассказал Алексей Тюрин. — Второй пример. Несколько раз мы находили административный интерфейс ДБО-системы банка, открытый в Интернет с учетными записями, где пароли были установлены по умолчанию. Фактически это залог полной компрометации и ДБО, и всех клиентов».

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

Эксплуатация

В ходе жизни системы в ней часто может что-то меняться — программный код, конфигурация, окружение. Наиболее частым случаем является обнаружение уязвимости в сторонних компонентах. В качестве примера можно взять недавно нашумевшую уязвимость Heartbleed в OpenSSL. Еще 6 апреля все ощущали себя в относительной безопасности, а уже 7-го узнали о Heartbleed, и поддержке многих тысяч серверов пришлось спешно латать огромную «дыру» в защите.

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

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

Сопровождение и модернизация

При каждом обновлении системы необходимо проходить все предыдущие этапы. Алексей Тюрин рассказал о примере из своей практики, связанной с разработчиками системы ДБО: «Приходим в банк, находим множество уязвимостей. Рассказываем, как их исправить. Разработчик по требованию банка вносит исправления. Мы проверяем — исправления корректны. Через какое-то время банк переходит на новую версию ДБО от того же разработчика, мы делаем проверку и опять находим уязвимости. Это бы не так шокировало, если бы в новой версии не было уязвимостей из старой версии. Разработчик позаботился лишь о том, чтобы «залатать» старую версию, но не о том, чтобы исключить старые «дыры» из новой версии, не говоря уже о других клиентах разработчика».

В соответствии с новым стандартом, банку после обнаружения уязвимостей необходимо написать новое техзадание (проект) к ДБО, в котором должны учитываться найденные уязвимости.

Регулятор и его намерения

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

Стандарт, заметим, адресован не разработчикам, а их заказчикам — банкам, которые, в свою очередь, обязаны требовать его соблюдения от своих подрядчиков. По всей видимости, эта схема должна быть вполне рабочей, ведь кто платит, тот и заказывает музыку. А тому, кто платит, совсем не захочется отвечать перед регулятором за незамеченные вовремя «дыры» в системе информационной безопасности. Если все пойдет, как задумано, через несколько лет изменения должны позитивно сказаться на безопасности наших с вами финансов. И, в определенной степени, на финансовой системе страны.

Михаил ДЬЯКОВ, Banki.ru