EDR вместо антивируса: выбор и внедрение на 500+ ПК

Почему одного антивируса уже не хватает

Классический антивирус хорошо ловит известные вредоносные файлы: то, что уже попало в базы сигнатур или похоже на типичный вирус. Но реальные инциденты на рабочих местах все чаще устроены иначе. Злоумышленнику не обязательно приносить на ПК «очевидный» файл-вредонос. Ему важнее получить доступ, закрепиться и тихо двигаться дальше.

Большинство проблем начинается с простых вещей: письмо «от бухгалтерии» с фишинговой ссылкой, документ с макросом, запуск легитимной утилиты (PowerShell, средства удаленного администрирования, архиваторы). На уровне антивируса это часто выглядит как обычная работа пользователя. А последствия проявляются позже: украденные пароли, доступ к почте, изменения в настройках, утечки.

Когда парк растет до 500+ ПК и появляются филиалы, быстро собрать картину становится сложнее. Разные версии ОС, разный софт, пользователи работают удаленно, а ИТ не видит, что происходило на конкретной машине до инцидента и после. В итоге расследование превращается в «догадки по остаткам»: логов мало, контекста нет, время уходит.

Особенно опасны «тихие» атаки без явного вредоносного файла (fileless). Антивирус может ничего не найти, потому что вредонос здесь - это цепочка действий:

• пользователь вводит пароль на поддельной странице;
• злоумышленник заходит под легитимной учетной записью;
• запускает встроенные инструменты Windows;
• перемещается по сети (lateral movement) к более ценным системам.

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

EDR простыми словами: что это и что он делает

EDR можно представить как «черный ящик» для компьютеров. Он не просто ищет известные вирусы, а фиксирует, что происходит на рабочей станции, и помогает быстро понять, где началась атака и куда она пошла дальше. При этом EDR и классический антивирус часто работают вместе: AV остается базовым слоем, а EDR дает контекст и управляемую реакцию.

EDR собирает цепочки событий: какие процессы запускались, какие файлы создавались и менялись, какие команды выполнялись, куда шли сетевые подключения, какие учетные записи использовались. Главное отличие - это связанная история, а не отдельные «сигналы». Например: письмо > запуск документа > появление PowerShell > скачивание файла > попытка закрепиться в автозагрузке.

На практике «обнаружение» означает, что EDR отмечает подозрительное поведение, даже если файл новый и без сигнатуры. «Реагирование» - это действия из консоли: изоляция ПК от сети, остановка процесса, карантин файла, сбор артефактов для расследования, запуск проверки.

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

Но у EDR есть границы. Он не заменяет обновления, резервные копии и контроль прав. Он не «чинит» процессы сам по себе и может давать ложные срабатывания, если политики настроены грубо. А на 500+ ПК успех часто упирается не в установку агента, а в то, кто и как ежедневно разбирает алерты.

Цели и границы проекта: что именно вы хотите улучшить

Переходя к EDR, начните не с выбора вендора, а с ответа на вопрос: какой результат вам нужен через 2-3 месяца. Без этого пилот превращается в накопление случайных алертов и споры про настройки.

Хорошая практика - зафиксировать 5-8 целей, измеримых и понятных ИТ и бизнесу. Например: сократить время обнаружения (MTTD) и реакции (MTTR), повысить видимость запуска процессов и источников исполняемых файлов, научиться быстро изолировать хост без отключения всей сети, навести порядок в запуске скриптов и утилит, получить единый контур расследования по пользователю и ПК.

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

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

Сразу же договоритесь о критериях успеха пилота и о сроке решения:

• покрытие: какой процент ПК и каких ролей включен;
• качество: доля ложных срабатываний и время на разбор;
• эффективность: сколько инцидентов выявлено и как быстро закрыто;
• решение: дата выбора продукта и план масштабирования.

Критерии выбора EDR для парка 500+ ПК

Когда парк переваливает за 500 устройств, EDR выбирают не по презентации, а по тому, как он ведет себя в эксплуатации: на рабочих станциях, ноутбуках, в филиалах и при сетевых ограничениях.

Сначала проверьте покрытие. Агент должен уверенно работать на вашей версии Windows (и других ОС, если они есть). Для ноутбуков важен офлайн-режим: события копятся локально и догружаются при появлении связи. Это критично для командировок и выездных сотрудников.

Дальше - удобство расследований. Хороший EDR дает понятную карточку инцидента: что произошло, на каком хосте, какая цепочка событий привела к срабатыванию, и быстрый поиск по всем устройствам. Если на разбор одного алерта уходит 30-40 минут, на масштабе 500+ вы упретесь в очереди.

Практичный минимум критериев:

