«SOC добрый и не очень». Воспоминания о Магнитке — 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 корпоративных компаний пока довольно редко. А вот для продавцов ИБ их ценность как создателей уникального, высокорелевантного бизнесу контента, напротив, довольно высока.