Rambler's Top100
Статьи
Дмитрий КОСТРОВ  03 июля 2025

EDR vs логирование, или Можно ли обойтись без EDR

На чем остановиться при создании SOC для своей организации или выборе аутсорсингового центра кибербезопасности: необходимо ли развертывание системы обнаружения угроз и реагирования на них на конечных точках (EDR) или же достаточно сбора логов с наиболее важных систем и их обработки?

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

SOC (Security Operations Center) – это центр безопасности, который отвечает за защиту организации от киберугроз. Аналитики SOC осуществляют круглосуточный мониторинг сети организации и расследуют все потенциальные инциденты безопасности. В случае обнаружения кибератаки они несут ответственность за принятие мер, необходимых для ее устранения. SOC включает в себя три основных элемента управления и повышения уровня безопасности организации: люди, процессы и технологии. 

EDR (Endpoint Detection & Response) — класс решений для обнаружения и изучения вредоносной активности на конечных точках (подключенных к сети рабочих станциях, серверах и т.п.). Системы EDR отслеживают активность на конечных точках и находят аномальную, что позволяет выявлять действия злоумышленников и оперативно (это главное!) реагировать на инциденты. EDR обнаруживает угрозы на ранних этапах и предоставляет инструменты для активного реагирования как автоматически, так и вручную. Можно самим, без ИТ-администратора, блокировать вредоносную активность, что очень ценно для безопасника, особенно ночью, в выходные, праздничные дни и т.д.

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

Какую информацию нужно логировать?

Вся собранная информация сначала направляется на некий первичный обработчик логов (предSIEM, или брокер), чтобы система обработки просто не захлебнулась. Важную роль здесь играет параметр EPS (Events Per Second) — количество событий, обрабатываемых системой безопасности в секунду. Его постоянно держат в уме те, кто предоставляет услуги SOC, но на него редко обращают внимание заказчики. 

Логирование не предполагает фиксации абсолютной всей информации, поскольку, например, логирование уровня DEBUG для Cisco ASА способно исчерпать все пространство хранения. Уровни логирования маршрутизатора Cisco включают в себя аварийные ситуации (0), оповещения (1), критические события (2), сообщения об ошибках (3), предупреждения (4), уведомления (5), информационные сообщения (6) и отладочные сообщения (7). Вы можете задать уровень серьезности сообщений, чтобы контролировать тип сообщений, отображаемых на консоли, и каждое из назначений. Можно ставить временные метки на сообщения журнала или устанавливать исходный адрес syslog, чтобы улучшить отладку и управление в реальном времени. Какой же уровень логирования нужен? До настоящего времени общепринятого ответа нет. Все «тюнингуется» в процессе внедрения того или иного решения.

Давайте вспомним, какую информацию по безопасности мы можем собрать в OC Windows. Для аудита безопасности обычно собирают следующие типы событий: 4624 (успешный вход в систему), 4647 (выход из системы), 4625 (неудачный вход в систему), 4778/4779 (соединение/разъединение по RDP), 4800/4801 (блокировка/разблокировка рабочей станции) и некоторые другие. В частности, нам важно понимать, как именно был осуществлен вход в систему (код события о неудачном входе в систему). Типы входа в систему: 2 – интерактивный, 3 – сетевой, 4 – запуск по расписанию, 5 – запуск сервиса, 7 – разблокировка экрана, 8 – сетевой (Basic Authentication в IIS), 10 – подключение по RDP. Корпорация Microsoft советует при настройке аудита для контроллеров домена обновить параметры расширенной политики аудита и дополнительные конфигурации для определенных событий и типов событий, таких как пользователи, группы, компьютеры и др. Предлагаемые конфигурации аудита для контроллеров домена — расширенная политика аудита, аудит NTLM, аудит объектов домена.

