Мифы и правда о SOC: как оценивать эффективность и строить работу
Изображение: recraft
Продолжаем разбирать мифы о центрах мониторинга кибербезопасности. В этой статье архитектор «Кросс технолоджис» Олег Игумнов расскажет, может ли внешний SOC полностью заменить команду реагирования внутри компании, правда ли, что эффективность центра оценивается по количеству пресеченных инцидентов, и ответит на вопрос, можно быть «совместителем» в SOC. Прочитать первую часть можно по ссылке.
1. Если у вас есть внешний SOC, то внутренняя команда реагирования не нужна
Приведу несколько фактов.
Внешний SOC видит угрозы: он анализирует телеметрию, обнаруживает аномалии и предоставляет технические данные об инциденте: что произошло, на каком узле, каким методом.
Но только внутренняя команда знает контекст: исключительно сотрудники компании знают нюансы бизнес-процессов, критически важные активы, политики компании и могут принять решение о полной остановке системы, уведомить руководство и начать восстановление.
Есть и вопрос полномочий: внешний SOC не имеет прав в вашей сети для активных действий (например, отключения сервера). Это делают внутренние специалисты по его указанию.
➜ Вердикт: внешний SOC и внутренняя команда — не заменяют, а дополняют друг друга.
Экспертам SOC нужен чёткий регламент взаимодействия с заказчиком. При обнаружении угрозы SOC связывается с представителем ИБ заказчика, который проверяет срабатывание, одобряет блокировки и помогает настроить правила, адекватные для бизнес-процессов. Поэтому в команде заказчика обязательны эксперты, хорошо знающие свою инфраструктуру.
На мой взгляд, идеальная модель — внешний SOC как сервис + внутренний CSIRT. SOC — это глаза и уши, а CSIRT — это руки и мозг, принимающий бизнес-решения.
2. Эффективность SOC нужно оценивать по количеству пресечённых инцидентов
✗ Миф! Сам по себе этот показатель не имеет смысла, и может быть легко «накручен». Эффективность SOC — это комплекс метрик, показывающих качество, а не количество. Можно настроить тысячи правил и генерировать миллионы алертов, «пресекая» массовые сканирования. Но это не имеет ничего общего с отражением реальных целевых атак.
Как правило, SOC оценивают по следующим метрикам:
- MTTD (Mean Time to Detect) — среднее время от начала атаки до ее обнаружения.
- MTTR (Mean Time to Respond) — среднее время от обнаружения до полного устранения инцидента.
- Процент ложных срабатываний — отражает точность настроек и квалификацию аналитиков.
- Покрытие — процент критически важных активов, охваченных мониторингом.
- Качество расследований — глубина и детализация предоставляемых отчетов.
- Количество пропущенных угроз — обычно выявляется при аудитах или тестах Red/Purple Team.
3. Специалист по ИБ может совмещать работу в SOC с другими задачами, например, ИТ-поддержкой
Отвечу популярным мемом, а ниже приведу факты.
SOC — это не «еще одна обязанность» ИТ-отдела, а специализированная команда с четкими процессами. Совмещение ролей убивает его эффективность.
Когнитивная нагрузка: работа в SOC требует постоянной учебы, отслеживания новых угроз и высокой концентрации. Совмещение ее с рутинными ИТ-задачами («сбросить пароль», «настроить принтер») снижает градус внимания и быстро приводит к ошибкам и пропуску реальных угроз.
Ответственность: сотрудник, разрывающийся между задачами, не может нести полноценную ответственность за безопасность. В случае инцидента окажется, что он в тот момент был занят решением проблемы с почтой.
➜ Вердикт: ✗ Миф!
«Хороший специалист — узкий специалист», и работа SOC аналитика — не исключение.
