SOC: процессы, роли, метрики и зрелость

Зачем это нужно

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

Теория

Типовой цикл: сбор и хранение данных → нормализация и обогащение → обнаружение и оповещение → анализ и классификация → реагирование и устранение → разбор и улучшение. Роли: аналитик первой линии (отсев и первичная оценка), второй линии (глубокий разбор), третьей (охота, разработка обнаружения), инженер данных и платформ, руководитель процесса. Часто роли совмещаются, особенно в небольших командах.

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

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

Ключевые концепции

Линии поддержки

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

Инструкция по оповещению

Что делать с конкретным типом оповещения: шаги проверки и критерии эскалации.

Зрелость процессов

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

Покрытие источников

Какая телеметрия собрана: без неё часть техник принципиально невидима.

Усталость от оповещений

Состояние, при котором шум мешает замечать значимые события.

Время до обнаружения и локализации

Ключевые метрики операционной эффективности.

Инструменты

• SIEM или платформа данных для журналов и правил.
• EDR или средства конечных точек для телеметрии процессов и файлов.
• Системы управления инцидентами и журналы действий.
• Каталоги правил (Sigma и внутренние) с описанием и владельцами.
• Панели метрик и отчёты по качеству правил.

Практика в легальных лабораториях

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

Защита, детект и защитные меры

• Держите список источников данных актуальным и контролируйте полноту сбора.
• У каждого правила должен быть владелец, описание и измеренная точность.
• Пересматривайте шумные правила: лучше меньше точных, чем много бесполезных.
• Разбирайте инциденты с фокусом на системные причины.

Правовая рамка и этика

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

Типичные ошибки

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

Чек-лист «умею»

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

Вопросы на интервью

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

Источники и первоисточники

• NIST SP 800-61 — обработка инцидентов
• MITRE ATT&CK — обзор