BIS Journal №3(50)2023

15 августа, 2023

«SOC добрый и не очень». Воспоминания о Магнитке — 2023

Как-то встретились мы с ребятами из разных сфер ИБ поговорить про Security Operation Centre… Именно так и хочется описать секцию под названием «SOC добрый и не очень», которую мне удалось провести в Магнитогорске в феврале.

Цель же этого обсуждения была в получении объёмного взгляда на процессы внутри SOCов, служащих для разных целей и функционирующих в разных компаниях. Но и ещё одно подспудное желание было — расставить все точки над i, показать, что один SOC нельзя полноценно заменить другим, а сравнения типа «этот подход лучше» неактуальны без указания целей и задач, для которых этот самый SOC и создаётся. На мой взгляд, получилось! 

 

АЛЕКСЕЙ МАРТЫНЦЕВ

Итак, начнём с промышленных SOC. Тут Алексей Мартынцев, директор департамента защиты информации и ИT-инфраструктуры «Норникеля», изрядно подготовился и показал несколько базовых тезисов:

  1. Подключение к внешнему SOC для промышленных компаний, без формирования гибридной модели, — плохая практика;
  2. SOC должен охватывать и корпоративный, и промышленный сегменты;
  3. При реализации процессов SOC должна быть проектная команда, которая охватывает не только специалистов по ИБ, но и технологов АСУТП.

С каждым тезисом можно быстро согласиться, но тогда и нового объёма получить не удастся. Забегая вперёд, надо сказать, что Владимир Дрюков, директор центра противодействия кибератакам Solar jsoc, и Алексей Новиков, директор экспертного центра безопасности Positive Technologies, как представители сервисного и экспертного центров также абсолютно не возражали. Ну, или мне так показалось. Пробежимся по основному смыслу самих тезисов, в которых видна логика, рождённая в продолжение долгого практического пути. 

 

ВЛАДИМИР ДРЮКОВ И АЛЕКСЕЙ НОВИКОВ

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

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

В последнем тезисе Алексей рассказывал про сам процесс внедрения всякого SOCовского, акцентируя внимание на том, что тут, как и во всяком важном действе, нужен основательный проектный подход. Особого внимания заслуживает интересная аналогия, взятая из практики программной разработки, — коллеги формируют институт Security Champion в неродной для ИБ среде — среде технологий и АСУТП. Искренне хочется посмотреть, к чему такая практика приведёт и какими результатами отзовётся. 

 

АРТЁМ КАЛАШНИКОВ

Артём Калашников, управляющий директор Центра информационной безопасности дочерних и зависимых обществ ГПБ, рассказывал про основные характерные особенности банковских SOC и про систему принятия решения о реализации SOC в ДЗО. Артём как один из организаторов FinCert насмотрелся многого и по-всякому, поэтому останавливался на простых, но очень показательных вещах. 

К примеру, про реализацию Antifraud: здесь реализация реактивного и самостоятельного процесса плотно завязана на другие активности SOC ровно потому, что чем больше контекста, тем точнее определение мошеннических действий. Да и управление схожими процессами, коллективом, который решает схожие задачи, логично доверить одному человеку. Так и получается, что Antifraud внутри или рядом с SOC для банков — это практически стандарт. 

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

 

ВЛАДИМИР ДРЮКОВ

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

В одном из тезисов, предложенных Владимиром, мы коснулись основных преимуществ MSSP-провайдера, а именно возможности быстрого ретроспективного поиска на основании вектора атаки, которая уже случилась в другом клиенте отрасли. Несомненный плюс, в отличие от конструкции с CERT, — скорость и качество реакции при наступлении описанных событий. Здесь те же аналитики, купировавшие или исследовавшие атаку ранее, могут, не упуская нюансов, провести оперативное изучение ситуации и у другого пострадавшего. CERT же даст на вход основные параметры для идентификации, не показывая (или не учитывая) логику движения атакующего в схожей сети. 

 

АЛЕКСЕЙ НОВИКОВ

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

 

В ЗАКЛЮЧЕНИЕ

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

  • В SOC включают (часто, но не всегда) схожие с областью ведения организационно и смыслово процессы. Для банков — это антифрод, для промышленности — сегмент АСУТП, МSSP-провайдер — сам по себе интегрированная всех со всеми сущность, экспертный центр синхронизирует в себе наработку контента для продуктовой линейки и реагирование внутри;
  • проектирование процессов SOC, формирование и оценка KPI для каждой отрасли, принятой организационной формы должно прорабатываться отдельно, так как большое количество отличий, выходящих из разности задач и целей, приводит к невозможности эффективно использовать стандартный подход — «как есть» — в каждом случае;
  • не все специалисты нужны в каждом SOC. Здесь речь шла про узкие (но востребованные) специализации, потребность в которых в основном сконцентрирована в MSSP-провайдерах и экспертных центрах. Базовый пример — malware analyst и специалист по сбору доказательств. Ситуации, в которых применение труда таких специалистов в SOC корпоративных компаний пока довольно редко. А вот для продавцов ИБ их ценность как создателей уникального, высокорелевантного бизнесу контента, напротив, довольно высока. 
Стать автором BIS Journal

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

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

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

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

01.03.2024
Банки будут строже следить за криптотранзакциями, связанными с дропперами
01.03.2024
Холода прошли, но голос берегите — скамеры усиленно собирают слепки
01.03.2024
Лишение банковской лицензии — это ещё не всё
01.03.2024
«Они подобны смартфонам на колёсах». В США проверят «умные» авто из Китая
01.03.2024
Набиуллина: Дважды «красные» клиенты будут исключаться из реестра
01.03.2024
Банк России усовершенствует платформу цифрового рубля
01.03.2024
Организации здравоохранения США стали жертвами массовых кибератак
29.02.2024
«ИнфоТеКС» — о проблемах стандартизации ИБ
29.02.2024
Почему нормативные акты выполняются формально
29.02.2024
Почему затянулся переход на российские решения

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

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

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