Как банк «Санкт-Петербург» защищает базы данных

Руководство банка уделяет большое внимание информационной безопасности, совершенствование системы ведется непрерывно. За последние пару лет в банке количество ИБ-специалистов практически удвоилось – в 2015 году отдел информационной безопасности был преобразован в управление, где сейчас трудятся 22 человека. В состав управления входят: отдел аудита и совершенствования системы информационной безопасности, отдел внедрения, развития и сопровождения средств обеспечения ИБ, отдел мониторинга и реагирования на инциденты, а также аналитический отдел по противодействию современным угрозам.

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

В банке «Санкт-Петербург» используется несколько десятков ИТ-систем, но есть 5–7 основных, в которых хранится максимальное количество защищаемой информации. Прежде всего, это основная автоматизированная банковская система (АБС), сюда же относится CRM-система, система дистанционного банковского обслуживания, автоматизированная система по обеспечению процессинговых операций, а также система по управлению ценными бумагами. Кроме того, недавно в банке было внедрено общее хранилище данных.

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

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

Бизнесу важно, чтобы сотрудники использовали рабочее время максимально эффективно, а не ждали отклика системы на запросы. То есть возможности аудита почти всегда ограничены.

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

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

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

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

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

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

Система  класса DAM (Database Activity Monitoring) проводит мониторинг обращений к базам данных в режиме реального времени и выявляет подозрительные операции

Взять, к примеру, АБС ЦФТ – в ней десятки тысяч различных режимов и функциональных возможностей. Даже если закрыть 90% режимов доступа к информации, сотрудники, постоянно работающие с системой, смогут найти новые хитрые ходы. В итоге информацию, которую мы закрыли, все же удается получить через редко используемые режимы, которые не были учтены. С помощью «Гарды БД» мы выявляем и такие неучтенные режимы, и самих пользователей, которые их применили, а затем фиксируем эти уязвимости и закрываем их.

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

Конечно, не у всех пользователей одинаковые права доступа к банковской системе – есть типовые рабочие места для определенных групп сотрудников с конкретными функциями. В банке таких рабочих мест ограниченное количество. К примеру, если всего с АБС в банке работает 1500 человек, то типовых рабочих мест порядка 100 и периодически проводится их проверка – имеется ли возможность получения информации, которая не требуется сотрудникам для исполнения своих обязанностей. Банк развивается, появляются новые подразделения и функции рабочих мест быстро меняются, поэтому важно работать в обоих направлениях. Необходимо постоянно проверять актуальность профилей пользователей и выявлять излишние права доступа, а также вести мониторинг доступ пользователей к защищаемой информации.

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

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

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

Анатолий Скородумов

В ближайшие полгода планируем завершить внедрение системы внутреннего фрод-анализа, основным источником для которого являются данные из системы «Гарда БД»

Ситуации с фродом в нашем банке мы решаем не без помощи системы защиты баз данных «Гарда БД» . Мы позиционируем ее как элемент системы защиты от утечек информации. Такая система нужна, чтобы контролировать не только каналы утечки, но и каналы получения информации. Система класса DAM направлена на противодействие внутреннему фроду, помогает отследить противоправные действия сотрудников, потому как 99,9% обращений к базам данных банка – это внутренние пользователи, которые могут помимо своей основной работы вести некую неправомерную деятельность, связанную с несанкционированным получением информации.

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

Если система внешнего фрод-анализа у нас налажена и работает давно и эффективно – строятся профили работы клиентов и выявляются нетипичные для них действия, то о внутреннем фрод-анализе мы задумались совсем недавно. А это огромные возможности выявления злонамеренных действий сотрудников еще до инцидента. Раньше результаты мониторинга баз данных системы «Гарда БД» мы использовали только для расследования инцидентов в ретроспективе и онлайн-контроля доступа к наиболее критичной информации (например, счетам VIP-клиентов). Но ежедневно в систему поступает свыше 20 ГБ данных о работе с базами данных всех сотрудников, и появилось большое желание использовать эти данные более эффективно. В ближайшие полгода планируем завершить внедрение системы внутреннего фрод-анализа, основным источником для которого являются данные из системы «Гарда БД» .

Мы строим профили нормального поведения сотрудников (групп сотрудников с одинаковым функционалом) и выявляем отклонения от нормы, стараемся выявить несанкционированные действия пользователей. Мы хотим создать проактивную систему защиты, то есть выявлять мошенничество не тогда, когда появились финансовые потери, а когда пользователи начали выполнять несвойственные для него или его группы действия.