• быстрые действия реагирования: изоляция хоста, завершение процесса, карантин, сбор артефактов;
• интеграции с AD, почтой, SIEM и тикет-системой (хотя бы через готовые коннекторы);
• понятное лицензирование и прогнозируемая стоимость при росте парка;
• низкая нагрузка на ПК и прозрачные требования к сети и обновлениям;
• отчетность для руководства: метрики по инцидентам, времени реакции, покрытию и исключениям.

Полезный тест перед покупкой: возьмите 10-20 типовых ПК (офисные станции и несколько ноутбуков) и проверьте, не ломаются ли бизнес-приложения и не растет ли число обращений в поддержку. Если парк собран на одинаковых моделях (например, корпоративные ПК и моноблоки одной линейки), оценить нагрузку и совместимость проще.

Подготовка перед пилотом: данные, доступы, коммуникации

Пилот часто проваливается не из-за продукта, а из-за неподготовленного окружения. Перед внедрением EDR соберите базовые данные: что защищаем, кто управляет, как изменения дойдут до пользователей.

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

Дальше - права и доступы. Решите, кто ставит агент и кто имеет право менять политики. Частая проблема - локальные админы у пользователей. На пилоте это приводит к отключению агента, конфликтам с драйверами и спору «кто виноват». Лучше сразу зафиксировать: кому разрешены админ-права, как это контролируется, и что делать, если установка требует временного повышения привилегий.

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

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

Пример: у компании в Казахстане есть головной офис и 6 филиалов на VPN. В пилот берут 50 ПК из бухгалтерии и контакт-центра, плюс 5 «сложных» машин с редким софтом. Параллельно согласуют с ИБ и ИТ окно внедрения и правила для локальных админов. Это экономит недели споров уже на второй неделе.

Пилот EDR: пошаговый план на 4-6 недель

Пилот нужен, чтобы проверить EDR в реальной жизни: не на «идеальном» стенде, а на типичных ПК, с привычными программами и людьми. Для парка 500+ устройств хороший пилот экономит недели споров и снижает риск остановки процессов при масштабировании.

Стартуйте с группы 30-80 ПК. Важно, чтобы там были разные роли (бухгалтерия, продажи, ИТ, руководители), разные типы устройств (ноутбуки и стационарные), и несколько филиалов, если они есть. Так вы быстрее увидите, где политики «цепляются» за особенности среды.

Неделя за неделей

• Неделя 1: согласуйте сценарии проверки и критерии успеха, назначьте ответственных, подготовьте доступы и окно для установки агента.
• Неделя 2: разверните агенты, включите сбор телеметрии, настройте базовые оповещения без жестких блокировок.
• Неделя 3: проведите контролируемые проверки по сценариям (подозрительные вложения, PowerShell, подключение USB, попытки доступа по RDP), фиксируйте, что сработало и где мешает работе.
• Неделя 4: разберите события за первые 1-2 недели, отделите «шум» от реальных рисков, составьте список исключений и уточнений правил.
• Неделя 5-6 (по необходимости): внесите изменения в политики, повторите проверки, зафиксируйте улучшения и остаточные проблемы.

Держите короткий ритм между неделями: 2-3 встречи по 30 минут, чтобы не копить спорные срабатывания.

Что должно выйти на финале

• согласованные политики и исключения с владельцами;
• оценка ложных срабатываний и времени реакции ИТ;
• решение о масштабировании и план раскатки волнами по подразделениям.

Настройка политик: как не сломать рабочие процессы

Внедрение EDR часто «ломается» не на установке агента, а на политиках. Лучший старт - режим наблюдения: минимум блокировок, максимум видимости. Первые 1-2 недели соберите факты: какие процессы запускаются, какие скрипты и драйверы реально нужны, какие админские действия происходят каждый день.

Дальше вводите «кольца» развертывания, чтобы ошибки не разлетелись на весь парк:

• пилот: ИТ и несколько сильных пользователей, готовых к обратной связи;
• расширенная группа: 10-20% ПК из разных отделов и филиалов;
• весь парк: только после правок по итогам предыдущего кольца.

Политики лучше делать по ролям, а не «одна на всех». Обычно хватает 4-5 профилей: офисные ПК, разработка, администраторы, киоски или терминалы, ноутбуки сотрудников в разъездах. Для каждого профиля заранее решите, что только детектируется, а что блокируется сразу (например, запуск неизвестных исполняемых файлов из временных папок).

Исключения вводите как управляемый процесс. Простое правило: исключение делается только по заявке, у него есть владелец приложения и срок пересмотра. Если «просто добавить в белый список», эффект от EDR быстро пропадет.

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

Как снизить число ложных срабатываний без потери защиты

После запуска почти всегда кажется, что «сигналов слишком много». Это нормально: EDR видит больше, чем антивирус, и в первые недели ему нужно помочь отличать атаку от особенностей вашей среды. Иначе команда устанет и начнет игнорировать важные события.

