Журнал "Information Security/ Информационная безопасность" #1, 2026

Ключевой момент не в самом факте интеграции, а в смене логики детекти- рования. Речь идет о том, чтобы связать неоднозначные сигналы в цепочку. Ни сетевой индикатор, ни отдельный SQL- запрос поодиночке не являются доказа- тельством утечки. Но вместе они начи- нают складываться в полную картину: откуда пришел запрос, что именно чита- ли, как долго это происходило и куда в итоге ушли данные. Именно в этот момент тихая эксфильтрация превра- щается в процесс с началом, развитием и последствиями. Появляется не просто алерт, а вектор атаки. Есть мнение, что тихую эксфильтра- цию можно обнаружить только пост- фактум, когда ущерб уже частично нане- сен. На практике это верно лишь в тех случаях, когда система защиты не пыта- ется "понять", что для хоста является нормальным. Как только появляется поведенческая модель, временной гори- зонт существенно сокращается. Блокировка – тяжелое решение Возникает вопрос: если мы видим активность с подозрением на эксфильт- рацию, почему просто ее не заблокиро- вать? Вроде бы ответ выглядит просто. Но организационно – это один из самых сложных моментов во всей цепочке. Исторически системы защиты баз дан- ных в большинстве компаний работают в режиме мониторинга. Не потому что они не умеют блокировать, а потому что никто не хочет брать на себя риск. Любая ошибка на этом уровне сразу превращается в инцидент для бизнеса: приложение перестало работать, отчет не сформировался, сервис упал в самый неподходящий момент. И дальше начи- нается хорошо знакомая многим цепочка взаимных претензий между ИТ, ИБ и владельцами процессов. Эта осторожность понятна. Поэтому даже при наличии уверенных сигналов компании часто предпочитают сначала посмотреть еще, собрать больше дан- ных, убедиться, что это не ложное сра- батывание. Проблема в том, что тихая эксфильт- рация как раз и выигрывает от этой паузы. Пока система наблюдает, данные продолжают уходить. И чем аккуратнее работает злоумышленник, тем сложнее принять решение о жестком действии. Здесь нет яркого триггера, нет харак- терного события, после которого все становится очевидно. Блокировка в таких сценариях – вопрос зрелости процессов и доверия к аналитике. Пока у ИБ нет уверенности в том, что система понимает контекст и видит картину целиком, автоматическая реакция будет восприниматься как риск, а не как защита. Даже если эксфильтрацию не удалось остановить на самой ранней стадии, связ- ка DBF и NDR меняет качество после- дующего расследования. Вместо попыток восстановить события по логам появляется связная картина – не просто факт утечки, а понятная последо- вательность дей- ствий. NDR записы- вает все инциденты и сырые сетевые пото- ки, что позволяет пол- ностью реконструиро- вать цепочку атаки. Важный момент здесь в том, что системы – это не источники логов, а полноценные участ- ники расследования. Решения на уровне DBF и NDR могут принимать локальные решения, фиксировать инцидент, блоки- ровать отдельные действия,работать самостоятельно без SIEM, а во внешнюю среду отдавать уже агрегированные инци- денты. Такой подход соответствует кон- цепции XDR – работе с телеметрией средств защиты, а не сырыми логами инфраструктуры. С точки зрения доказательной базы появляется возможность аргументиро- ванно говорить о злонамеренности, а не просто о подозрительной активности. От детекта к активному противодействию Когда базовый детект и расследование начинают работать, довольно быстро возникает следующий вопрос: а что можно сделать дальше, кроме фиксации и блокировки? Связка NDR и DBF здесь открывает пространство для сценариев, которые еще несколько лет назад выгля- дели скорее экспериментальными, чем практическими. Самое очевидное направление – уско- рение реакции. Сегодня многие интег- рации строятся вокруг передачи списков индикаторов и ожидания, пока другая система их обработает. Логика посте- пенно смещается в сторону более пря- мого взаимодействия: если одна сторона уверена в компрометации источника или учетной записи, другая может реагиро- вать практически сразу, без промежу- точных этапов. Дальше начинается работа с самим содержимым данных. Если система пони- мает, что происходит злонамеренная выгрузка, появляется возможность не только остановить процесс, но и повлиять на его дальнейшее развитие. Маркировка данных, добавление скрытых идентифи- каторов, отслеживание утекших копий – все это позволяет увидеть, где и как информация всплывает после выхода за пределы исходного контура. В таких сценариях эксфильтрация становится источником дополнительной аналитики. Еще один логичный шаг – более тесная связка с маскированием и технологиями Deception. Если выявлен подозрительный хост, пользователь или приложение, – можно незаметно перенаправить их к обезличенной среде или в ложный слой инфраструктуры. Злоумышленник про- должает действовать, не подозревая, что его поведение уже находится под контролем, а риск утечки реальных дан- ных при этом исключается. Все эти сценарии не рождаются в лабораториях ради красивых презен- таций. Они появляются из практики, когда заказчик сталкивается с конкрет- ной проблемой и ищет способ не просто закрыть инцидент, а понять, как сделать систему устойчивее к подобным атакам в будущем. Тихая эксфильтрация здесь выступает как драйвер развития – заставляя защиту данных двигаться от пассивного наблюдения к управляемому противодействию. Вместо послесловия Если свести рассуждения к одной мысли, она будет такой: утечки из баз данных давно перестали быть следстви- ем плохих людей или дырявых систем. Гораздо чаще это результат того, что инфраструктура живет по инерции, а данные в ней воспринимаются как статичный ресурс, а не как процесс с поведением, динамикой и рисками. Тихая эксфильтрация неудобна имен- но этим. Она спокойно существует в рам- ках разрешенного – и потому требует от ИБ не быстрых реакций, а вдумчивого взгляда на то, как устроено доверие внутри системы. Кто, зачем и в каком контексте работает с данными, и что происходит после того, как данные поки- дают привычные границы. Связка NDR и DBF в этом смысле – не универсальный ответ и не серебря- ная пуля. Это пример того, как разные уровни защиты данных и сетевой без- опасности начинают дополнять друг друга и закрывать слепые зоны, кото- рые по отдельности они закрыть не могут. И чем раньше такие связи ста- новятся частью архитектуры, а не разо- вой интеграцией под конкретный кейс, тем меньше шансов у эксфильтрации оставаться тихой. l • 57 ТЕХНОЛОГИИ www.itsec.ru На правах рекламы