Журнал "Information Security/ Информационная безопасность" #4, 2025

кам отследить перемещения злоумыш- ленника в сети, даже если его действия были замаскированы под легитимную активность. Наконец, NDR может служить источ- ником для формирования внутренней базы знаний об угрозах. Такое приме- нение дает возможность лучше калиб- ровать политики безопасности или плей- буки и адаптировать их под реальные сценарии атак. Нередко именно внедре- ние NDR становится катализатором для изменений в процессах SOC, так как делает видимыми слабые места, о кото- рых ИБ-отделы раньше не подозревали. NAC против NGFW и роль ручного реагирования Изоляция хоста часто становится пер- вым ответом на выявленный инцидент. При выборе инструмента для этого обыч- но рассматривают два варианта: NAC и NGFW. NAC обеспечивает изоляцию конкретного узла в сети и, надо признать, это наиболее предсказуемый способ с минимальными "побочными эффекта- ми". Хост блокируется до вмешательства администратора или выполнения задан- ного сценария, а риск влияния на смеж- ные сегменты сети минимален. NGFW также может блокировать трафик на основе загрузки правила для блокиро- вания скомпрометированного ресурса или передачи информации об этом ресурсе в формате индикатора компро- метации (IoC), но вероятность ошибок в этом сценарии заметно выше. Добав- ление многочисленных динамических правил может негативно сказаться на работе легитимных сервисов. Важно помнить, что NGFW в первую очередь предназначен для контроля периметра, а не для изоляции хостов внутри корпо- ративной сети, и с нетипичной задачей справляется не всегда идеально. Таким образом, можно заключить, что NAC является оптимальным решением для автоматической изоляции хостов в корпоративной сети. NGFW полезен только для отдельных сценариев, напри- мер для блокировки внешних IP-адресов на основе данных TI. Однако даже в условиях развитой автоматизации сохраняется необходи- мость ручного реагирования, поскольку оно позволяет провести детальное рас- следование. Аналитик получает возмож- ность детально разобрать событие: изучить копию всего трафика или отно- сящегося к событию, исследовать сете- вые пакеты, проверить индикаторы ком- прометации в базах TI или запустить ручной плейбук для изоляции или эска- лации. Это позволяет проверить гипоте- зы и сводит к минимуму вероятность ошибки. Наиболее сбалансированным реше- нием становится полуавтоматическое реагирование. В этом случае аналитик подтверждает обнаруженное событие, а последующая изоляция выполняется автоматически. Такой подход сочетает опера- тивность реакции и конт- роль принимаемых реше- ний. На практике именно подобные сценарии часто оказываются наиболее востребованными, осо- бенно в условиях россий- ских SOC, где не хватает ресурсов аналитиков, а полуавтоматические сценарии как раз позволяют оптимизировать нагрузку на специалистов без ущерба для качества мониторинга. От SIEM в настоящем к XDR в будущем Архитектура большинства организа- ций на сегодняшний день остается SIEM- центричной. Все события стекаются в SIEM, где они нормализуются и корре- лируются. В SIEM формируются инци- денты, которые затем обрабатываются аналитиками или передаются в SOAR. Этот подход знаком и относительно отлажен, но у него есть существенные недостатки: высокая нагрузка на коман- ды SOC, задержки в обработке событий, рост числа источников данных, услож- няющий корреляцию. Многие инциденты формируются постфактум, когда атака уже успела развиться. Следующий шаг развития – XDR-цент- ричная архитектура. В отличие от SIEM, работающей с сырыми данными логов, XDR оперирует обогащенными собы- тиями, агрегированными в инциденты, которые получены от средств защиты. Система сама выполняет корреляцию, обогащение, скоринг и способна ини- циировать реагирование. В этой модели SIEM сохраняет роль хранилища логов и инструмента аудита, в то время как центр управления инцидентами и сред- ствами защиты смещается в XDR. Это дает сразу несколько преимуществ: сни- жается нагрузка на SOC за счет авто- матизации корреляции, формируются готовые инциденты вместо событийного шума, появляется возможность надеж- ного автоматического реагирования бла- годаря скорингу и охват не только сете- вого уровня, но и конечных точек, обла- ков и контейнеров. Для российского рынка переход к XDR- центричной модели будет постепенным. Многие компании уже сейчас рассмат- ривают XDR как стратегическое направ- ление развития, хотя их существующая инфраструктура и процессы пока выстроены вокруг SIEM. Важно пони- мать, что переход потребует времени, и первые шаги могут заключаться в интег- рации NDR и NAC в существующую SIEM-центричную архитек- туру, с последующим постепенным смещением фокуса в сторону XDR. В перспективе XDR, веро- ятно, будет выполнять роль центра управления реагированием, объединяя различные классы решений и упрощая для заказчиков построение целостной картины инцидентов. Уже сейчас стоит задуматься о том, как обеспечить совместимость будущего XDR с существующей ИБ-инфраструк- турой, чтобы избежать зависимости от одного вендора и сохранить необходи- мую гибкость архитектуры. Отдельного упоминания заслуживает применение технологии Deception. Она позволяет выявить появление злоумыш- ленника в сети на ранней стадии, изо- лировать его в ложном слое инфра- структуры и дополнить картину атаки. Deception предоставляет аналитикам SOC дополнительный контекст, помогая понять, какие техники использует зло- умышленник, и быстрее связать отдель- ные события в единую цепочку инци- дента. Изолированные ловушки, не интегрированные с другими системами безопасности, дают ограниченную цен- ность, так как не позволяют восстановить цепочки событий до обращения к ловуш- ке или использования приманки учетной записи. Поэтому чаще всего решения Deception применяют совместно с NDR, EDR или XDR, что создает комплексную систему обнаружения и реагирования. Стратегия сетевой защиты Не стоит забывать, что до внедрения сложных технологий безопасности необходимо закрыть базовые вопросы защиты сети. Они включают в себя инвентаризацию активов, настройку сег- ментации сети и документирование раз- решенных потоков данных. После этого можно двигаться дальше: внедрить NDR в качестве основного источника сетевой аналитики, использовать NAC как глав- ный инструмент изоляции и готовить инфраструктуру к переходу на XDR- центричную архитектуру. Для ИБ-руководителей это означает пересмотр приоритетов: акцент следует делать не на закупке новых инструмен- тов, а на эффективном использовании существующих ресурсов. Только так можно преобразовать технологические инвестиции в измеримые улучшения безопасности. l • 61 ЗАЩИТА СЕТЕЙ www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ ГРУППА КОМПАНИЙ ГАРДА см. стр. 84 NM Реклама Рисунок: Гротек