Начните с простой классификации алертов по смыслу и реакции:

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

Дальше аккуратно работайте с исключениями. «Белый список» должен быть точечным: лучше разрешить конкретный файл по хэшу или по цифровой подписи издателя, чем отключать целый класс детекций. Исключение по пути удобно, но опасно, если в эту папку могут писать обычные пользователи. По издателю безопаснее, если вы доверяете цепочке поставки и обновлениям.

Сильно снижает шум подавление повторов и группировка похожих событий. Если на 200 рабочих местах один и тот же агент фиксирует одинаковое действие каждые 5 минут, оператору нужен не поток из тысяч алертов, а один инцидент с масштабом и понятной сводкой.

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

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

Операционная модель: роли, регламенты и метрики

EDR дает пользу только тогда, когда понятно, кто и как реагирует на события. Иначе алерты копятся, пользователи злятся из-за блокировок, а ИТ начинает отключать защиту, чтобы «не мешало».

Роли: кто за что отвечает

В небольших командах роли могут совмещаться, но ответственность лучше закрепить заранее:

• ИТ-администраторы: установка агента, обновления, исключения по согласованию, устранение причин (патчи, права, настройки).
• Инфобез: правила детекта, приоритизация инцидентов, решение об изоляции, согласование исключений.
• SOC (внутренний или внешний): мониторинг 24/7, первичный разбор (triage), сбор фактов и рекомендации.
• Service desk: коммуникации с пользователем, тикеты, контроль восстановления доступа.
• Владельцы бизнес-систем: подтверждают критичность узлов и допустимые окна простоя.

После распределения ролей нужен короткий регламент на 1-2 страницы. Например: что делать, если ПК изолирован. Кто уведомляет пользователя, как выдать временный доступ к почте, кто снимает изоляцию и при каких условиях (скан чистый, пароли сброшены, уязвимость закрыта).

Шаблоны реакций и метрики

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

Чтобы понимать, что система работает, достаточно 3-4 метрик:

• время до подтверждения инцидента и время до сдерживания;
• доля ложных срабатываний по критическим правилам;
• повторяемость инцидентов (одна и та же причина снова и снова);
• доля устройств с актуальным агентом и политиками.

Если проект делается с интегратором (так часто бывает при построении защищенной инфраструктуры), попросите оформить роли, регламенты и метрики как часть пилота, а не «когда-нибудь потом».

Обучение ИТ и пользователей: чтобы EDR реально работал

EDR помогает только когда люди понимают, что они видят в консоли и что делать дальше. Иначе команда тонет в алертах, а пользователи получают запреты «ни за что». Обучение лучше планировать как часть пилота.

Мини-обучение для ИТ

Для второй линии и администраторов достаточно практического блока на 2-3 часа с работой в системе. Цель - уверенно сделать первичный разбор и принять решение: игнорировать, ограничить, расследовать, эскалировать.

Полезный минимум:

• как устроена консоль: устройства, инциденты, политики, исключения;
• разбор алерта за 5 минут: процесс, родитель, пользователь, время, сетевые контакты;
• базовые расследования: цепочка процессов, артефакты, что собрать для ИБ;
• эскалация: когда нужен SOC/ИБ и какие данные передать;
• безопасная работа с исключениями: кто согласует и на какой срок.

Первая линия и сотрудники

Первая линия должна уметь принять заявку без паники и без «выключите EDR». Дайте им готовые скрипты: какие вопросы задать, как объяснить блокировку, как быстро понять, это рабочая программа или реальная угроза.

Для сотрудников достаточно памятки на одну страницу: что может измениться на ПК (иногда всплывают окна, возможна блокировка файла), что делать при подозрении (не закрывать уведомление, не перезапускать «до исчезновения», сразу сообщить в Service Desk), какие ситуации особенно важны (письмо с вложением, странный запуск, неожиданный запрос пароля).

Закрепите обучение тренировкой на тестовой группе: 2-3 заранее подготовленных инцидента (подозрительный PowerShell, запуск неизвестного exe, фишинговое вложение). После каждого разбора обновляйте инструкции и пороги уведомлений, чтобы в продуктиве было меньше шума.

Пример сценария внедрения на 500+ ПК: как это выглядит вживую

Средняя компания: около 700 рабочих станций, 6 филиалов, часть сотрудников работает с ноутбуков и периодически выходит из офиса. Антивирус стоит давно, но инциденты все равно случаются, а понять, что именно произошло на ПК, трудно. Команда решает внедрять EDR аккуратно, без остановки работы.