Для Windows аудит безопасности — это методическое исследование и обзор действий, которые могут повлиять на безопасность системы. В операционных системах Windows аудит безопасности — это функции и службы, с помощью которых администратор может регистрировать и просматривать события для определенных действий, связанных с безопасностью. Мониторинг этих событий может предоставить ценную информацию, которая поможет администраторам устранять неполадки и расследовать действия, связанные с безопасностью. Это нам и нужно. 

Мы помним (во всяком случае, администраторы Windows обязаны помнить), что все объекты в доменных службах Active Directory (AD DS) и все защищаемые объекты на локальном компьютере или в сети имеют дескрипторы безопасности, помогающие контролировать доступ к ним. Дескрипторы безопасности включают информацию о том, кто владеет объектом, кто может получить к нему доступ и каким образом, какие типы доступа проверяются. 

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

Что дает логирование дескрипторов безопасности?

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

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

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

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

Дескрипторы содержат список управления доступом (ACL) объекта, который включает все разрешения безопасности, применимые к этому объекту. Дескриптор может содержать два типа ACL: список дискреционного контроля доступа (DACL), определяющий пользователей и группы, которым разрешен или запрещен доступ; и системный список контроля доступа (SACL), который контролирует, как осуществляется аудит доступа. Модель контроля доступа, используемая в Windows, администрируется на уровне объектов путем установки различных уровней доступа или разрешений для объектов. 

Если для объекта настроены разрешения, его дескриптор безопасности содержит DACL с идентификаторами безопасности (SID) для пользователей и групп, которым разрешен или запрещен доступ. Если для объекта настроен аудит, его дескриптор безопасности также содержит SACL, который управляет тем, как подсистема безопасности проверяет попытки доступа к объекту. Однако аудит не настроен полностью, если SACL не настроен для объекта и соответствующий параметр политики аудита доступа к объекту не настроен и не применен.

Сложно?

Что же следует собирать в качестве важных логов и каким должен быть уровень EPS? Что собирать, станет ясно после выполнения двух команд: auditpol /list /subcategory:* (список всех доступных подкатегорий аудита) и auditpol /get /category:* (список настроенных в настоящее время подкатегорий аудита). Но этого недостаточно. 

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

Каковы возможности EDR?

С чем обычно сталкивается сотрудник отдела информационной безопасности при попытке развернуть агентов EDR на рабочих станциях пользователей, особенно на серверах? С противодействием ИТ-службы: «Мы боремся за бизнес, а ИБ только мешает и тормозит бизнес. Каждый процент загрузки сервера важен нам и важен бизнесу». 

Какие здесь возникают вопросы и какие на них обычно даются ответы?
  • Нужен ли агент системы DLP? Да.
  • Нужен ли агент антивирусной защиты? Да.
  • Нужен ли агент EDR? Это вопрос для обсуждения. 
Прежде всего не будем путать EDR с XDR (Extended Detection and Response, расширенные обнаружение и реагирование). XDR — класс систем информационной безопасности, предназначенных для автоматического проактивного выявления угроз на разных уровнях инфраструктуры, реагирования на них и противодействия сложным атакам. Microsoft описывает XDR как единую автоматизированную платформу для инцидентов безопасности, использующую ИИ. Эта платформа предоставляет организациям комплексный и эффективный способ защиты от сложных кибератак и реагирования на них.

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

В зависимости от профиля риска, потребностей в безопасности и существующей цифровой инфраструктуры бизнеса системы XDR, такие как Microsoft Defender XDR, могут оказаться даже лучшим решением. XDR в отличие от EDR расширяет сферу безопасности за пределы конечных точек, включая данные в реальном времени из других уязвимых сред, таких как сети, облачные платформы и электронная почта. Внедрение систем XDR в ваш стек безопасности помогает создать более целостное представление об организации.

Возвращаемся к SOC и EDR. 

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

