Проектируем, каким должен быть ваш центр мониторинга и реагирования: уровни аналитиков и линии реагирования, роли и процессы, состав источников событий и интеграций, целевые метрики. Проект, по которому SOC можно строить, а не набор купленных инструментов, которые не складываются в работающую службу.
SOC — это не SIEM. SIEM это инструмент, а SOC — люди, процессы и технологии вместе. Купить SIEM и не получить работающего мониторинга — типичная и дорогая ошибка. Проектирование модели помогает её избежать.
Частый сценарий: организация покупает SIEM, разворачивает его — и через полгода обнаруживает, что мониторинга как не было, так и нет. Система собирает события, но никто не разбирает срабатывания, роли не распределены, процессов реагирования нет, а половина важных источников не подключена.
Причина в том, что начали не с того конца. SOC — это в первую очередь модель: кто и что делает, как события превращаются в реакцию, какие процессы связывают людей и технологии. Инструменты обслуживают модель, а не наоборот. Если модели нет, дорогой SIEM превращается в дорогой генератор событий, которые никто не читает.
Проектирование SOC-модели отвечает на вопрос, каким должен быть ваш мониторинг, — до того, как вы вложитесь в его создание.
Модель описывает будущий центр мониторинга по нескольким измерениям.
Классически SOC строится по линиям: первая — обработка и первичная сортировка срабатываний, вторая — разбор инцидентов, третья — сложные расследования и проактивный поиск угроз. Мы определяем, какие линии нужны именно вам и как между ними распределяется работа.
Типовой набор: аналитик первой линии (дежурный мониторинг и первичный разбор), аналитик второй линии (расследование инцидентов), специалист по контенту и правилам корреляции, при необходимости — специалист по threat hunting и руководитель SOC. Роли не обязательно равны людям: в небольшом SOC один человек совмещает несколько, и это нормально, если зафиксировано, — важно, чтобы не осталось функций, за которые не отвечает никто.
Как срабатывание превращается в инцидент, как он эскалируется, кто принимает решения, как SOC взаимодействует с ИТ, с бизнесом, с внешними сторонами. Без процессов роли и инструменты не складываются в службу.
Что подключается к мониторингу: сеть и NGFW, серверы и контроллеры домена, рабочие станции, СЗИ (антивирус, EDR, DLP, песочница), приложения, облако. Определяем порядок подключения и отделяем события, действительно указывающие на угрозу, от шумных: подключить всё сразу — значит утопить аналитиков в потоке, в котором теряется важное.
Как измерять, что SOC работает: время обнаружения инцидента (MTTD), время реагирования (MTTR), охват источников, доля разобранных срабатываний, уровень ложных срабатываний. Метрики задают цель и позволяют потом оценить результат, а не верить, что «мониторинг есть».
SOC необязательно строить целиком у себя. Есть три модели, и выбор между ними определяет всё остальное.
Все линии, люди и инструменты — внутри организации. Максимальный контроль, но требует штата аналитиков, который сложно набрать и удержать, и постоянных вложений. Оправдан для крупных организаций с высокими требованиями.
Часть функций внутри, часть — на аутсорсинге. Например, первая линия и базовый мониторинг внешние, а расследование критичных инцидентов и контроль остаются у вас. Или наоборот. Гибкий баланс контроля и затрат.
Мониторинг и реагирование обеспечивает внешняя команда. Быстрый старт без набора штата, предсказуемые затраты. Подходит организациям, которым нужен результат, а не собственная служба.
Изучаем инфраструктуру, действующие средства защиты и мониторинга, процессы, штат, применимые требования регуляторов. Определяем, что защищаем и что считается инцидентом.
Определяем, какие угрозы и сценарии атак SOC должен обнаруживать. От этого зависит, что мониторить и какие источники подключать в первую очередь.
Обосновываем выбор между собственным, гибридным и аутсорсинговым SOC под ваши требования, бюджет и возможности по персоналу.
Проектируем уровни и линии, роли и ответственность, штатную потребность, процессы обнаружения, реагирования и эскалации.
Определяем состав источников, приоритеты подключения, требования к SIEM и смежным средствам, схему сбора и хранения событий, интеграции.
Проектируем взаимодействие SOC с ИТ, бизнесом, руководством, внешними сторонами и, при необходимости, с ГосСОПКА и НКЦКИ. Готовим регламенты реагирования.
Определяем целевые метрики и поэтапный план: с чего начать, как развивать, как измерять зрелость.
Цель: зачем нужен SOC — требования регулятора, реальные инциденты, и то и другое
Сведения об инфраструктуре: что мониторить, масштаб, площадки
Действующие средства защиты и мониторинга, если есть
Сведения о штате: кто сейчас занимается ИБ и мониторингом, есть ли аналитики
Применимые требования: КИИ, ГИС, отраслевые, необходимость подключения к ГосСОПКА
Ограничения: бюджет, сроки, возможности по найму персонала
Изучаем инфраструктуру, средства, процессы, штат и требования.
Определяем целевые сценарии, обосновываем модель SOC, согласуем подход.
Готовим модель: структуру, роли, процессы, архитектуру событий, интеграции, метрики, план развития.
Проходим проект с вами, при необходимости — с учётом требований регулятора. Дорабатываем.
Передаём проект и план. При необходимости переходим к построению SOC, внедрению SIEM или организации аутсорсингового мониторинга.
Обоснование выбора модели SOC: собственный, гибридный или аутсорсинговый
Целевые сценарии обнаружения — что SOC должен ловить
Структуру SOC: уровни, линии, роли, ответственность, штатную потребность
Процессы обнаружения, реагирования и эскалации
Архитектуру сбора и обработки событий, состав и приоритеты источников
Требования к SIEM и смежным средствам — как основу для выбора или оценки имеющегося
Схему интеграций и взаимодействия, включая ГосСОПКА, если нужно
Регламенты реагирования на инциденты
Целевые метрики работы SOC
Поэтапный план построения и развития с оценкой ресурсов
Зависят от масштаба инфраструктуры и глубины проекта. На объём влияет:
Масштаб: что мониторить, число площадок, объём инфраструктуры
Наличие действующих средств и процессов или проектирование с нуля
Выбираемая модель: своя, гибридная, аутсорсинговая
Необходимость подключения к ГосСОПКА и взаимодействия с НКЦКИ
Глубина: только модель или сразу с детальной архитектурой сбора событий
SIEM — инструмент, одна из составляющих SOC. Проектирование SOC определяет, каким должен быть весь мониторинг: люди, процессы и технологии вместе. Сначала модель, потом под неё — инструменты. Внедрить SIEM без модели можно, но работающего мониторинга это не даст.
Это типичная ситуация, и часто дело не в инструменте, а в отсутствии модели: нет процессов, ролей, разобранных источников. Спроектируем модель вокруг того, что есть, и покажем, чего не хватает, чтобы SIEM заработал как часть SOC.
Нет, и часто это невыгодно. Собственный SOC требует штата аналитиков, который трудно набрать и удержать. Для многих организаций разумнее гибрид или аутсорсинг. Выбор модели — часть проекта, и мы обосновываем его, а не навязываем самое дорогое.
Зависит от режима работы и объёма инфраструктуры. Круглосуточный мониторинг силами своего SOC требует заметного штата — только на дежурство первой линии в режиме 24/7 нужно несколько человек. Именно поэтому для многих организаций выгоднее гибрид или аутсорсинг: круглосуточную первую линию обеспечивает внешняя команда, а разбор критичных инцидентов и контроль остаются у вас. Штатную потребность под каждую модель мы рассчитываем в проекте.
Да. Для субъектов КИИ взаимодействие с ГосСОПКА и порядок реагирования — часть модели. Проектируем SOC с учётом этих требований и порядка взаимодействия с НКЦКИ.
И то, и другое. Проектирование — отдельный этап, но у нас есть внедрение SIEM, построение SOC и проактивный мониторинг. Можно заказать проект и реализовать его самостоятельно или передать нам.
Расскажите о задаче — строите мониторинг с нуля, оживляете купленный SIEM, выбираете между своим SOC и аутсорсингом или готовитесь к требованиям по КИИ. Проведём обследование и предложим модель и план.