SOC: центр мониторинга и реагирования на инциденты информационной безопасности

Из чего складывается SOC

SOC объединяет:

• специалистов по мониторингу и расследованию;
• процессов выявления и обработки инцидентов;
• технических платформ и средств защиты;
• регламентов взаимодействия между подразделениями.

SOC нельзя сводить к одной программе. Даже развитая платформа не расследует инциденты без выстроенных процессов и ответственных сотрудников.

Чем SOC отличается от SIEM

SIEM (Security Information and Event Management) — система управления событиями и информацией о безопасности.

SIEM собирает журналы, нормализует записи и сопоставляет события. Система может сформировать оповещение о подозрительной активности, но для проверки и реагирования нужны процессы и специалисты.

SOC использует SIEM как один из инструментов. Центр также включает аналитиков, инженеров, средства защиты и процедуры реагирования.

Условно SIEM можно сравнить с системой сигнализации, а SOC — со всей службой безопасности: она получает сигнал, проверяет угрозу и принимает меры.

Роль SOC в управлении информационной безопасностью

Центр связывает технические события с бизнес-рисками и помогает оценить не только сам факт атаки, но и её возможные последствия.

Например, заражение тестового компьютера и платёжного сервера имеет разную критичность. SOC учитывает роль актива, тип данных и права, которые мог получить злоумышленник.

Результат работы SOC — подтверждённые инциденты, рекомендации и действия по реагированию. Руководство получает сведения о рисках и слабых местах защиты.

Круглосуточный мониторинг событий безопасности

Кибератака может начаться ночью, в выходной или праздничный день. Поэтому организации с критичными процессами часто используют мониторинг 24/7.

SOC получает события от разных систем:

• серверов и рабочих станций;
• межсетевых экранов и маршрутизаторов;
• антивирусов и платформ EDR;
• облачных сервисов;
• корпоративной почты;
• бизнес-приложений;
• служб каталогов;
• систем управления доступом.

Центр контролирует непрерывность потока данных. Если критичный источник перестал передавать журналы, это тоже требует проверки.

Недостаточно один раз подключить источник. Нужно контролировать качество данных, синхронизацию времени и полноту полей, иначе правила обнаружения будут работать неточно.

Выявление кибератак и аномальной активности

SOC ищет признаки известных атак и аномальную активность. Для этого центр использует правила корреляции, индикаторы компрометации и поведенческий анализ.

Аналитики могут обнаружить:

• компрометацию учётной записи;
• запуск вредоносной программы;
• перемещение между узлами сети;
• выгрузку больших объёмов данных;
• атаку на веб-приложение;
• использование уязвимости;
• отключение средств защиты;
• подозрительные действия администратора.

Аномалия не всегда означает инцидент. Например, сотрудник может войти из новой страны во время командировки. Аналитик должен проверить контекст и определить, есть ли угроза.

Расследование инцидентов

После подтверждения угрозы SOC восстанавливает ход событий и определяет, как злоумышленник проник в инфраструктуру.

Затем аналитик ищет связанные действия: проверяет учётные записи, устройства, процессы и сетевые соединения.

Расследование должно ответить на несколько вопросов:

• где находилась точка входа;
• какие активы затронула атака;
• какие права получил нарушитель;
• происходила ли передача данных;
• сохраняется ли доступ злоумышленника;
• какие действия нужны для устранения угрозы.

Выводы расследования помогают устранить последствия и первопричину инцидента.

Рис.1 Цикл работы SOC

Реагирование и предотвращение повторных инцидентов

SOC не должен ограничиваться уведомлением: он помогает выполнить конкретные действия по сдерживанию и устранению угрозы.

В зависимости от ситуации центр может:

• заблокировать учётную запись;
• изолировать рабочую станцию;
• остановить вредоносный процесс;
• заблокировать IP-адрес или домен;
• удалить опасное письмо;
• передать задачу владельцу системы;
• запустить утверждённый сценарий реагирования.

Часть действий выполняется вручную. Типовые операции можно автоматизировать через SOAR — Security Orchestration, Automation and Response.

Автоматизация сокращает задержки, но потенциально опасные действия требуют контроля. Ошибочная блокировка критичной системы может нарушить бизнес-процессы.

