Почему вопрос «SIEM или XDR» стал ловушкой для бюджета
Лет пять назад на вопрос «чем мониторить ИБ» ответ был один: ставьте SIEM. Потом вендоры дружно переключились на XDR, и теперь на встрече вам показывают «единую платформу расширенного детекта и реагирования» с ценником, который для компании на 200 человек сопоставим с годовым бюджетом отдела разработки. При этом вопрос «что мне реально нужно» подменяется вопросом «какой продукт моднее».
Разберёмся по-честному: где между SIEM и XDR настоящая разница, а где — переупаковка одного и того же в новый акроним. Я не буду советовать конкретный вендор: задача — понять, за что вы платите и что будете делать с этим в понедельник утром.
Что такое SIEM, если убрать маркетинг
SIEM (Security Information and Event Management) — это централизованный сбор и корреляция событий. Три функции, и ничего сверх этого:
- собрать события почти отовсюду — ОС, Active Directory, СУБД, межсетевые экраны, прокси, приложения, средства защиты;
- нормализовать их в единую схему, чтобы попытка входа из Windows и из Linux описывалась одинаково;
- применить правила корреляции и сохранить всё на месяцы вперёд, чтобы можно было вернуться к вопросу «а что вообще было 12 февраля».
Главное: SIEM по своей природе логоцентричен. Он не смотрит в процессы на хосте, не умеет «заглянуть в память» и сам ничего не блокирует. Он отвечает на вопрос «что подозрительное было в потоке событий». Что с этим делать — целиком ваша ответственность.
Что такое XDR и почему это не «SIEM 2.0»
XDR — Extended Detection and Response. Термин вошёл в оборот в конце 2010-х, и за ним стоит довольно простая идея: взять телеметрию не только из логов, но и с конечных точек (EDR), из сети (NDR), почты и облачных сервисов, свести её в один продукт и добавить автоматическую реакцию.
- Глубина вместо ширины. EDR внутри XDR видит процессы, командные строки, загрузку модулей, обращения к реестру — то, чего в логах ОС просто нет.
- Сквозная история. Цепочка «письмо → запуск макроса → обращение к LSASS → исходящее соединение» собирается в одну сущность, а не в пять алертов из пяти систем.
- Реакция, а не только алерт. Изоляция хоста, блокировка хеша, завершение процесса, карантин файла — встроенными средствами.
Слабые места у честного XDR тоже есть: покрытие ограничено тем, что поддерживает вендор. Ваш самописный биллинг, АТС и учётную систему он в лучшем случае не увидит, в худшем — испортит корреляцию своим неполным взглядом на мир.
Четыре отличия, которые реально влияют на выбор
1. Данные: широкий поток логов против глубокой телеметрии
SIEM покупают по объёму: лицензии считают в гигабайтах в сутки или в событиях в секунду (EPS, events per second). XDR — по количеству защищаемых узлов. Отсюда первый практический вывод: если у вас 400 виртуалок, генерирующих гигабайты логов, SIEM обойдётся дороже; если 150 ноутбуков — XDR почти всегда дешевле.
2. Детект: правила против поведенческой аналитики
Классический SIEM — это корреляционные правила, которые пишут руки. Правило «много неуспешных входов с одного IP» ловит брутфорс и не ловит действия легитимной учётки, угнанной через фишинг. XDR опирается на поведение: «текстовый редактор породил PowerShell» — аномалия независимо от того, скомпрометирована учётка или нет. Это не значит, что правила не нужны, — это значит, что их должно быть меньше и они точнее.
3. Реакция: очередь на разбор против кнопки «изолировать»
SIEM выдаёт инцидент в очередь аналитику. Если аналитика нет — инциденты просто копятся, а через месяц вы удалите половину правил, потому что «шумно». XDR умеет отработать по заранее заданному сценарию сам: изолировать хост, заблокировать соединение. Для компании без круглосуточной смены это принципиальная разница.
4. Стоимость сопровождения, а не лицензии
Основные деньги в любом из вариантов уходят не на лицензию, а на людей и контент правил. По опыту проектов внедрения, львиная доля стоимости владения приходится на подключение источников, нормализацию и написание правил, а не на сам продукт. XDR перекладывает часть этой работы на вендора, но взамен вы попадаете в его экосистему и его темп обновлений.
Российская специфика: что учесть отдельно
Если вы субъект КИИ, ГИС или крупный оператор персональных данных, требования ФСТЭК и отраслевых регуляторов прямо влияют на выбор: нужны средства защиты из реестра отечественного ПО, а инциденты подлежат передаче в НКЦКИ в рамках ГосСОПКА. На практике это означает, что мировой лидер рынка, каким бы хорошим он ни был, может не пройти по формальным критериям.
Отечественный рынок здесь догоняет быстро: есть SIEM-платформы и продукты, которые вендоры описывают как XDR, и по части корреляции и интеграции с российской инфраструктурой они уже вполне работоспособны. Но проверяйте не логотип в реестре, а наличие коннекторов под ваши реальные источники — 1С, отечественные СУБД, АБС, СЗИ. Отсутствие коннектора убивает всю пользу от продукта, каким бы красивым ни был дашборд.
Три сценария: что выбрать без дорогого SOC
Сценарий A: до 300 сотрудников, своего ИБ-специалиста нет
Классический SIEM — плохая идея. Вы купите систему, которая генерирует алерты, и не будет никого, кто их разбирает. Разумный путь: EDR или XDR с минимальным покрытием плюс аутсорс мониторинга (MDR/MSSP), где реагирование по регламенту берёт на себя провайдер.
Сценарий B: один-два ИБ-инженера
Комбинация: XDR/EDR как основной инструмент детекта и SIEM как «второй слой» для того, что не покрыто агентами — сеть, АБС, веб-приложения, облака. SIEM здесь нужен конкретный, под ваши источники и под несколько честно написанных правил, а не «чтобы было».
Сценарий C: несколько площадок, парк разросся
Без SIEM не обойтись: инфраструктура слишком разнородная. Но и без XDR вы останетесь в режиме «алертов без рук». Здесь нормально начинать с SIEM и постепенно добавлять XDR-функции, а не наоборот.
Гибрид, который работает чаще всего
Если убрать маркетинг, рабочая схема для среднего бизнеса выглядит так: EDR/XDR на всех конечных точках и серверах как источник качественной телеметрии и быстрой реакции, SIEM — для сетевых и прикладных логов, долгого хранения и разбора сложных цепочек.
Порядок действий при инциденте в такой схеме: XDR изолирует узел и не даёт атаке распространиться; SIEM даёт аналитику контекст — с какой учётки всё началось, куда ходило, что происходило за месяц до этого. Один инструмент без другого даёт либо скорость без контекста, либо контекст без скорости.
Чего не умеет ни SIEM, ни XDR
Обе категории бесполезны против того, что не оставляет телеметрии: ручной работы злоумышленника легитимными инструментами на машине без агента, утечки через сотрудника с легальным доступом, ошибки конфигурации в облаке без журналирования. Ни SIEM, ни XDR не заменят управление уязвимостями, управление доступами и проверяемые резервные копии. Если этих базовых вещей нет, аналитика по логам превратится в чтение протокола собственного падения.
Чек-лист перед подписанием договора
- Выпишите реальные источники данных по именам систем и продуктов, а не «серверы и сеть». Проверьте наличие коннекторов, а не слайды.
- Посчитайте, кто будет разбирать алерты в три часа ночи. Если ответа нет — вам нужен не продукт, а услуга.
- Уточните схему лицензирования: за гигабайты, за EPS или за узлы, и как считается хранение сверх нормы.
- Проверьте, что именно входит в автоматическую реакцию и есть ли «предохранитель»: правило, изолировавшее единственный контроллер домена, стоит дорого.
- Протестируйте на своём стенде один-два сценария по MITRE ATT&CK: не «видит ли он вирусы», а ловит ли конкретную технику.
- Согласуйте требования регулятора до закупки: реестр отечественного ПО, порядок передачи инцидентов в НКЦКИ, отчётность для руководства.
Вывод
SIEM и XDR решают разные задачи: первый — про широкий контекст и историю, второй — про глубину телеметрии и скорость реакции. Для компании без SOC выбирать «чистый SIEM» почти всегда означает купить генератор алертов. Начинайте с того, что закрывает реагирование, а не отчётность, и не берите платформу под будущий отдел из шести аналитиков — этот отдел может не появиться никогда.
