SOC 2.0. Аппетит приходит во время еды
Пока ИБ-сообщество продолжает споры о том, что такое SOC, компании и государственные учреждения вовсю ведут стройку и эксплуатируют эти центры. То, что получается на практике, удивительно редко соответствует каноничному представлению о SOC. Кто-то не может сдвинуться с точки SOC v0.1, но если уж взялся строить SOC, то и на версии 1.0 остановиться сложно. Хочется больше функций, больше возможностей. Рассмотрим, какие метаморфозы претерпевает SOC в российских реалиях, и какие подводные камни встречаются на пути к SOC 2.0.
ФИЗИЧЕСКАЯ БЕЗОПАСНОСТЬ
Самый популярный кейс, с которого зачастую начинается интеграция SOC в физическую и инженерно-техническую безопасность, - это учет прохода сотрудников через турникеты, чтобы отслеживать логины на АРМ пользователей, которые физически отсутствуют в здании. Для любой популярной SIEM-системы не сложно сделать коннектор для СКУД и создать соответствующее правило. Но многие хотят двинуться дальше и создают на базе SOC центр мониторинга инженерно-технической защиты. SIEM создает информационную шину, которая опутывает все подразделения компании и позволяет вывести сигналы от систем защиты в единый центр.
Но тут же возникают и проблемы. В мире физической безопасности существует еще больший зоопарк средств защиты, чем в ИБ. В одной компании может использоваться по десятку моделей СКУД, сигнализаций, противопожарных систем. Создавать и поддерживать такое число нестандартных коннекторов для SIEM очень неудобно. Кроме того, системы генерируют огромные объемы информации, пожирающие каналы связи и недешёвые лицензии на EPS в SIEM.
А с частью информации (например, видео) SIEM вообще работать не умеют. Тут на помощь приходят системы класса PSIM (physical security information management). У них есть коннекторы к сотням моделей устройств физической безопасности, несложная, по меркам SIEM, система правил позволяет пересылать в SIEM только важную информацию, а видеоданные можно передавать в SIEM как ссылку на интерфейс PSIM. Или вообще выстроить на PSIM альтернативную сеть сбора данных и коррелировать информацию с SIEM уже в центре (вариант для не самых больших компаний).
Сама необходимость корреляции именно сырых событий между ИТ и системами физической безопасности должна быть здраво оценена перед строительством системы. Практика показывает, что она нужна не так уж и часто. Проблема возникает также с тем, что у инцидентов ИБ и инцидентов физической и инженерно-технической безопасности разные алгоритмы обработки, свойства, классификация и т.п. Да и просто в компаниях ими обычно занимаются совершенно разные люди, свести которых под крышей одного центра реагирования бывает совсем непросто.
БОРЬБА С МОШЕННИЧЕСТВОМ
Данные, собираемые SOC, могут использоваться, в том числе и для анализа поведения пользователей и обнаружения фактов мошенничества (например, воровство базы клиентов). А отдельные системы борьбы с мошенничеством не уступают по сложности корреляционных и обнаруживающих механизмов SIEM и IPS. Например, в случае контроля фрода в каналах ДБО и кросс-канальных схем мошенничества в банковской сфере.
Направления ИБ и антифрода взаимно дополняют друг друга, но в большем выигрыше определенно антифрод, потому что поле его анализа существенно расширяется за счет традиционных источников данных SIEM-систем. Физическое совмещение дежурных смен по направлениям натыкается на проблемы ограничения доступа и разделения обязанностей (SoD). Корпоративные политики могут сделать это и вовсе невозможным. Различаются и процессы обработки инцидентов. На уровне техники проблем меньше и в базовом варианте антифрод может использовать ИБ-системы SOC просто как ценный источник информации для обнаружения и расследования мошеннических действий, ничего не предоставляя SOC.
СТРАТЕГИЧЕСКИЙ УРОВЕНЬ
В рамках работы с инцидентами ИБ накапливается ценная статистика по реальным угрозам, идет анализ внешних источников, оценивается эффективность защитных мер. Логично использовать эти данные при планировании развития ИБ в компании. Но необходимо понимать, что это дополнительное преимущество, а не основная задача.
SOC – мощный инструмент и большая стройка. Его заказчиком в компании обычно является кто-то из крупных руководителей. Он формирует основные требования к системе. Сам термин SOC говорит о том, что он должен создаваться в первую очередь для решения оперативных задач по управлению инцидентами. Однако, обсуждать блок-схемы обработки событий безопасности скучно, поэтому руководство переключается на более глобальные задачи. Например, «SOC должен в автоматическом режиме анализировать геополитическую обстановку в мире и прогнозировать будущие угрозы ИБ». Задача строителей SOC состоит в том, чтобы не только «приземлить» эти требования до чего-то реализуемого и реально полезного, но и выстроить основу SОС, сконцентрированную на рутинной обработке инцидентов. Иначе этот голем на глиняных ногах рухнет под своим весом, так и не сделав первого шага.
ЭКСПЛУАТАЦИЯ СРЕДСТВ ЗАЩИТЫ
Может показаться, что смешение инцидент менеджмента и администрирования СЗИ - это вынужденная мера небольших организаций с ограниченным штатом. О SOC здесь, понятно, речи не идет. На деле даже в крупных организациях эти функции часто смешивают. Где-то это политическое решение, где-то реальное непонимание недостатков такого подхода. В любом случае, нарушение разграничения полномочий, отвлечение сотрудников 1-й и 2-й линии SOC от основных обязанностей, конфликт интересов на уровне руководства SOC - неадекватная плата за плюсы такой интеграции. Если сдвинуть ситуацию невозможно (например, не удается пересмотреть организационно-штатную структуру), приходится строить искусственные "стены" внутри SOC, разделяя обязанности. Половина SOC - это настоящий SOC, а вторая половина только так называется.
***
SOC должен иметь стратегический план развития. Выход за пределы классических ограничений - хорошая его часть. Как и для человека, так и для SOC, чтобы достичь больших целей, надо их сформулировать и планомерно к ним двигаться. Однако, многие российские SOC имеют уровень зрелости базовых процессов управления ИБ в районе единицы по классической пятибалльной шкале модели зрелости (Capability Maturity Model, CMM). Думаю, сначала надо сконцентрировать большую часть ресурсов на этой проблеме. На прочном фундаменте базовых процессов и технологий можно построить систему, способную на гораздо большее, чем рутинная обработка типовых инцидентов, построить тот самый SOC 2.0.
.png)