После инцидента специалисты обновляют правила обнаружения и проверяют, нет ли похожей активности на других узлах.

Отчётность и контроль защищённости

SOC формирует несколько видов отчётов.

Оперативная отчётность показывает текущие инциденты, а техническая содержит хронологию, артефакты и рекомендации.

Управленческий отчёт показывает динамику рисков, критичные проблемы и выполнение соглашений об уровне сервиса.

Регуляторная отчётность зависит от отрасли. Она может включать сведения об инцидентах, сроках обработки и принятых мерах.

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

Сбор событий

Источники передают журналы в централизованную систему через агенты, API, коллекторы или стандартные протоколы.

Данные приводят к единому формату — этот процесс называют нормализацией.

Без нормализации разные системы описывают одно действие по-разному. Унифицированные поля упрощают поиск и корреляцию.

События хранят в течение установленного срока. Он зависит от задач расследования, регуляторных требований и доступных ресурсов.

Корреляция и обнаружение угроз

На этом этапе SOC ищет опасные сочетания событий.

Правило может сработать после серии неудачных попыток входа. Более сложный сценарий учтёт успешную авторизацию, новое устройство и запуск административного инструмента.

Для обнаружения применяют:

• правила корреляции;
• индикаторы компрометации;
• модели поведения пользователей;
• анализ сетевых связей;
• сведения об актуальных угрозах;
• поиск отклонений от обычной активности.

Правила должны учитывать особенности инфраструктуры компании. Универсальный набор обеспечивает только начальное покрытие.

Первичный анализ оповещения

Аналитик первой линии проверяет оповещение: изучает источник, пользователя, актив и связанные события.

На этом этапе аналитик отсеивает ложные срабатывания и определяет приоритет.

Критичность зависит не только от техники атаки, но и от роли системы, ценности данных и возможного ущерба.

Событие на контроллере домена требует особого внимания. Такое же событие на изолированном тестовом узле может иметь меньший приоритет.

Эскалация и расследование

Сложные случаи передают аналитикам следующего уровня, которые проверяют гипотезы и строят хронологию.

Специалист может запросить данные из EDR, почтовой системы или сетевого анализа. При необходимости он привлекает владельца приложения.

Материалы расследования нужно сохранять. В карточке инцидента фиксируют факты, решения и выполненные действия.

Реагирование

После подтверждения инцидента запускается план реагирования. Он может включать технические и организационные шаги.

SOC координирует действия, но не всегда выполняет их самостоятельно. Например, для остановки производственной системы может потребоваться решение владельца процесса.

Поэтому компании заранее формируют матрицу ответственности: кто принимает решение и кто выполняет действие.

Улучшение правил обнаружения

Каждый инцидент даёт новые данные, которые SOC использует для развития мониторинга.

Команда добавляет новые признаки, уточняет логику корреляции и корректирует фильтры по результатам ложных срабатываний.

Так центр постепенно учитывает особенности инфраструктуры. Без постоянной настройки качество мониторинга со временем снижается.

SIEM

SIEM часто становится центральной точкой сбора событий. Система принимает журналы, поддерживает поиск и выполняет правила корреляции.

Ценность SIEM зависит от качества настройки. Само по себе подключение большого числа источников не делает мониторинг эффективным.

SOAR

SOAR автоматизирует повторяющиеся действия. Например, платформа может собрать сведения об IP-адресе, проверить репутацию домена и создать карточку инцидента.

Сценарии автоматизации называют плейбуками. Их запускают автоматически или после подтверждения аналитика.

EDR и XDR

EDR — Endpoint Detection and Response. Решение контролирует действия на рабочих станциях и серверах.

Аналитик видит дерево процессов, сетевые соединения и изменения файлов. В зависимости от возможностей решения EDR может позволять изолировать устройство.

XDR (Extended Detection and Response) объединяет данные от конечных точек, почты, сети и облачных сред.

NDR

NDR (Network Detection and Response) анализирует сетевой трафик и выявляет отклонения.

NDR помогает обнаруживать перемещения внутри сети и связи с внешней инфраструктурой злоумышленника.

Threat Intelligence

Threat Intelligence — сведения об угрозах, группах атакующих и индикаторах компрометации.

Эти данные помогают понять контекст события. Однако без проверки актуальности массовое добавление индикаторов создаёт лишний шум.

