Три ноу-хау Александра Бабкина
Ситуационный центр (СЦ или SOC) Службы информационной безопасности Газпромбанка давно привлекает внимание и вызывает вопросы. С одной стороны, Служба ИБ Газпромбанка регулярно рассказывает о своем детище, внедряя в общественное сознание образ масштабного и зрелого SOC. С другой, закрадываются сомнения: ИТ-инфраструктура Газпромбанка не настолько велика, чтобы поддержать создание и развитие столь крупного Ситуационного центра. В стремлении разрешить эту загадку наш обозреватель Александр БОДРИК встретился с руководителем SOC Газпромбанка Александром БАБКИНЫМ.
ИСТОРИЯ, СТРУКТУРА И ИЗАДАЧИ СЦ
- У всякой инициативы есть свое начало. Когда и почему был создан СЦ ГПБ?
- До нашего создания в банке не было ни одной службы ИТ и ИБ мониторинга. И в один прекрасный понедельник в 2010 году, придя на работу, сотрудники банка обнаружили, что каналы интернета лежат вмертвую ещё с вечера пятницы. Лежит интернет – лежит всё – не работают терминалы, банкоматы, то есть все банковские процессы, подразумевающие внешнюю коммуникацию, встали.
Вот для предотвращения подобных инцидентов в рамках служб ИТ и ИБ были созданы дежурная смена и ситуационный центр соответственно. Спроектированная тогда мной архитектура СЦ лежит в его основе и по сей день.
- Минимизация ущерба от масштабных инцидентов требует координации многих подразделений. Как структурирована ваша служба информационной безопасности?
- Расскажу о подразделениях, что прямо задействованы в рамках текущей деятельности и развития СЦ. Например, проектно-методологический офис выступает агентом изменений ИБ-проектов Банка и представителем безопасности в ИТ-проектах Банка. Управление эксплуатации поддерживает меры, направленные на предотвращение инцидентов (FW, antispam и т.п.), а также выступает в качестве эксперта, когда СЦ расследует технические инциденты. Управление режима обеспечивает user awareness и проводит нетехнические расследования (все инциденты, связанные с людьми, например, нарушения политики ИБ инсайдерами).
- А как структурирован сам СЦ?
- СЦ состоит из двух отделов – отдела администрирования и отдела мониторинга инцидентов. Отдел администрирования предоставляет технический сервис – поддерживает необходимые для работы отдела мониторинга технические средства, по запросу отдела мониторинга инцидентов делает форензик.
Отдел мониторинга инцидентов реализует первую линию по всем инцидентам, а также вторую линию по техническим инцидентам. По нетехническим инцидентам второй линией выступает Управление режима.
- Отличительной чертой крупных инцидентов является пристальное внимание руководства к их разрешению. Кто курирует ситуационный центр в этом плане и службу ИБ в принципе?
- Департамент защиты информации курирует член правления, одновременно курирующий блоки корпоративных клиентов и проблемных активов. Отдельно отмечу, что у служб ИБ и ИТ разные кураторы, в этом плане мы полностью соответствуем требованиям ЦБ. Отдельно отмечу, что куратор службы ИБ реально вникает в вопросы и проблемы ИБ, так что служба ИБ имеет настоящего адвоката на уровне высшего руководства.
- Насколько я знаю, основной бизнес Газпромбанка корпоративный, а значит, Служба ИБ обладает высоким авторитетом, раз попала в такую компанию. Однако вы упомянули о мониторинге доступности силами СЦ. Это нетиповая ситуация, почему так?
- Действительно, наш ситуационный центр занимается в том числе и мониторингом доступности банковских ресурсов. Что кардинально отличается от практики, например, телекоммуникационной индустрии.
Производится мониторинг как инфраструктуры ИБ (VPN, FW, IPS), так и ИТ-инфраструктуры, за счет чего СЦ видит полную картину и может разобраться в проблеме даже лучше ИТ, у которых нет доступа к инфраструктуре ИБ. Наверное, можно сказать что ИБ тут выступает как контроль качества ИТ-сервисов, но с другой стороны, в ИБ и ИТ Банка инцидент воспринимается по-разному.
Для ИТ инцидент – это когда уже что-то сломалось и нужно срочно чинить (вред Банку уже нанесен). ИБ действует более проактивно, для нее инцидент - это когда произошло событие, которое может повлечь за собой вред для Банка. С точки зрения ИБ проактивная деятельность очень важна для минимизации влияния на бизнес Банка, что также в полной мере соответствует требованиям к управлению инцидентами из СТО БР ИББС.
- Развитые SOC часто идут по пути технического развития, например, форензики, реверс-инжиниринга и киберразведки. Что с этими практиками у вас?
- В 2016 году мы запустили проект по развития функции реверс-инжиниринга. Сейчас закупаем инструменты мирового класса, которые позволят нам оперативно и качественно снимать все нужные данные.
В части реверс-инжиниринга мы опираемся в первую очередь на нашего антивирусного вендора, а также запустили проект по внедрению «песочницы».
В сфере киберразведки СЦ выступает скорее как потребитель, уже используются бесплатные подписки и идет проработка проектной инициативы по приобретению и использованию платной подписки от одного из российских вендоров киберразведки.
Также в этом году у нас будет реализован проект независимой оценки зрелости СЦ, ведь мы уже 6 лет работаем – пора понять правильно ли мы работаем с точки зрения передового мирового опыта. Естественно, службы внутреннего контроля и аудита Банка регулярно помогают СЦ определить зоны потенциальных улучшений, но хотелось бы определить такие зоны именно с точки зрения передового мирового опыта, для чего уже запущен конкурс. По итогам оценки должен быть сформирован не просто набор отдельных рекомендаций, а фактически целевая операционная модель, включая ИТ-архитектуру, процессную модель, оценку и расчёты достаточной численности штата.
- Мы достаточно углубились в тему, но еще не коснулись индустриальной специфики. Входит ли в СЦ служба фрод-мониторинга?
- В службе фрод-мониторинга как самостоятельном подразделении у нас необходимости нет, так как удалось выстроить высокоэффективный процесс мониторинга фрода в дистанционных каналах обслуживания. Большую часть работы в нем закрывают технологии на базе прообраза искусственного интеллекта (нейронные сети).
По сравнению с основной деятельностью СЦ этот процесс фактически «безлюдный»: операторы выполняют подтверждение подозрительных транзакций (общение с клиентской базой – 30 тысяч ЮЛ), и периодически аналитики СЦ добавляют новые правила выявления фрода. Они у нас в этом плане универсалы: делают правила как для мониторинга ИБ, так и для фрод-мониторинга.
- Многие крупные корпорации при создании SOC выносят операционное ядро в регионы, надеясь снизить затраты и получить доступ к менее конкурентным, чем московский, рынкам труда. Как распределяются по регионам подразделения вашего СЦ?
- Исторически Банк развивался децентрализованно, каждый филиал во многом независим. Поэтому движение в сторону выноса операционных центров в регионы в Банке началось относительно недавно.
Служба ИБ предпочитает концентрировать экспертизу в первую очередь в Москве, так как здесь проще найти высококвалифицированных специалистов, ведь сюда со всей страны стекаются лучшие кадры.
ТЕХНОЛОГИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СЦ
- Газпромбанк известен на рынке высокой степенью автоматизации SOC. Какие ключевые системы Вы бы выделили?
- У нас и правда практически полный комплект систем – CMDB, сбор с наших и ИТ-источников, нормализация, агрегация и корреляция в события с признаками инцидентов (посредством SIEM от одного из лидеров рынка), обработка инцидентов в сервис-деске службы ИБ, Security BI («светофоры для менеджмента») – всю архитектуру возможно увидеть на Рисунке 1.
Рис.1. Структура построения SOC
- Остановимся на CMDB. Главной проблемой таких систем обычно является их постоянно устаревающее наполнение.
- Мы практикуем конфедеративный подход к CMDB. Вручную ведем свою инфраструктуру, интегрируемся с развивающимся CMDB-проектом ИТ. Если в ходе обработки инцидента мы обнаруживаем «темные пятна» (например, что инцидент не привязан ни к одному элементу нашей сервисно-ресурсной модели) или неактуальную информацию, мы стараемся устранить этот недостаток в своей CMDB.
Актуальная CMDB критически необходима для здравой оценки влияния инцидента на бизнес. В планах есть и развитие систем класса Asset Discovery, но это не самая приоритетная инициатива нашего портфеля проектов развития ИБ.
- Обсудим Ваш Service Desk. Он общий с ИТ или свой?
- У нас свой, так как у инцидентов поля прописаны в четком соответствии с классификатором инцидентов по требованию ЦБ, а у ИТ-шников все по-другому. К счастью у нас есть возможность иметь свою инфраструктуру автоматизации СЦ.
- Да, для служб ИБ, что сидят вместе с ИТ в одном SD, характерна проблема приоритетности задач по доработке SD для ИТ над задачами ИБ. Как Вы решаете проблему контроля регионов, учитывая слабые каналы связи в традиционных нефтегазовых провинциях?
- Мы ставим в регионах экспресс-редакцию нашего SIEM и пересылаем в центр не сырые, а отфильтрованные данные.
ПРОЦЕССЫ РАБОТЫ СЦ
- Как распределяются полномочия в СЦ в рамках мониторинга угроз?
- В СЦ существует четыре роли в рамках процесса реагирования и расследований инцидентов – оператор, аналитик, расследователь и администратор.
Оператор производит мониторинг введенных в работу кейсов, подтверждает и классифицирует инцидент, расследует инцидент -реагирует согласно инструкциям (выступает в роли расследователя), либо эскалирует руководителю SOC (мне).
Дежурный и производит подключение систем к ситуационному центру, уже выступая в роли администратора.
Этот же дежурный выступает в роли аналитика – составляет правила для детектирования угроз. В итоге центр иногда выступает агентом изменений, так сказать, «передовиком производства», везде говоря «А еще вот это надо улучшить».
Например, пошли APT-атаки. Мы стали получать о них информацию из различных источников – от коллег по межбанку, из рассылки FinCERT, и поняли, что, во-первых, типовое начало такой атаки — это электронное письмо, во-вторых, на рынке существуют решения по анализу таких писем и их вложений («песочницы»). На данный момент проект по «песочнице» уже в активной фазе – внедряем.
Таким образом, у нас не существует типовой многоуровневой модели SOC («пирамида»), у нас скорее кольцо.
- То есть у Вас выработана своя ролевая модель работы?
- Это действительно модель, причем, мы стараемся придерживаться этой модели уже шесть лет. И пока никто меня не смог разубедить в ее неправильности. Мы не всегда успеваем ее актуализировать, потому что я по каждому правилу требую паспорт, например. В паспорте должно быть прописано: автор, логика этого технического правила, меры реагирования, меры оповещения руководства.
- Да, у Вас очень высокий уровень формализации процессов.
- Когда в SIEM валится 4000 событий в секунду, возникает вопрос: как аналитику начать с этими событиями работать. И тут я выделяю два подхода.
Подход «снизу-вверх», как у трейдеров – технический анализ. Раз у нас много данных, их возможно визуализировать на графиках. Раз есть графики, то у любого из них есть baselines – нормальные и аномальные состояния.
Например, все сотрудники используют систему Х с 10 до 18 часов, а некий сотрудник с 8 до 9. Или мы видим, что типовой спад объема интернет-трафика по окончании рабочего дня не происходит. В таких случаях регистрируются события с признаками инцидента, и оператор производит проверку.
Однако, чтобы первоначально выявить такое нетипичное поведение дежурному надо собрать данные, построить графики, посчитать отклонения и т.д. Тут нужен очень серьёзный мат. аппарат.
Подход «сверху-вниз» (тоже как у трейдеров – фундаментальный анализ. – прим.). Исходя из внутренней нормативной базы (политики безопасности, модель угроз), организация планирует обеспечивать конфиденциальность информации. Какие могут быть угрозы конфиденциальности? Например, нарушение конфиденциальности учетной записи. Банальный брутфорс.
Проводим самопроверку – нормативные основания есть, угроза такая есть, есть ли в подлежащих мониторингу системах данные об успешных и неуспешных попытках входа? Есть, - можем описывать и запускать в работу.
- Сейчас на Западе очень популярна тема обмена информацией (data sharing). Обмениваетесь ли Вы с кем-то?
- У нас налажено хорошее рабочее взаимодействие с FinCERT. Я считаю создание такой структуры очень правильным шагом, и она уже принесла много пользы банковскому сектору.
Так же в этом году очень актуальна тема ГосСопки. Мы сейчас в процессе подписания соглашения о взаимодействии с 8-ым центром ФСБ, но пока процесс идет туго. Тут два момента. Во-первых, существует дефицит правового обеспечения ГосСопки. Соответствующий законопроект уже давно лежит в ГосДуме без движения. Во-вторых, ГосСопка де факто находится на стадии планирования проекта.
Тем не менее мы ожидаем существенных результатов от будущего взаимодействия в рамках ГосСопки. Например, корпорации могут быть предупреждены о готовящихся атаках на их системы (situational awareness) и снизить на определенное время чувствительность своих сенсоров.
ТРИ НОУ-ХАУ
- Мы обсудили много технических моментов, давайте поговорим о кадрах. Где СЦ берет людей, как развивает, мотивирует и удерживает?
- Когда мы набирали людей, было поставлено принципиальное условие – исключительно с высшим образованием в сфере защиты информации. Мы не переучиваем людей с хелпдеск, мы сразу берем профессионалов в сфере безопасности.
В части обучения. Банк регулярно выделяет средства на обучение в России и мире. Зарубежное обучение производится в том случае, если нужных курсов в России нет, а так часто бывает по тематике SOC.
Естественно, инвестиции в обучение плюс разнообразная работа (совмещение ролей) повышают стоимость наших сотрудников. Банк это понимает, и реализует целую программу мероприятий для мотивации специалистов. Во-первых, денежная мотивация – индексация, увеличение по мере повышения производительности, дополнительная оплата ночных дежурств (как велит ТК), дополнительная оплата в случае двух смен за 4 дня (по умолчанию график сутки / трое, но молодые специалисты готовы работать и через сутки).
Во-вторых, мотивация гибким графиком работы. Специалист имеет много свободного времени и может себе позволить то, что не могут люди с 8х5.
В-третьих, мотивация разнообразием работы, в частности, нашим распределением ролей. Если человек сидит в смене, т.е. на сутки, то мы стараемся подключить его на первую линию (разбор инцидентов). Если же он, предположим, сегодня отоспался, ушел в 8 часов утра, завтра выходит в день (только в день), то завтра он станет аналитиком, будет делать правила и анализировать повторяющиеся инциденты.
- Значит, у вас больше человекочасов, чем должно быть при стандартном расписании? То есть человек работает больше 40 часов в неделю? Это фактически некое ноу-хау по повышению отдачи от людей!
- Специалисты молодые - глаза горят, поэтому они говорят: хочу, хочу. А – им это интересно, Б – банк за это ещё и деньги платит. Почему бы не выйти, не повысить свою компетенцию, да еще и деньги получить.
Но если уж говорить о ноу-хау, то это в первую очередь – ТОСы.
- А что такое ТОСы?
- В свое время мы увязали понятия СТО БР ИББС с той визуализацией, которая у нас есть (показывает Рис. 2 – прим.). В стандарте Банка России сказано, что кредитная организация и служба информационной безопасности обязана обеспечивать информационную безопасность на каждом уровне. Вот эти ТОСы – их ровно 7. Они очень сильно повторяют семиуровневую модель ОСИ. Один в один, практически.
Рис. 2. Сбор информации об объектах мониторинга.
- То есть это некий security framework?
- В целом да, мы используем модель ТОСов для планирования и разработки правил детектирования инцидентов. Фактически это таблица, как мы ее называем, Менделеева по ИБ. Как и в таблице Менделеева, здесь пока много незакрытых элементов.
Например, когда аналитик создает правило детектирования (той же DDOS атаки), он должен это правило вписать в определенную клеточку. Ее местоположение зависит от того, какого свойства информация была нарушена и какого уровня объект «защищает» это правило.
У каждого уровня ТОСа есть направление защиты: конфиденциальности, целостности и доступности. Когда мы говорим об инциденте, связанном с DDOS атакой, это означает нарушение доступности сетевых сервисов. То есть второй-третий уровень. Это точно не физический уровень и точно не шестой-седьмой…
Это конкретно сбой на сетевом уровне, причем, направленный на нарушение доступности, а не конфиденциальности или целостности. И получается матрица: по вертикали ТОСы, по горизонтали КЦД (конфиденциальность, целостность, доступность). Когда создается правило, то на пересечении определенного уровня и определенного столбца вписывается цифра: сколько правил для этого создано.
Большинство полей пустые. Почему пустые? Потому что это задача на «подумать», какие должны быть правила, чтобы выявлять угрозу целостности, конфиденциальности, доступности на том или ином ключе.
ТОСы мы используем даже при общении с руководством. В частности, представляя результаты работы куратору.
Мы столкнулись с тем, что создать правило, которое выявляло бы инциденты с нарушением целостности (столбец «целостность») – это самое сложное. Очень многие вещи нельзя выявить только из-за того, что системы (контролируемые системы) не обладают достаточно детальным журналированием
(legacy, давняя проблема ИБ во многих отраслях - прим. автора).
- Да, действительно, ноу-хау как минимум в России, чем-то похоже на американский фрейм-ворк VERIS. И напоследок, что бы вы выделили среди направлений развития СЦ?
- Сейчас мы прорабатываем возможность мониторинга доступности и эффективности бизнес-процессов.
Согласно требованиям ЦБ служба ИБ должна обеспечить безопасность банковских технологических процессов. Некий абстракт. Когда мы говорим про банковские технологические процессы – это практически формализованный технологический процесс. Входные данные, выходные, функции преобразования...
Второй момент. На дворе 21 век, любые технологические процессы оцифрованы.
Таким образом у нас есть возможность декомпозировать бизнес-процесс на элементы (с помощью сервисно-ресурсной модели) – сервер приложений, СУБД, ОС, инфраструктура… и используя матмодель (например, затухающего коэффициэнта), вывести для бизнеса монитор (независимый от ИТ).
Если представитель ИТ по телефону сообщит «все ОК» - по монитору можно будет понять, так ли это.
Например, сервис SWIFT. Сервис основан на 4 серверах (кластер) – 2 СУБД и 2 appservers. Но, если сервис функционирует как задумано, то бизнесу не важно сколько серверов.
Мы попытались в процесс мониторинга доступности сервисов вовлечь бизнес и объяснить, что бизнес сможет понимать правильно ли все функционирует, смотря на всего лишь один понятный индикатор. Неважно, что за этим индикатором стоит большая сервисно-ресурсная модель, это уже наши проблемы.
Теперь бизнес-языком можно с ними общаться: «Ребята, у вас система простаивает или наоборот?»
У нас была ситуация, когда все системы штатно работают, а сам процесс начинает тормозить (KPI не выполняются). Что ж такое? IT-шники работают, все корректно, а где-то тормозит, как они говорят, ванночки не переливаются. Выясняется, половина одного отдела на больничном – слегли с гриппом. Вот там-то нагрузка и разошлась по «выжившим». Все системы работают, но переливание ванночек стало подтормаживать.
А вот выход из строя одного из серверов в кластере бизнесу, наоборот, может оказаться не интересен – сервис-то работает исправно.
ОТ РЕДАКЦИИ
Очевидно, что Ситуационный центр Газпромбанка - один из наиболее развитых СЦ в стране, и благодаря ряду ноу-хау (достойных быть внесенными в своды лучших практик) ухитряется закрывать относительно небольшими силами многотриллионные активы банка ТОП-5 страны. Но в то же время существуют десятки и сотни банков, которые не могут себе позволить даже бледного подобия практик Газпромбанка. Может быть, Банку России стоит развивать FinCERT не только в сторону координации управления инцидентами, киберразведки и других привычных аспектов модели CERT. Например, продумать модель Community SOC, когда Банк России или уполномоченный им банк станет центром экспертизы по мониторингу кибератак, и все, кто захочет подключиться, например, к БЭСП, будут обязаны заказать такой сервис для всей своей сети или ее сегмента.
Ровно по такой модели сегодня работают крупнейшие глобальные корпорации, к централизованным информационным системам которых не получить доступ, если не соответствовать внутренним ИБ-стандартам, не заказывать внутренний сервис SOC.
- Стоимость медиауслуг (открыть PDF) -
