SOC может получать большое число оповещений, журналов и данных мониторинга, но при расследовании ключевой вопрос нередко остаётся без ответа: какая идентичность связана с активностью и к каким ресурсам она имеет доступ.
Подозрительный вход не обязательно означает действия злоумышленника: его мог выполнить сотрудник. Нетипичный API-вызов может исходить от машинной учётной записи. Доступ к чувствительным системам способен получить и ИИ-агент, действующий с разрешениями, которые давно не пересматривались. SIEM и EDR фиксируют такие события, однако сами по себе не всегда показывают владельца идентичности, её полномочия, связанные системы и возможный масштаб последствий.
Разрыв между IAM и SOC
Команды IAM обычно располагают данными о том, кто и к чему имеет доступ. SOC отслеживает подозрительную активность и реагирует на инциденты. На практике эти функции нередко работают с разными инструментами и наборами данных, а их приоритеты не всегда совпадают.
В результате аналитик видит событие, но не может сразу определить его значение для организации. При компрометации служебной учётной записи, например, нужно установить:
- к каким приложениям и системам она имеет доступ;
- может ли её использование помочь атакующему продвинуться глубже в инфраструктуру;
- каким может быть ущерб;
- можно ли отключить учётную запись, не остановив критически важный процесс.
Ошибочное отключение служебной идентичности способно вызвать сбои в производственных или других важных процессах. Но затягивание решения даёт атакующему дополнительное время для развития активности. Поэтому реагирование не сводится к обнаружению аномалии: необходимо оценивать последствия и блокировки, и бездействия.
Не только пользователи и устройства
Традиционный мониторинг в основном строился вокруг пользователей, устройств и сетевой активности. В рабочих процессах теперь участвуют и служебные учётные записи, API-ключи, автоматизированные нагрузки, а также ИИ-агенты, которые способны выполнять действия без непосредственного участия человека.
Такие идентичности могут иметь доступ к важным системам и данным. Если одна из них скомпрометирована, фиксация подозрительного действия становится только началом расследования. Специалистам требуется определить её права, связи с другими ресурсами и вероятные последствия компрометации.
Новости информационной безопасности, технологий и государственного регулирования, а также анонсы новых исследований Tech Threat Lab.
Контекст идентичности позволяет не рассматривать каждое оповещение изолированно. Связав событие с конкретным пользователем, машинной учётной записью или ИИ-агентом, SOC может оценить возможное продвижение атакующего, потенциальный радиус воздействия и выбрать меры, ограничивающие ущерб без необязательной остановки рабочих процессов.
Какие данные нужны при реагировании
Речь не обязательно идёт о создании ещё одной панели мониторинга или увеличении числа оповещений. Задача состоит в том, чтобы дать аналитику сведения об идентичности в момент развития инцидента и связать их с уже поступающими сигналами SIEM и EDR.
Для проверки, может ли SIEM использоваться в инфраструктуре для сопоставления событий с данными об идентичностях, можно обратиться к официальной странице Security Capsule SIEM для оценки применимости к требованиям инфраструктуры. Такая проверка относится к практической задаче расследования: аналитик должен получить контекст учётной записи вместе с сигналом, а не после отдельного ручного поиска по нескольким системам.
Подход с контекстом идентичности предполагает возможность:
- быстрее устанавливать, какая идентичность — человек, машина или ИИ-агент — связана с событием;
- оценивать фактический риск с учётом прав доступа, подключённых систем и возможностей латерального перемещения;
- сдерживать угрозу, не нарушая критически важные автоматизированные процессы;
- выстраивать общую работу IAM и SOC через единые процессы, понятные маршруты эскалации и согласованные цели реагирования.
Особое значение имеют анализ латерального перемещения и оценка потенциального радиуса воздействия. Недостаточно установить, что произошло подозрительное действие: необходимо понимать, на какие системы и данные оно может повлиять, а также какие действия допустимы для его остановки. Для служебной учётной записи это означает проверку не только самого факта её использования, но и зависимостей процессов, которые она обслуживает.
Практический вывод
Российским организациям при настройке процессов SOC стоит проверить, получает ли аналитик вместе с оповещением данные о владельце идентичности, её правах, связанных системах и роли в автоматизированных процессах. Отдельно важно заранее согласовать между IAM и SOC правила эскалации, показатели и сценарии реагирования.
Это позволяет принимать решение о блокировке или ограничении доступа с учётом не только признаков атаки, но и возможного влияния на работу инфраструктуры. Контекст идентичности не отменяет необходимость расследовать подозрительную активность, но помогает определить, какие меры сдерживания допустимы в конкретном случае и как быстро их можно применить.