SOC должен учитывать актуальность сведений, доверие к источнику и применимость данных к своей инфраструктуре.

Vulnerability Management

Сведения об уязвимостях помогают оценить критичность. Если на атакуемом сервере есть уязвимость, которую можно использовать в текущем сценарии, приоритет инцидента повышается.

Важно сопоставлять результаты сканирования с конкретными активами. Без этого аналитик не сможет полноценно оценить риск.

Ticketing и Case Management

Система управления инцидентами хранит карточки, сроки и материалы расследования.

Она помогает контролировать SLA (Service Level Agreement) — соглашение об уровне сервиса.

Карточка должна содержать не только статус, но и хронологию, доказательства и принятые решения.

Средства визуализации и отчётности

Дашборды показывают состояние мониторинга. Они могут отображать критичные инциденты, время обработки и доступность источников.

Для руководства нужны отдельные показатели: техническая статистика без связи с рисками мало помогает принимать управленческие решения.

Рис.2 Архитектура SOC

Итоговый набор технологий зависит от инфраструктуры, модели угроз, регуляторных требований и зрелости процессов.

Аналитик первой линии — L1

Аналитик L1 контролирует очередь оповещений, выполняет первичную проверку и классифицирует событие.

Он собирает основной контекст и передаёт подтверждённые или сложные случаи на следующий уровень.

Первая линия должна работать по понятным инструкциям, но не закрывать оповещения механически.

Аналитик второй линии — L2

Аналитик L2 проводит углублённый анализ, ищет связанные события и определяет масштаб атаки.

Специалист подтверждает инцидент и готовит рекомендации. Он также помогает улучшать сценарии мониторинга.

Эксперт третьей линии — L3

Эксперт L3 работает со сложными атаками и проводит threat hunting — проактивный поиск скрытых угроз.

В его задачи могут входить анализ вредоносного кода и разработка новых методов обнаружения.

Инженер SOC

Инженер подключает источники, поддерживает платформы, настраивает сбор данных, интеграции и отказоустойчивость.

Он также внедряет правила и плейбуки. Без этой роли SOC быстро накапливает технический долг.

Руководитель SOC

Руководитель управляет командой, процессами и SLA, отвечает за развитие центра и отчётность.

Он также согласует приоритеты с бизнесом, чтобы направлять ресурсы на наиболее значимые риски.

1. Начальный уровень

Мониторинг охватывает лишь часть инфраструктуры. Процессы часто зависят от отдельных сотрудников.

Основные проверки выполняются вручную. Метрики либо отсутствуют, либо отражают только объём событий.

Главное ограничение — низкая повторяемость. Результат сильно зависит от опыта конкретного аналитика.

2. Базовый уровень

Компания формализует основные процессы. Появляются правила классификации, эскалации и закрытия инцидентов.

SOC контролирует критичные источники. Команда измеряет сроки обработки и выполнение SLA.

Главным ограничением остаётся реактивный подход: центр в основном работает с известными сценариями.

3. Развитый уровень

SOC применяет автоматизацию и Threat Intelligence, а команда регулярно проводит threat hunting.

Сценарии обнаружения связаны с техниками атак. Аналитики проверяют качество покрытия.

Метрики учитывают скорость, точность и долю автоматизации. Центр также проводит регулярные учения.

4. Проактивный уровень

Мониторинг строится с учётом бизнес-рисков. Центр постоянно адаптируется к изменениям инфраструктуры.

Аналитика помогает выявлять сложные цепочки действий. Команда проверяет гипотезы до появления подтверждённого инцидента.

Главная особенность — непрерывное развитие: SOC адаптирует сценарии к изменениям угроз, инфраструктуры и бизнес-процессов.

Когда целесообразен собственный SOC

Собственная модель подходит организациям, которым нужен полный контроль над данными и процессами и которые располагают необходимыми ресурсами.

Она оправдана при наличии зрелой службы ИБ, сменной команды и выделенных инженерных ролей.

Собственный SOC также подходит для специфической инфраструктуры, поскольку позволяет глубоко учитывать внутренние процессы.

Однако запуск потребует времени. Кроме платформ, нужно создать команду, регламенты и систему управления качеством.

