BIS Journal №4(23)/2016

20 декабря, 2016

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.
Стать автором BIS Journal

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

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

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

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

28.05.2024
Хакеры из Head Mare утверждают, что «положили» системы СДЭК
28.05.2024
СПЧ и МВД — о масштабах потерь от действий скамеров
28.05.2024
Узбекистан откалывается от «Мира»?
28.05.2024
«Росатом»: Регуляторика ИИ с чёткой логикой сегодня отсутствует
28.05.2024
В ходе дискуссии может появиться многогранная программа ИИ
28.05.2024
Существует неопределённость в толковании и применении правовых норм использования ИИ
28.05.2024
«РУССОФТ»: В ИИ-гонке выигрывает не тот, кто придумал, а тот, кто внедрил
28.05.2024
Хакеры грозят опубликовать ПДн клиентов аукционного дома Christie’s
27.05.2024
НКЦКИ запустит сервис бесплатной «скорой помощи» пострадавшим от киберинцидентов
27.05.2024
Банкиры спасли от скамеров два триллиона рублей своих клиентов

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

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

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