Системы EDR предлагают проактивный подход к управлению угрозами следующими средствами:
  • сбор и анализ огромных объемов данных с конечных точек для выявления подозрительного поведения, часто с использованием методов машинного обучения и поведенческого анализа; 
  • обеспечение детального обзора действий конечных точек, что позволяет быстро обнаруживать аномалии и оперативно реагировать на инциденты; 
  • интеграция с другими инструментами безопасности для повышения общего уровня безопасности организации; 
  • обеспечение комплексной защиты от сложных киберугроз.
При оценке возможностей EDR целесообразно рассмотреть три вопроса:
  1. Что дает система EDR при мониторинге инфраструктуры?
  2. Как происходит обнаружение угроз?
  3. Выявляет ли критические недостатки конфигурации инфраструктуры? (Полезная функциональность, сам использую.)
Если говорить о горизонтальном и вертикальном движении информации в корпоративной сети, то EDR поможет отслеживать горизонтальное движение. 

От агента EDR требуется, чтобы он мог обрабатывать как можно больше (на практике более 150) событий мониторинга и инвентаризации, чтобы происходило обогащение телеметрии необходимым контекстом (для принятия решения). Журнал событий должен пополняться данными киберразведки, и эти данные должны использоваться для проактивного поиска угроз (охоты на угрозы, threat hunting), т.е. проактивного обнаружения вредоносной деятельности в компьютерных сетях. 

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

Система EDR должна автоматически выявлять угрозы на базе индикаторов компрометации (Indicator of Compromise, IoC), поведенческих индикаторов атаки (IoA) и YARA-правил. Индикатором компрометации в сфере компьютерной безопасности называют наблюдаемый в сети или на конкретном устройстве объект (или активность), который с большой долей вероятности свидетельствует о несанкционированном доступе к системе (т.е. ее компрометации). Индикаторы атаки фокусируются на инцидентах в режиме реального времени и поведенческих признаках злоумышленников. Они указывают на то, что атака произойдет с высокой вероятностью. 

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

Правила YARA используются для классификации и идентификации образцов вредоносных программ путем создания описаний их семейств на основе текстовых или двоичных шаблонов. Один из самых популярных вариантов расшифровки аббревиатуры YARA — Yet Another Ridiculous Acronym — «Еще один нелепый акроним».

Также система EDR должна сопоставлять собранную информацию с матрицей (базой знаний) Mitre ATT&CK (Adversarial Tactics, Techniques & Common Knowledge — тактики, техники и общеизвестные факты о злоумышленниках), которую компания Mitre на основе реальных наблюдений пополняет описаниями тактик, приемов и методов, используемых киберпреступниками в атаках на корпоративную инфраструктуру.

Важно, чтобы система EDR обнаруживала угрозу автономно, без отправки информации на сервер, ведь связи с сервером может просто не быть. Полезна возможность добавления пользовательских правил обнаружения. Желательно также наличие модуля deception. Deception относится к системам обнаружения вторжений (Intrusion Detection System, IDS), основная цель которых — выявлять попытки нежелательного доступа к сети. Deception помогает обнаруживать сетевые атаки. Первой разработкой технологии deception можно считать Honeypot («горшочек с медом»).

Как уже говорилось, EDR позволяет реагировать на инциденты. Желательно иметь консоль для реагирования в реальном времени. Кроме того, система EDR должна иметь возможность завершать подозрительные процессы и блокировать подозрительные учетные записи. Иногда (в фазе атаки всегда) требуется сетевая изоляция хостов. Также хотелось бы иметь возможность после инцидента удалять файлы — следы вредоносной активности. 

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

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

* * *

Что же выбрать? Я не очень верю, что без применения EDR можно в реальном времени «поймать», скажем, атаку шифровальщика на вашу ИТ-систему. Но, скажут мне, такие решения весьма дороги и ими сложно управлять. Отвечу: да. Можно использовать схему без EDR и попытаться «предугадать» атаку на ранних этапах. 

Я выбрал гибридную схему и работаю пока по ней. В дальнейшем расскажу, как это было.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!