Когда подходит коммерческий SOC

Коммерческий центр подходит, когда мониторинг нужно запустить быстро, а у провайдера уже есть аналитики и выстроенные процессы.

Услуга помогает компенсировать дефицит специалистов: заказчику не нужно формировать полную сменную команду.

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

Перед подключением следует проверить SLA, формат отчётов и порядок реагирования. Важно также согласовать хранение данных.

Гибридная модель

В одном из вариантов гибридной модели провайдер выполняет мониторинг первой линии, а внутренняя команда принимает критичные решения и организует реагирование.

Возможна и обратная схема: заказчик ведёт ежедневный мониторинг, а сложные расследования передаёт экспертам провайдера.

Гибридная схема помогает сохранить внутреннюю экспертизу и снизить нагрузку на команду.

Рис.3 Модели организации SOC

1. Обследование инфраструктуры

Проект начинается с инвентаризации. Нужно понять состав активов, сетевые связи и действующие средства защиты.

Отдельно выделяют критичные системы, отказ или компрометация которых могут причинить наибольший ущерб.

На этом этапе оценивают качество журналов: некоторые системы могут не фиксировать нужные события.

2. Формирование модели угроз и сценариев мониторинга

Команда сопоставляет активы с возможными угрозами и определяет последствия для каждого риска.

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

Такой подход помогает избежать бессистемного подключения источников.

3. Проектирование архитектуры

Архитектура описывает сбор, передачу и хранение данных, а также интеграции и требования к отказоустойчивости.

Нужно определить модель размещения: в инфраструктуре заказчика, в облаке или в гибридной среде.

Важно заранее оценить объём событий: ошибка в расчётах может привести к проблемам с производительностью и росту стоимости.

4. Разработка процессов

До промышленного запуска нужно описать жизненный цикл инцидента.

Процесс включает:

• регистрацию;
• классификацию;
• назначение ответственного;
• эскалацию;
• расследование;
• реагирование;
• закрытие;
• анализ результатов.

Для критичных случаев формируют отдельные процедуры, утверждают контакты и сроки.

5. Подключение источников

Источники подключают по приоритету: начинать со всех систем одновременно не стоит.

Сначала следует охватить критичные активы и ключевые точки контроля, например службы каталогов, межсетевые экраны и средства защиты.

После подключения проверяют полноту данных и убеждаются, что события поступают без значимых задержек.

6. Разработка сценариев обнаружения

Каждый сценарий должен решать понятную задачу.

Карточка сценария обычно содержит:

• описание угрозы;
• связанные активы;
• необходимые источники;
• логику выявления;
• уровень критичности;
• порядок проверки;
• действия по реагированию;
• условия закрытия.

Сценарии нужно тестировать: формальное наличие правила не гарантирует, что оно обнаружит реальную атаку.

7. Пилотная эксплуатация

На пилоте команда проверяет архитектуру и процессы. Аналитики оценивают качество оповещений.

Часть правил будет создавать лишний шум, поэтому их нужно адаптировать к нормальной активности компании.

Пилот также выявляет пробелы в журналах: нужные поля могут отсутствовать или передаваться некорректно.

8. Запуск промышленной эксплуатации

После пилота центр переходит на целевые SLA. Команда начинает регулярную отчётность.

Ответственные сотрудники должны понимать порядок взаимодействия, иначе даже точное обнаружение не приведёт к быстрому реагированию.

9. Непрерывное развитие

Инфраструктура и угрозы постоянно меняются, поэтому SOC нельзя считать завершённым проектом.

Нужно подключать новые активы, обновлять сценарии, проводить учения и контрольные проверки.

Инфраструктура

К базовым источникам относятся серверы и операционные системы: они фиксируют входы, процессы и изменения настроек.

Также полезны события:

• баз данных;
• платформ виртуализации;
• систем резервного копирования;
• файловых хранилищ;
• систем управления конфигурациями.

Журналы систем резервного копирования особенно важны при атаках программ-вымогателей.

Сеть

Сетевые источники помогают контролировать внешние и внутренние соединения.

К ним относятся:

• межсетевые экраны;
• маршрутизаторы;
• VPN-шлюзы;
• DNS-серверы;
• прокси-серверы;
• IDS/IPS;
• системы анализа трафика.

