Зачем нужен EDR, если SIEM и так всё видит?

Вопрос закономерный. Но SIEM видит ровно то, что ему передают источники. И по умолчанию глубокой телеметрии с хостов там просто нет.
Представьте охрану здания с датчиками дыма в коридорах, но без камер в комнатах. Дым заметят. Кто его устроил - нет.
Здесь же стоит закрыть и второй частый вопрос - про антивирус. EDR – это не просто антивирус, хотя современные NGAV уже умеют проводить поведенческий анализ, и граница между ними не такая строгая, как принято думать. Отличие не в том, что один видит подозрительное поведение, а другой нет, а в глубине видимости и возможностях реагирования. EDR даёт полную телеметрию по каждому процессу, хранит её для расследования и позволяет аналитику действовать удалённо: изолировать хост, завершить процесс или собрать артефакты. Антивирус же останавливается сразу после блокировки файла.
 
Где разница становится критичной:
1. Атакующие всё чаще работают через встроенные утилиты Windows – PowerShell, WMI, Certutil. Это подписанные системные компоненты, которые для сигнатурного детекта не выглядят угрозой, а в логах SIEM отображаются как обычная активность администратора. EDR же восстанавливает полное дерево процессов. Без этой цепочки остаются лишь разрозненные точки, которые аналитику приходится соединять вручную.
2.Мгновенное реагирование тогда, когда в сети разворачивается шифровальщик, счёт идёт на минуты. EDR позволяет в один клик изолировать заражённый хост от сети прямо из консоли, сохраняя при этом связь с агентом для проведения расследования.
3.Ретроспективный анализ и Threat Hunting – возможность ретроспективного анализа телеметрии, то есть это отдельная ключевая фича EDR, подразумевающая хранение сырой истории активности конечных точек. Она позволяет «вернуться назад во времени» и проверить гипотезу. Например, при публикации описания новой техники из MITRE ATT&CK можно прогнать её по всей накопленной телеметрии и найти следы компрометации, которые в момент атаки не подсвечивались алертами. Threat Hunting – это работа не по событиям, а по гипотезам, и без EDR он невозможен в принципе.
 
А еще есть XDR, который добавляет ещё один слой: объединяет телеметрию хостов, сети (NDR/NTA) и почты в единую цепочку инцидента. Вместо десятков разрозненных сработок аналитик получает связную историю атаки, что ощутимо снижает нагрузку на SOC – при условии, что правила корреляции настроены и регулярно актуализируются.
Теперь небольшая оговорка о том, что наличие EDR само по себе ничего не гарантирует. Там, где агент принципиально не установишь (IoT, технологическое оборудование, устаревшие ОС), нужна сетевая видимость (NDR).
 
К тому же телеметрия бесполезна без команды: покрытие хостов, качество детектов и квалификация аналитиков решают не меньше самого инструмента. Для компаний без своего SOC разумной альтернативой остаётся Managed EDR/MDR – тот же уровень видимости, но с внешней экспертизой.
 
В итоге получается, что SIEM фиксирует событие, а EDR/XDR дает контекст и возможность остановить атаку в один клик. В эпоху размытия граней между SIEM и XDR важны не ярлыки вендоров, а реальная видимость хостов. Без нее любой SOC работает вслепую, поэтому доступ к телеметрии конечных точек – это первый и главный шаг при старте проекта.

Кстати, алгоритмы ИИ активно применяются в решениях EDR/XDR для первичного анализа телеметрии с конечных точек.

Коллега по отрасли написал как раз с своем посте
https://t.me/Cyb3rSecKz/64

🔐 Сентябрь в Казахстане объявили месяцем кибербезопасности

Такую инициативу действительно нужно поддержать.

Весь месяц по стране будут идти мероприятия по кибербезопасности: для обычных пользователей, школьников и студентов, бизнеса и специалистов. Темы вполне жизненные: фишинг, интернет-мошенничество, защита персональных данных, ЭЦП, deepfake, цифровая и финансовая грамотность.

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

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

А еще министерство запустило довольно симпатичный конкурс. Нужно снять вертикальный ролик до 60 секунд на тему киберкультуры или кибербезопасности и выложить его в Instagram. Темы можно брать любые: персональные данные, безопасные пароли, мошенничество, deepfake, цифровая гигиена и так далее.

Работы принимают до 20 сентября, потом организаторы отберут 12 финалистов, а победителей выберут открытым голосованием. В итоге будет шесть призов: два ноутбука, два планшета и два смартфона.

Так что коллегам из телекома и IT я бы тоже предложил подключиться. У операторов есть сайты, приложения, личные кабинеты, соцсети, офисы и, главное, миллионы контактов с абонентами. Иногда один вовремя увиденный совет полезнее очень дорогой системы защиты.

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

Материалы месяца:
https://www.instagram.com/p/Dcx4zeeDVZr/?igsi=Zzk5aGlyeTJyNmJu

Конкурс:
https://www.instagram.com/p/DcvjyibDQg8/?igsi=Y2RhbmhncXhxM3Jt

Памятка:
https://www.instagram.com/p/Dc234FpDZm4/?igsi=ZzlnaDFncDlyaGc5

Недавно попалась на глаза интересная публикация от Elastic, и я поймал себя на мысли, что тема Observability vs Security до сих пор остаётся одной из самых недооценённых слепых зон в архитектуре многих SOC и ИТ-блоков.

Захотелось поделиться своим мнением на этот счёт.

Если очистить термины от маркетинга, обе системы смотрят на одну и ту же инфраструктуру, но из разных сторон:
Observability (ИТ-наблюдаемость) - это врач скорой помощи. Ей важен пульс и давление системы: чтобы ничего не «падало», CPU не грелся, а сервисы откликались быстро.
Задаётся вопросом: «Почему всё тормозит?» - и стремится решить проблему как можно быстрее.
 
Security Monitoring (Мониторинг ИБ) - это детектив. Ему не так важна производительность, ему важен умысел.
Задаётся вопросом: «Кто это сделал и куда утекают данные?», то есть разбирает ситуацию с точки зрения причинно-следственной связи.
 
В чём главный конфликт и где кроются риски?
На практике эти два направления почти всегда разведены по разным платформам и командам. В итоге мы получаем две классические проблемы:
1.Экономическая: компании дважды платят за обработку и хранение одних и тех же данных (Syslog, NetFlow, DNS) в двух разных «корзинах».
2.Операционная (самая опасная): атаки сегодня идеально маскируются под обычный инфраструктурный шум.

Классический кейс из статьи Elastic: ночью у сервера взлетает CPU до 97%. Дежурный инженер IT/DevOps заходит в консоль мониторинга, видит аномальную нагрузку, перезагружает хост и со спокойной душой закрывает тикет со статусом «Resolved».
А что на самом деле? За 6 часов до этого туда задеплоили майнер, замаскированный под системный поток ядра. В итоге ИТ отчиталось об устранении сбоя, Security вообще ничего не узнало, а хакеры спокойно продолжают крутить свои процессы.

Резюмируя, можно сказать следующее:
Observability отвечает на вопрос «Система жива?», а Security - «Систему не взломали?». Пока они живут в разных системах, мы видим только половину картины. Общий контекст - это не просто экономия на хранении логов, это единственная возможность оперативно выявить и заблокировать атаку до того, как она превратится в инцидент.

Ссылка на ту самую статью Elastic: elastic.co/blog

Интересная презентация, которая демонстрирует стратегическую трансформацию Казахстана из простого географического транзитного коридора в ключевой цифровой агрегационный узел региона и, возможно, всего Евразийского континента.
 
Развитие магистральной сети, описанное в документе, выводит сетевую связность на качественно новый уровень.
 
На мой взгляд, параллельное выведение из эксплуатации устаревших медных и 3G/CDMA-сетей вместе с переходом магистралей на 400G/800G и Telemetry-управление дает синергетический эффект:

1.Общее снижение OPEX-а на эксплуатацию физически и морально устаревшего оборудования/технологий.

2.Повышение качества услуг, за счет перехода с медных сетей на оптику (GPON) и телеметрический контроль микровсплесков исключают «просадки» скорости и задержки у конечных пользователей и корпоративных клиентов.

3.Готовность к высоким нагрузкам магистральных сетей, которые становятся способны без задержек прокачивать трафик от AI-кластеров («Долина ЦОД»), спутниковых сетей (Amazon LEO) и транзитных потоков Европа - Азия.

Вот ссылка на саму презентацию на канале у Олега Емельянова - https://t.me/telco_kz/1283

Radware Threat Report H1 2026: Главное из отчета по киберугрозам
 
Radware выпустила отчет об угрозах за первое полугодие 2026 года. Главный вывод – атаки развиваются быстрее, чем успевает реагировать традиционная защита. Ниже приведен разбор ключевых показателей и трендов.
 
Патч-окна больше не существует
Среднее время от публикации CVE до первой эксплуатации в реальном мире ушло в минус и составляет -8 часов. Уязвимости массово эксплуатируются до того, как о них становится известно вендорам. Доля Zero-Day атак превысила 80%. Для сравнения: в 2024 году среднее время эксплуатации составляло 53 дня, а доля Zero-Day –48%.
 
DdoS-атаки обновляет максимумы
- Web DDoS: рост на 111% год к году. За первые 6 месяцев 2026 года зафиксировано 83% от всего объема атак 2025 года. Прогноз на весь год –рост на 166%.
- Сетевой DDoS: в среднем 110 атак в сутки на клиента (+37% к 2025 году). Атакующие уходят от механизмов reflection и amplification в сторону прямых UDP-флудов, которые составляют 73% всего трафика атак.
- География: Северная Америка лидирует по объему (43% сетевых атак), однако наиболее резкий рост зафиксирован на Ближнем Востоке –с 9 до 520 атак в сутки на клиента.
- Целевые секторы: наибольшему числу атак подвержены технологический сектор (59% сетевых атак) и финансовые организации (21%).
 
Приложения и API под увеличенным давлением
Вредоносный трафик к веб-приложениям и API увеличился в два раза: фиксируется более 14 000 вредоносных транзакций в день на приложение (+104%). 62% всех атак приходится на эксплуатацию уязвимостей. Активность вредоносных ботов за полугодие составила 59% от общего объема за весь 2025 год.

Влияние искусственного интеллекта на атаки
- Локальные агенты с функцией heartbeat работают в фоновом режиме на устройствах и автономно изменяют собственную логику. При возникновении ошибок пользователей склоняют к предоставлению им полных прав в системе, что нивелирует изолированность песочниц.
- AI-агенты для разработки выступают автоматическими установщиками вредоносного ПО, загружая скомпрометированные зависимости (в качестве примера приводятся атаки Mini Shai-Hulud на менеджер пакетов npm, затронувшие инфраструктуру OpenAI).
- Модели уровня Claude Mythos способны находить и связывать уязвимости в сложные цепочки атак, пропускавшиеся экспертами на протяжении десятилетий (включая 27-летнюю уязвимость в TCP-стеке OpenBSD).
- Накопление Zero-Day уязвимостей теряет экономический смысл: ИИ снижает эксклюзивность находок, а развитие модели Crime-as-a-Service делает инструменты уровня APT доступными по подписке.
     
Геополитический хактивизм
Европа (48%) и Ближний Восток (26%) остаются основными регионами атак хактивистов. Израиль является наиболее атакуемой страной (17% от всех заявлений об атаках). На группировку NoName057(16) приходится 40% всех публично заявленных атак.
 
Внутренние слепые зоны организаций
Данные опроса 377 организаций, проведенного Osterman Research для Radware:
· Компании, внедряющие AI-агентов: 77%
· Компании, имеющие полную видимость действий своих AI-агентов: 17%
· Компании, обновляющие production API один раз в неделю и чаще: 81%
· Компании, имеющие полную документацию собственных API: 7%
Вывод
Реактивная защита периметра перестает быть эффективной: угрозы скрываются внутри внешне легитимных, но высокоскоростных автоматизированных транзакций. Требуется переход к поведенческой аналитике в реальном времени, автоматизированному управлению поверхностью атаки и контролю последовательности действий систем.

Источник: Radware H1 2026 Global Threat Analysis Report

В одной индийской деревне жители жаловались на плохое покрытие 5G. Они попросили телеком-компанию прислать сотрудника, чтобы тот решил проблему. Когда он приехал, его привязали к вышке и сказали, что не отпустят, пока сеть не станет лучше.

Канал «Связано!» отношения к этому кейсу не имеет.

На сегодняшнем Fortinet Security Day был интересный доклад ГТС о развитии ЕШДИ. Самое важное для операторов: модель постепенно меняется от полностью централизованной к более распределенной. Теперь оператор может поставить собственный комплекс ЕШДИ в своем регионе, передать его под управление ГТС и пропускать через него трафик своих клиентов, без дорогостоящей «петли» через Астану.

Хороший пример того, как изменение закона довольно быстро превращается в работающую инфраструктуру.

Облако vs on-prem EDR: тема, которая не утихает в отрасли - и в Казахстане особенно
 
Один из самых частых вопросов, которые всплывают в профессиональных чатах и на встречах ИБ-сообщества: что ставить - облачный EDR или он-прем? Дискуссия идёт годами и в мировой отрасли, но в Казахстане у неё есть своя специфика - местное законодательство добавляет переменные, которых нет в типовых зарубежных гайдах.
 
Почему в РК это не просто вопрос вкуса
ЕТ (единые требования в сферах цифровизации и обеспечения кибербезопасности, пост. Правительства № 832) обязательны для госорганов, местных исполнительных органов, госюрлиц, субъектов квазигоссектора и владельцев КВЦО (критически важных цифровых объектов - по старой терминологии КВОИКИ, критически важных объектов информационно-коммуникационной инфраструктуры). Это первое, из-за чего дискуссия «облако или on-prem» у нас звучит иначе, чем в статьях зарубежных вендоров.
 
Где обязана находиться инфраструктура
С 2026 года закреплено: ЦОД, где размещаются государственные цифровые данные, данные ограниченного доступа или КВЦО, обязаны находиться на территории РК. Цифровые объекты (бывшие «объекты информатизации») на площадках «цифрового правительства» и КВЦО проходят обязательные испытания на соответствие требованиям кибербезопасности.
 
Отсюда и растёт главный спорный вопрос: запрещён ли облачный EDR госструктурам?
Формального запрета на слово «облако» в законе нет - и именно поэтому спор продолжается: одни трактуют это как «можно», другие указывают, что телеметрия, улетающая на зарубежные серверы вендора, прямо конфликтует с требованием локализации КВЦО и госданных. На практике для ГО и владельцев КВЦО рабочими остаются on-prem либо облако на казахстанском ЦОД, с продуктом, прошедшим испытания.
 
Второй горячий момент дискуссии: а вообще передаёт ли EDR персональные данные?
Телеметрия EDR - это хэши файлов и процессов, IP-адреса, hostname, логин учётки, иногда сами файлы в карантине. ФИО и ИИН там обычно нет - и именно этот нюанс с 25 августа 2026 года получил юридическое основание.

Закон № 326-VIII закрепил в статье 6 закрытый перечень идентификаторов персональных данных - ФИО в совокупности, ИИН, изображение лица, биометрический вектор лица. Стандартная техническая телеметрия под этот перечень формально не подпадает, если консоль EDR не подтягивает ФИО/ИИН из HR/AD.
Закон также впервые развёл обезличивание (данные теоретически можно связать с субъектом) и новую анонимизацию - необратимое преобразование, после которого связь с субъектом восстановить нельзя в принципе. Хэш логина без соли - это обезличивание, не анонимизация: он всё ещё сопоставим с AD.
 
Что из этого следует - и почему спор не закрыт
- Для бизнеса без интеграции с госсистемами и статуса КВЦО появляется веский аргумент, что типовая телеметрия EDR - это не персональные данные. Облачный EDR становится более защищённым выбором с точки зрения комплаенса.
- Для ГО и владельцев КВЦО: локализация ЦОД действует независимо от статуса телеметрии - облако возможно только на казахстанской инфраструктуре с продуктом, прошедшим испытания.
- Настоящая анонимизация телеметрии юридически чище, но критически снижает практическую ценность EDR при расследовании инцидентов, так как теряется контекстная привязка алертов к конкретным хостам и пользователям.

Именно поэтому вопрос регулярно поднимается на профильных площадках Казахстана: законодательство задает лишь общий вектор, оставляя выбор и обоснование конкретных архитектурных решений на усмотрение самих организаций - с учетом их принадлежности к ГО, КВЦО или частному сектору