Пилот делают небольшим, но показательным: 60 ПК из финансов, HR, администраторов и один филиал. Первые 2 недели - режим наблюдения. Задача простая: собрать картину поведения, понять, что будет «шуметь», и не ломать процессы.

Типовые находки повторяются почти всегда. Всплывают админские скрипты и утилиты, которые раньше никто не описывал. На части ПК находятся старые автозапуски и остатки софта от подрядчиков. Пару раз срабатывает защита на подозрительные вложения из почты, но выясняется: часть писем легитимная, просто с агрессивными макросами.

После этого делают тюнинг: около 10-15 исключений, и у каждого появляется владелец (кто отвечает и зачем это нужно). Для бухгалтерии и админов политики, наоборот, ужесточают: больше контроля над запуском утилит и скриптов.

Дальше раскатка идет волнами - по 150 ПК в неделю. Каждую волну оценивают по метрикам:

• число алертов на 100 ПК;
• доля ложных срабатываний;
• время реакции ИТ;
• количество обращений в поддержку.

Если метрики «поплыли», следующую волну ставят на паузу и правят политики, а не закрывают все подряд широкими исключениями.

Короткий чек-лист перед стартом и после запуска

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

Перед стартом (до закупки и до пилота)

Потратьте 1-2 встречи на согласование базовых вещей. Это меньше, чем время на разбор хаоса после первых блокировок.

• Сформулируйте 2-3 цели в измеримом виде (например, время реакции на инцидент, доля покрытых ПК, снижение «шума») и назначьте владельцев со стороны ИБ и ИТ.
• Выберите пилотную группу: 50-150 ПК, разные роли (бухгалтерия, разработка, колл-центр, руководители) и 1-2 «капризных» приложения.
• Соберите инвентарь: ОС, версии, критичные приложения, VPN, VDI, админ-инструменты. Отдельно отметьте компьютеры и серверы, которые нельзя перезагружать в рабочее время.
• Подготовьте доступы и границы: кто ставит агент, кто видит консоль, кто утверждает исключения, кто имеет право изолировать хост.
• Сделайте план отката: как быстро отключить политики или удалить агент, и как объяснить пользователям, что делать при блокировке.

После запуска (и при масштабировании)

Когда пилот дал понятные результаты, важнее всего превратить настройки в повторяемый процесс, а не в «героизм» отдельных специалистов.

• Введите еженедельный тюнинг: разбор топ-алертов, добавление правил, закрытие «дыр» в покрытии, проверка производительности на типовых ПК.
• Ведите журнал исключений: кто запросил, причина, срок действия, что проверили перед добавлением. Раз в месяц пересматривайте и удаляйте устаревшие.
• Согласуйте короткие регламенты: как эскалировать инцидент, когда изолировать устройство, как возвращать в сеть, какие сроки реакции.
• Обучите ИТ и первую линию поддержки: типовые симптомы, что считать инцидентом, какие данные собирать до передачи в ИБ.
• Настройте отчетность для руководства: 3-5 метрик (покрытие, MTTD/MTTR, доля ложных срабатываний, число критичных инцидентов) и фиксированный день отчета.

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

Следующие шаги: как перейти от пилота к стабильной эксплуатации

После пилота легко застрять в состоянии «вроде работает, но запускать страшно». Чтобы EDR стал нормальной операционной практикой, нужен короткий план перехода и понятные владельцы.

Зафиксируйте, что именно проверили в пилоте: какие отделы и типы ПК, какие сценарии атак, какие интеграции (почта, AD, тикеты). Отдельно соберите список критичных приложений и процессов, которые нельзя ломать: бухгалтерия, медицинские системы, гос-ИС, спецдрайверы, удаленные рабочие места. Для каждого пункта назначьте владельца (ИТ, безопасность, бизнес) и срок решения.

Дальше помогает простой маршрут из пяти шагов:

• утвердить критерии готовности: какие метрики считаются нормой (время реакции, доля ложных срабатываний, покрытие устройств);
• запланировать ресурсы на разбор событий: минимум 1-2 ответственных на ежедневный первичный разбор в первые недели;
• составить план внедрения по волнам (например, 10%, затем 30%, затем остальной парк) с окном отката;
• описать правила исключений: кто может запросить, кто одобряет, на какой срок, как пересматривается;
• обновить регламенты: что делать при блокировке, как эскалировать инцидент, как вести учет решений.

Хороший признак зрелости - когда исключения не копятся годами, а пересматриваются по расписанию, и у каждого есть причина и срок действия.

Если нужна помощь в проектировании, внедрении и поддержке, GSE.kz (gse.kz) может подключиться как системный интегратор: помочь подготовить инфраструктуру, организовать внедрение и обеспечить 24/7 поддержку по корпоративным требованиям, чтобы переход от пилота к эксплуатации не держался на одном перегруженном специалисте.