DNS-журналы могут содержать ранние признаки заражения: устройство иногда обращается к вредоносному домену до появления других заметных действий.

Средства защиты

Антивирусы и EDR дают данные о процессах и файлах, а WAF помогает выявлять атаки на веб-приложения.

Также в SOC передают события от DLP, PAM и систем контроля доступа.

PAM (Privileged Access Management) — решения для управления привилегированным доступом.

Облачные и прикладные системы

Облачная инфраструктура формирует собственный набор событий. Важно получать журналы административных действий, входов и изменений политик.

Также следует подключать:

• корпоративную почту;
• службы каталогов;
• ERP и CRM;
• веб-приложения;
• DevOps-платформы;
• системы управления исходным кодом;
• средства контейнеризации.

Начинать следует с систем, связанных с критичными процессами, а затем расширять покрытие.

Рис.4 Источники событий SOC

Подбор паролей и компрометация учётной записи

Угроза: злоумышленник пытается подобрать пароль.

Источники: служба каталогов, VPN, облачная платформа и приложение.

Признаки: серия неудачных входов, затем успешная авторизация.

Действия аналитика: проверить IP-адрес, устройство и обычное поведение пользователя.

Реагирование: заблокировать сессию, сменить пароль и проверить активность учётной записи.

Вход из необычного региона

Угроза: использование украденных данных.

Источники: VPN, почта и облачные сервисы.

Признаки: вход из нового региона или географически невозможное перемещение за короткий промежуток времени.

Действия аналитика: проверить сведения о командировках, устройство и результаты многофакторной аутентификации.

Реагирование: завершить сессию и запросить подтверждение пользователя.

Повышение привилегий

Угроза: получение административных прав.

Источники: службы каталогов, операционные системы и PAM.

Признаки: добавление в привилегированную группу или изменение политик.

Действия аналитика: определить инициатора и проверить заявку на изменение.

Реагирование: отменить изменение и ограничить учётную запись.

Отключение средств защиты

Угроза: попытка ослабить защиту перед запуском вредоносного кода.

Источники: EDR, антивирус и системные журналы.

Признаки: остановка службы, изменение политик или удаление агента.

Действия аналитика: проверить пользователя, процесс и связанные события.

Реагирование: изолировать узел и восстановить защиту.

Запуск подозрительного PowerShell-кода

Угроза: выполнение вредоносных команд.

Источники: EDR, журналы PowerShell и сетевые события.

Признаки: обфускация команд, загрузка файлов или скрытый запуск.

Действия аналитика: изучить дерево процессов и сетевые адреса.

Реагирование: остановить процесс и изолировать устройство.

Массовое шифрование файлов

Угроза: атака программы-вымогателя.

Источники: EDR, файловые серверы и система резервного копирования.

Признаки: быстрое изменение файлов, новые расширения и удаление теневых копий.

Действия аналитика: определить исходный узел и затронутые ресурсы.

Реагирование: изолировать устройства и ограничить доступ к хранилищам.

Передача большого объёма данных наружу

Угроза: утечка информации.

Источники: DLP, прокси, межсетевые экраны и облачные сервисы.

Признаки: необычный объём, новый получатель или редкий протокол.

Действия аналитика: определить владельца данных и проверить деловую необходимость передачи.

Реагирование: остановить передачу и привлечь владельца процесса.

Обращение к вредоносному домену

Угроза: связь заражённого узла с сервером управления.

Источники: DNS, прокси, NDR и Threat Intelligence.

Признаки: совпадение с индикатором компрометации и регулярные обращения.

Действия аналитика: найти процесс и другие устройства с похожей активностью.

Реагирование: заблокировать домен и изолировать узел.

Перемещение между узлами сети

Угроза: развитие атаки внутри инфраструктуры.

Источники: EDR, NDR, службы каталогов и системные журналы.

Признаки: удалённый запуск, новые административные сессии и доступ к нескольким узлам.

Действия аналитика: восстановить маршрут перемещения и определить скомпрометированные учётные данные или узлы.

Реагирование: ограничить учётную запись и сегментировать затронутый участок.

Основные метрики

SOC нельзя оценивать только по числу обработанных событий. Важнее скорость, качество решений и полнота покрытия.

К основным метрикам относятся:

