BIS Journal №4(19)/2015

5 ноября, 2015

Опыт создания SOC в крупном российском банке

Главными причинами создания в АО «Газпромбанк» Ситуационного центра по информационной безопасности (Security Operation Center — SOC) послужило увеличение масштабных, в том числе регионально распределённых банковских бизнес-процессов и связанный с этим рост инцидентов информационной безопасности.


ПРЕДПОСЫЛКИ И СТАРТОВЫЕ УСЛОВИЯ

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

На момент создания в банке SOC в 2010 году парк используемых программно-аппаратных средств составлял свыше 6 000 автоматизированных рабочих мест, свыше 1 500 серверов, 600 объектов активного оборудования, более 500 отдельных автоматизированных систем и приложений. IT-ландшафт Газпромбанка включал разнообразные операционные системы, в т. ч. Novell, MicroSoft Windows, Red Hat/SUSE Linux, HP-UX, Solaris, AIX, OS/400, ОС QNX, SecurePlatform и пр., а также многочисленные системы управления базами данных от Oracle, Sybase, Microsoft SQL, Pervasive SQL, DB2, MySQL, Paradox, Interbase и пр.

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

КОНЦЕПЦИЯ И СТРУКТУРА ЦЕНТРА

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

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

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

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

Сотрудниками, ответственными за обеспечение защиты информации в Газпромбанке, была разработана концепция реализации SOC, включающая следующие основные блоки:
  • перечень объектов мониторинга;
  • перечень средства и инструментов осуществления мониторинга;
  • перечень средств сбора и агрегирования данных;
  • описание событий с признаками инцидентов ИБ;
  • описание системы визуализации данных;
  • инструкции для операторов по выявлению и реагированию.
  • инструкции по процедуре проведения расследований инцидентов.
Иллюстрация 1. Принципиальная структура банковского SOC
 


ТЕХНОЛОГИИ РАБОТЫ С ПОДСИСТЕМАМИ

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

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

Иллюстрация 2. Концепция реализации SOC. Принцип «светофора»

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

ВИЗУАЛИЗАЦИЯ ПОЛУЧАЕМЫХ ДАННЫХ

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

Красный цвет характеризует выявленные сбой, нарушение, мошенничество, утечку и т. п.

Жёлтый цвет обозначает предпосылку к инциденту или возникновение событий, соответствующих известным сценариям инцидентов без их завершения (т. е. без нанесения какого-либо ущерба объекту мониторинга) по состоянию на момент появления сигнала. 

Зелёный цвет демонстрирует нормальный режим работы всех объектов мониторинга и показывает соответствие контролируемых параметров установленным границам штатного режима работы.

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

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

Возможность руководства подразделения оперативно оценивать состояние инцидента информационной безопасности предоставляется благодаря использованию технологии Drill Down — обработки данных по накопительным уровням в виде «пирамиды». Благодаря этому методу руководитель в режиме реального времени может видеть итоговые результаты работы Ситуационного центра в целом. Переходя на более низкие уровни, можно детализировать отчётность по разным параметрам интересующих инцидентов информационной безопасности.

ИНТЕРФЕЙС ФОРМЫ РАССЛЕДОВАНИЯ ИНЦИДЕНТОВ

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

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

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

К особым атрибутам инцидента информационной безопасности относятся:
  • характер воздействия (например, попытка получения несанкционированного доступа);
  • масштаб (какие бизнес-процессы, подразделения оказываются затронуты);
  • возможности наступления негативных последствий и их тип (нарушение конфиденциальности и т. д.).

Устранение условий, вызвавших инцидент информационной безопасности, включает комплекс мероприятий, предполагающий:
  • подготовку аналитических записок по наиболее критичным инцидентам;
  • формирование регулярных отчётов по состоянию ИБ;
  • проведение рабочих встреч с представителями IT-блока, посвящённые устранению причин инцидентов ИБ;
  • проведение рабочих встреч с представителями бизнес-подразделений, в т.ч. согласование значимых мероприятий, направленных на обеспечение непрерывности технологических бизнес-процессов.

ИНТЕРФЕЙС КОНТРОЛЯ IT-РЕСУРСОВ В ПРОЦЕССЕ ПРЕДОТВРАЩЕНИЯ ИНЦИДЕНТОВ

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

Такой контроль является надёжным подспорьем для совершенствования внутренней нормативной базы банка в сфере обеспечения информационной безопасности. Разработан и утверждён следующий комплекс корпоративных нормативных документов:
  • политика информационной безопасности;
  • частная политика управления инцидентами ИБ;
  • регламент взаимодействия в рамках мониторинга информационных программно-технических систем;
  • методические рекомендации по описанию инцидентов ИБ;
  • классификатор инцидентов на основе СТО БР ИББС;
  • регламент сбора информации об инцидентах ИБ неавтоматизированными средствами.
  • иные документы, содержащие отдельные пункты, относящиеся к SOC.

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

Иллюстрация 3. Интерфейс визуализации работы SOC

В результате создания SOC в Газпромбанке к 1 сентября 2015  года общее количество контролируемых автоматизированных систем превысило 200. Были настроены десятки средств защиты информации, являющихся источником для SOC. Более 500 правил выявления инцидентов информационной безопасности успешно функционируют в модуле корреляции атомарных событий. Настроено более 30 утверждённых и контролируемых профилей защиты для отдельных компонентов IT-ландшафта банка.
 

Ежедневно выявляется порядка 50 инцидентов ИБ, в том числе около 10 уникальных. Всего только за первый год работы SOC на основе 127 млрд атомарных событий было выявлено и обработано свыше 18 000 событий с признаками инцидентов информационной безопасности. Из них получено подтверждение более чем в 8500 случаев, включая 2500 уникальных «родительских» инцидентов и порядка 6000 «дочерних» – т. е. произошедших в результате выявленных ранее инцидентов.


 
Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных