Out of Path | ИБ, ИТ & Телеком

Облако 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 при расследовании инцидентов, так как теряется контекстная привязка алертов к конкретным хостам и пользователям.

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

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

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

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

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

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

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

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

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

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

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

Недавно попалась на глаза интересная публикация от 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

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

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

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

😱 Дипфейки, звонки и фишинг: как мошенники крадут деньги и данные казахстанцев

Мошенники всё чаще не взламывают устройства, а заставляют человека самому передать данные. В ход идут фишинговые ссылки, поддельные сайты, звонки и даже дипфейки, которые имитируют голос и видео знакомых.

Технический директор BESupply Амангельды Кусаинов рассказал, почему люди попадаются на такие схемы, какие данные могут использовать злоумышленники и что поможет защититься.

Какие ошибки мы совершаем сами и как не стать жертвой мошенников — читайте далее на сайте SHYNDYK.KZ 👉🏻

Подписаться | Прислать информацию

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

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

Зачем нужен 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 работает вслепую, поэтому доступ к телеметрии конечных точек – это первый и главный шаг при старте проекта.

В день открытия канала на юге Казахстана случился блэкаут) Символично подметил мой друг и коллега Александр Баитов у себя на канале - https://t.me/TechnologiiIB/133 😄

Благодарю канал SecuriXy.kz за обратную связь! 👍

https://t.me/securixy_kz/1403

Рекомендую потестить тулзу от s0ld13r ch.

https://t.me/s0ld13r_ch/412?single

«Почему SOC не увидел шифровальщика?» – вопрос, который чаще всего задают, когда уже случился инцидент

Пока всё спокойно, никто не спрашивает SOC, что именно он видит, а чего не видит. Вопрос возникает постфактум – когда база уже зашифрована, а объяснить произошедшее нужно было ещё вчера.
Регулярно слышу одну и ту же историю: компания подключается к SOC по предписанию регулятора, для галочки в аудите или потому что «так положено». Экономит на охвате источников. А потом, после инцидента, выясняет отношения с провайдером: «Мы же вам платим! Почему вы это пропустили?!»😱

Разберём по существу – и с той, и с другой стороны.
 
Как это обычно выглядит на практике?
В SOC заводят не критические контроллеры домена, EDR с ключевых хостов и логи бизнес-критичных сервисов, а тестовый сегмент, пару второстепенных Linux-серверов и второстепенный файрвол. Формально требование выполнено, логи идут, отчёт для регулятора готов. Например, по факту в зоне видимости – 5% инфраструктуры.
Дальше – стандартный сценарий: фишинг на бухгалтера или забытый RDP, компрометация учётки на DC, боковое перемещение по сегменту без единого сенсора. Шифровальщик добирается до базы, бизнес встаёт.
 
Что здесь правда, а что – нет?
Правда в том, SOC анализирует только то, что ему дают. Если в зону мониторинга не попали DC, критичные хосты и периметр – задача физически нерешаемая, какой бы сильной ни была команда аналитиков. Это не вопрос компетенций, это вопрос архитектуры покрытия.
Но есть и вторая сторона, о которой честные провайдеры не молчат, если SOC на этапе подключения видит, что заказчик подключает источники-заменители вместо критической инфраструктуры, это должно быть зафиксировано в письменном виде с описанием конкретных рисков и слепых зон. Это должно быть не как формальная отписка в приложении к договору, а как понятный руководству документ: «Вот что вы видите, вот чего не видите, вот что это значит при реальной атаке».
Если этого не сделано – вина уже не только на заказчике.
 
Минимальный чек-лист охвата для реального (не бумажного) SOC:
1. Все контроллеры домена и критичные системы (AD, ADFS, PAM)
2. EDR/XDR на критичных серверах и рабочих станциях с высоким уровнем привилегий.
3. Логи периметра (VPN, публичные сервисы и т.п.).
4. Логи сегментов с критичными данными (БД, ERP, файловые хранилища).
5. Мониторинг и анализ сетевой активности ключевых узлов и сегментов с помощью NTA/NDR.
Если из этого списка закрыто меньше половины – это не MDR и не полноценный мониторинг, это дашборд для отчёта регулятору.
 
Мониторинг работает только тогда, когда видит то, что действительно нужно защищать. Всё остальное – это красивая отчётность до первого реального инцидента.

P.S. Я специально не стал затрагивать сложные таргетированные атаки и APT-группировки – это отдельный разговор. Описал только то, что на поверхности, с чем сталкиваются постоянно и что бьёт по бизнесу больнее всего.

Наблюдается изменение характера DDoS-атак. Во-первых, существенно растёт объем атак, в июле зафиксировали и отразили одну из крупнейших атак типа UDP Flood, пиковая интенсивность превысила 300 Гбит/с. Во-вторых, всё больше заражённых локальных устройств, участвующих в атаках. Системы защиты и ответственные подразделения хорошо отработали.

На днях буквально написал, почему на рынке не востребована глубокая экспертиза, а сегодня регулятор фактически обяжет операторов персональных данных её иметь в связи с грядущими поправками.

Уведомление об утечках и запрет выгрузок требуют контроля уровня L3+ (форензика, Threat Hunting и тд).
Но если продолжить на этом экономить, про компрометацию ПД компания узнает не от своего мониторинга, а из новостей.

Подробности тут https://t.me/telco_kz/1246