• MTTD — Mean Time to Detect, среднее время обнаружения;
• MTTA — Mean Time to Acknowledge, среднее время принятия в работу;
• MTTR — Mean Time to Respond, среднее время реагирования; конкретную точку отсчёта нужно закрепить в методике;
• число подтверждённых инцидентов;
• доля ложных срабатываний;
• выполнение SLA;
• покрытие критичных активов;
• покрытие техник атак;
• доля автоматизированных операций;
• число повторных инцидентов.

Метрики нужно анализировать вместе. Например, низкий MTTD мало полезен, если реагирование занимает несколько дней.

Почему количества событий недостаточно

Инфраструктура может создавать миллионы событий, но их количество не говорит о качестве защиты.

SOC может обрабатывать большой поток, но пропускать значимые атаки. И наоборот, небольшой поток может содержать точные сигналы.

Нужно оценивать полноту контекста, точность сценариев и фактический результат реагирования.

Отчётность для руководства

Руководству важен не список технических оповещений, а их влияние на бизнес.

Отчёт может показывать:

• динамику рисков;
• наиболее атакуемые активы;
• критичные инциденты;
• повторяющиеся причины;
• эффект принятых мер;
• состояние ключевых проектов;
• план развития мониторинга.

Данные следует сравнивать по периодам, чтобы видеть устойчивые изменения.

Рис.5 Показатели эффективности SOC

SIEM внедряют без процессов

Платформа создаёт оповещения, но сотрудники не знают, как их обрабатывать.

Как избежать: заранее описать классификацию, эскалацию и реагирование.

Все источники подключают одновременно

Команда получает большой поток данных, а критичные системы теряются среди второстепенных.

Как избежать: подключать источники на основе рисков и сценариев.

Не назначают владельцев активов

SOC обнаруживает инцидент, но не может быстро найти ответственного.

Как избежать: вести актуальную матрицу владельцев и контактов.

Создают слишком много правил

Большое число правил создаёт шум, из-за которого аналитики могут пропускать важные сигналы.

Как избежать: проверять пользу каждого сценария и удалять неэффективные правила.

Игнорируют качество журналов

Неполные данные затрудняют расследование, а рассинхронизация времени искажает хронологию.

Как избежать: контролировать доступность, полноту и синхронизацию источников.

Не определяют SLA

Инциденты обрабатываются без понятных сроков. Критичные случаи могут ждать слишком долго.

Как избежать: задать сроки по уровням критичности.

Не проверяют сценарии

Правило есть в SIEM, но не срабатывает при воспроизведении реальной техники атаки.

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

Ориентируются только на формальное соответствие

Отчётность может соответствовать требованиям, но реальные угрозы останутся незамеченными.

Как избежать: связывать мониторинг с активами, рисками и последствиями.

Чем SOC отличается от SIEM?

SIEM — техническая платформа для сбора и сопоставления событий безопасности. SOC включает SIEM, аналитиков, процессы, регламенты и средства реагирования. Платформа может сформировать оповещение, но без команды и процессов не проведёт полноценное расследование. Поэтому внедрение SIEM — часть создания центра, а не готовый SOC.

Нужен ли SOC небольшой компании?

Небольшой компании не всегда нужен собственный центр, но мониторинг критичных систем всё равно необходим. Подходящим вариантом может стать коммерческий SOC с ограниченным набором контролируемых активов — например, корпоративной почтой, VPN, облачными сервисами и рабочими устройствами.

Сколько времени занимает внедрение SOC?

Срок зависит от масштаба и готовности инфраструктуры. На него влияют число источников, качество журналов, сложность интеграций, а также время на разработку процессов и сценариев. Быстрое подключение SIEM ещё не означает готовность SOC: перед промышленным запуском нужно проверить данные и взаимодействие команды.

Чем SOC отличается от CERT и CSIRT?

SOC постоянно мониторит инфраструктуру и выявляет подозрительные события. CSIRT (Computer Security Incident Response Team) специализируется на реагировании и расследовании инцидентов. CERT (Computer Emergency Response Team) может выполнять сходные функции; конкретное распределение ролей зависит от организации. На практике зоны ответственности SOC, CSIRT и CERT нередко пересекаются.

Как проверить качество коммерческого SOC?

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