ITSec_articles

Шесть тревожных сигналов из жизни ЦОДа. Круглый стол экспертов

Редакция журнала "Информационная безопасность" — Thu, 30 Apr 2026 12:56:39 GMT

В инфраструктуре ЦОДов многие проблемы безопасности проявляются через обычные на первый взгляд ситуации. Но за такими эпизодами часто стоят системные архитектурные проблемы. Мы предложили экспертам разобрать несколько подобных сценариев и объяснить, какие риски и ошибки инфраструктуры они могут скрывать.

Эксперты:

Иван Барановский, руководитель группы поддержки продаж, “АйТи Бастион”
Алексей Карабась, эксперт, инженер в ЦОД
Владислав Шелепов, аналитик угроз GSOC компании “Газинформсервис”

Во время расследования инцидента выясняется, что часть серверов и сервисов в инфраструктуре ЦОДа вообще отсутствует в системе учета активов.

Иван Барановский, "АйТи Бастион"

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

Сможет ли ИИ думать как белый хакер?

Виктор Минин — Thu, 30 Apr 2026 12:46:24 GMT

Уважаемые СМИ, в том числе иностранные, в начале 2026 г. сообщили о том, что искусственный интеллект научился выявлять уязвимости быстрее человека. Неужели специалистов по тестированию на проникновение скоро заменит ИИ?

Авторы:
Виктор Минин, председатель правления АРСИБ, руководитель направления “Цифровой наставник” Всероссийского общественного движения наставников детей и молодежи
Георгий Песчанских, д.э.н., к.ф.-м.н., профессор математики и ИТ, доцент кафедры специальных дисциплин

Вспомним, что роботизация началась с передачи машинам однообразных операций, ранее выполнявшихся человеком у станка. Роботы действовали по заданной программе, воспроизводя описанную последовательность действий. Когда станки объединились в сборочные линии, управление ими сосредоточилось в вычислительных системах, которые постепенно стали использоваться не только для производственных операций, но и для обработки информации и управления бизнес-процессами.

Следующим этапом стало появление нейросетей. В отличие от традиционного программирования, здесь алгоритм не задается напрямую – систему обучают на примерах. Такой подход напоминает обучение человека и породил представление о новом эволюционном скачке – появлении искусственного интеллекта, способного к самостоятельному развитию. Однако этот этап принципиально отличается от предыдущих. Замене человека станком с числовым программным управлением предшествовала длительная подготовительная работа: действия рабочего изучались, описывались и оптимизировались, после чего переводились в программный код.

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

Возможности ИИ ограничены

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

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

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

Пример таможни

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

Одним из способов выявления новых схем может быть случайный досмотр части безрисковых партий. Однако и к таким механизмам злоумышленники способны адаптироваться.

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

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

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

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

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

Практическая основа для подобной интеграции уже существует. Российская система межведомственного электронного взаимодействия (СМЭВ) показывает, что объединение информационных ресурсов различных государственных органов технически возможно. Разработка принципов совместной работы таких нейросетей могла бы стать одной из задач национального плана развития искусственного интеллекта.

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

На этом можно завершить пример с таможней и вернуться к основной теме – применению ИИ в тестировании на проникновение.

Симбиоз пентестера и ИИ

Особенностью подготовки специалистов по тестированию на проникновение являются практико-ориентированные соревнования CTF (Capture the Flag). В них команды участников анализируют программный код, ищут уязвимости, атакуют системы соперников и защищаются от их атак. По сути такие соревнования моделируют реальную практику проведения тестов на проникновение.

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

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

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

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

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

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

Что для этого должно измениться?

Почему деятельность таможни удалось алгоритмизировать и использовать в ней технологии ИИ, а тестирование на проникновение – нет? Дело не в сложности задач. Работа таможенных органов подробно описана в нормативных актах и регламентирующих документах. Именно эти документы сформировали четкие алгоритмы действий, благодаря которым многие таможенные процедуры удалось автоматизировать.

С тестированием на проникновение ситуация иная. Несмотря на высокий спрос на такие услуги, нормативное описание профессии фактически отсутствует. В реестре профессиональных стандартов Минтруда России нет профстандарта для пентестеров или баг-хантеров. Эти профессии отсутствуют и в квалификационных справочниках должностей, а также в ряде общероссийских классификаторов. В результате не сформирован перечень трудовых функций специалистов по тестированию на проникновение. Без такого описания невозможно перейти к следующему этапу – алгоритмизации этих функций и их последующей автоматизации с использованием ИИ.

Пока же предпринимаются попытки компенсировать этот нормативный вакуум другими мерами – например, обсуждается создание реестра белых хакеров и ужесточение ответственности за неправомерные действия. Однако такие шаги скорее свидетельствуют о незрелости регулирования, чем способствуют развитию отрасли.

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

В этом направлении уже ведется работа профессиональным сообществом, в частности Ассоциацией руководителей служб информационной безопасности (АРСИБ).

Формирование таких стандартов и регламентов может стать важным шагом к более широкому использованию технологий ИИ в сфере кибербезопасности.

Падение курса биткоина и его последствия для ландшафта атак

Редакция журнала "Информационная безопасность" — Thu, 30 Apr 2026 12:37:38 GMT

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

Эксперты:

Денис Гойденко, руководитель департамента комплексного реагирования на киберугрозы экспертного центра безопасности Positive Technologies
Олег Скулкин, руководитель BI.ZONE Threat Intelligence
Максим Федосенко, ведущий инженер-аналитик Аналитического центра кибербезопасности компании “Газинформсервис”

В начале 2026 г. курс биткоина снизился с уровней выше $100 тыс., достигнутых в 2025 г., до существенно более низких значений, продемонстрировав выраженную волатильность и нисходящий тренд.

В горизонте 3–6 месяцев снижение курса биткоина приведет к росту, снижению или стагнации общего числа атак?

Максим Федосенко, "Газинформсервис"

Наиболее вероятна стагнация при росте количества атак и уменьшении числа атакующих. Связано это с тем, что вместе со снижением курса биткоина снизятся и потенциальные доходы злоумышленников от выкупа в результате успешных атак, вследствие чего они станут пытаться брать не качеством, а количеством – плодить массовые атаки в режиме бешеного принтера. Ожидаемо также снижение числа атакующих, поскольку часть мелких игроков предпочтет уйти с рынка из-за уменьшения потенциальной выгоды. Однако лидеры рынка адаптируются.

Олег Скулкин, BI.ZONE

Злоумышленники переживают падение курса криптовалют уже не первый раз, и этот факт едва ли значительно повлияет на их операции. Дело в том, что криптовалюта играет промежуточную роль. Например, вымогатели оценивают выкуп в долларах, после чего конвертируют его в криптовалюту. Соответственно, повлиять это может разве что на тех, кто хранит полученные незаконным путем средства в криптовалюте. Тем не менее, учитывая объем выплат, это едва ли повлияет на общий уровень активности злоумышленников.

В горизонте 3–6 месяцев мы увидим больше закрытий и распадов киберпреступных группировок или, наоборот, их укрупнение и консолидацию?

Максим Федосенко, "Газинформсервис"

Наиболее вероятный сценарий – консолидация небольших и крупных игроков теневого рынка. Небольшие игроки скорее откажутся от самостоятельной реализации атак из-за снижения доходности и отсутствия ресурсов для расширения поля массовых атак, в то время как лидеры рынка адаптируются и по правилам среднего и малого бизнеса возьмут под свое крыло остальных. Реализация такой тенденции, вероятно, будет за счет развития RaaS-платформ, в рамках которых неопытные хакеры будут использовать арендованный у крупных игроков доступ к вредоносному ПО по подписке или за процент от выкупа в результате успешных атак.

Олег Скулкин, BI.ZONE

Группировки регулярно исчезают и появляются, заработок влияет на это далеко не всегда: не все группировки являются финансово мотивированными. Более того, сегодня не каждое объединение можно назвать группировкой в традиционном понимании. Например, если говорить о вымогателях, они часто работают в формате партнерской программы. Соответственно, количество участников такой программы может исчисляться десятками, которые используют один и тот же шифровальщик, но при этом не связаны друг с другом.

Денис Гойденко, Positive Technologies

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

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

Денис Гойденко, Positive Technologies

Хакеры атакуют инфраструктуру, жертвы делают выводы и прокачивают свою киберзащиту. Поэтому злоумышленникам становится сложнее повторять прежние сценарии нападения. Усиленные меры защиты со стороны бизнеса могут подталкивать атакующих к более рискованным формам атак. Это будет происходить за счет упрощения методов проникновения, например через фишинг, компрометацию учетных данных, подкуп инсайдеров. Однако чем больше будет личного взаимодействия с жертвами, тем больше у киберпреступников рисков по раскрытию. Тем не менее атакующие постоянно совершенствуют свой инструментарий и способы обхода технологий защиты.

Олег Скулкин, BI.ZONE

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

Максим Федосенко, "Газинформсервис"

В связи с ожидаемым падением доходности от одной атаки из-за падения курса биткоина, злоумышленники будут пытаться наверстать упущенную выгоду количеством атак. Это приведет к повышению рисков со стороны атакующих, которые будут обусловлены, с одной стороны, увеличением числа агрессивных методов вымогательства и сокращением времени на переговоры о выкупе, с другой – снижением качества реализации атак (ростом числа ошибок, пренебрежением методами маскировки) в погоне за их количеством, с третьей – задействованием в роли потенциальных жертв серьезных организаций, использующих КИИ и имеющих в своем штате опытных безопасников из силовых структур.

И в завершение...

Максим Федосенко, "Газинформсервис"

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

Денис Гойденко, Positive Technologies

Базовые технологии атаки и защиты существенно не изменились за многие годы. Появились новые инструменты, которые помогают ускорять некоторые процессы в атаке и защите и ими стоит пользоваться (например, LLM). Однако не стоит забывать, что не существует кнопки "сделать хорошо", а также о том, что человеческий фактор будет как преимуществом в творчестве атакующих, так и недостатком в пробелах при организации киберзащиты.

Песочница без анализа цепочки атаки: почему просто детекта мало

Александра Савельева — Thu, 30 Apr 2026 11:51:25 GMT

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

Автор: Александра Савельева, исполнительный директор АВ Софт

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

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

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

Каждый элемент по отдельности может выглядеть безопасно. Архив не содержит явного вредоносного кода, документ не вызывает подозрений, а сетевой запрос формально легитимен. Если анализировать их изолированно, то система не всегда сможет принять правильное решение. В таких ситуациях песочница действительно позволяет увидеть поведение объекта при выполнении. Но анализ одного элемента не позволяет восстановить Kill Chain, поэтому результат остается фрагментарным.

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

Ограничение классических песочниц

Если песочница анализирует только один элемент, то фиксирует лишь часть происходящего. Например, она может показать, что документ запускает скрипт, но не всегда связывает это с тем, откуда этот документ появился и что происходит дальше, после выполнения скрипта. В результате анализ разбивается на отдельные фрагменты. Каждый из них может быть понятен сам по себе, но целостной картины атаки не возникает. Чтобы ее собрать, аналитик должен вручную сопоставлять результаты разных проверок. Это становится проблемой, когда атака разворачивается в несколько этапов.

Еще одна сложность связана с тем, что поведение может проявляться не сразу. Часть действий откладывается или зависит от внешних условий. Если анализ ограничен по времени или не учитывает такие сценарии, то песочница фиксирует лишь начальный этап. Поэтому на практике важен не просто запуск объекта в изолированной среде, а возможность проследить, как его действия приводят к следующим шагам. А это требует не только наблюдения за процессами, но и фиксации связей между ними.

Именно в этом направлении развиваются современные решения. Например, в решении ATHENA [1] (разработано компанией АВ Софт) внимание уделяется не только поведению отдельного файла, но и отслеживанию переходов между этапами – от открытия вложения до обращения к внешним ресурсам и загрузки дополнительных компонентов. Подход ATHENA позволяет перейти от анализа отдельных объектов к пониманию всей последовательности действий. Именно это определяет практическую ценность песочницы в современных условиях.

Формирование целостной картины атаки

Чтобы перейти от отдельных наблюдений к целостной картине, песочница должна последовательно фиксировать все этапы, через которые проходит объект. Речь идет не только о запуске файла, но и о действиях, которые он инициирует дальше.

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

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

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

Следующий уровень – сетевое взаимодействие. Во многих атаках именно здесь происходит переход к основному вредоносному коду. Объект обращается ко внешним ресурсам, загружает дополнительные модули, получает команды. Если эти действия не связаны с предыдущими шагами, то анализ распадается на части.

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

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

В ATHENA эти задачи решаются как единый процесс. Система последовательно обрабатывает вложенные объекты, фиксирует переходы между ними и отслеживает, как локальные действия приводят к сетевой активности. Имитация пользовательских действий и обработка задержек позволяют довести сценарий до стадии, где проявляется основная логика атаки.

В результате формируется не набор отдельных событий, а связанная последовательность – от исходного объекта до его взаимодействия с внешней инфраструктурой. Именно такая реконструкция позволяет понять, как развивается атака и какие элементы в ней задействованы.

Меняем практику защиты

Когда песочница восстанавливает не отдельный эпизод, а всю последовательность действий, меняется ценность результата. Прежде всего такой анализ дает более точные индикаторы компрометации. Речь идет не только о хэше файла, но и о доменах, IP-адресах, сетевых обращениях, созданных процессах и других признаках, которые относятся ко всей цепочке. Теперь можно использовать результат шире, чем просто одна проверка.

Кроме того, появляется контекст. Аналитик видит не просто факт запуска подозрительного объекта, а понимает, на каком этапе атаки он находится, что уже произошло и какие действия могут последовать дальше. Это сокращает время на разбор инцидента и снижает объем ручной работы. А результат проще встроить в существующие процессы мониторинга и реагирования. Если песочница передает не только общий вердикт, но и структурированные данные о поведении объекта, их можно использовать в SIEM, SOAR, EDR и других системах. Тогда анализ не остается изолированным, а становится частью общей логики защиты. Для этого важна не только глубина анализа, но и удобство интеграции.

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

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

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

Роль песочницы меняется

Когда анализ начинает строиться вокруг цепочки атаки, песочница перестает быть инструментом, который используется только в сложных и редких случаях. Она становится постоянным источником данных о поведении объектов и их связях. Ведь в реальной инфраструктуре подозрительные объекты поступают из разных источников: почты, веб-трафика, файловых хранилищ. При этом динамический анализ целесообразен не для всех объектов, а прежде всего для тех, которые содержат активный код – макросы, скрипты или исполняемые компоненты. Это позволяет избежать избыточной нагрузки и задержек при проверке. Если такие объекты анализируются изолированно, то система быстро перегружается разрозненными результатами.

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

Такой подход открывает возможности для автоматизации. Если известна последовательность действий, система может не только зафиксировать инцидент, но и заранее определить, какие этапы атаки требуют блокировки или дополнительного контроля. В этом контексте песочница становится частью более широкой системы защиты, где ее задача – не просто анализировать объекты, а поставлять данные и контекст для принятия решений во внешних системах – SIEM, SOAR, EDR и др. Это требует стабильной работы под нагрузкой, масштабируемости и возможности обрабатывать поток объектов без задержек.

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

В зависимости от сценария могут использоваться разные режимы работы: потоковый – для обработки большого количества объектов без задержек, и экспертный – для детального анализа сложных инцидентов с расширенным набором поведенческих данных.

Заключение

Современные атаки больше не укладываются в модель проверки отдельных объектов. Они разворачиваются как последовательность действий, где каждый шаг сам по себе может не вызывать подозрений. И песочница сохраняет ценность только тогда, когда способна выйти за рамки изолированного анализа и показать, как эти действия связаны между собой. Без этого она остается инструментом, который дает детальный, но ограниченный результат.

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

https://avsw.ru/products/anti-apt/athena

Реклама: ООО «АВ Софт». ИНН 7729662615. Erid: 2SDnjdBYFYN

Расследование транзакционной цепочки при кроссчейн-переходах

Дмитрий Пойда — Thu, 30 Apr 2026 07:33:24 GMT

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

Автор: Дмитрий Пойда, аналитик по расследованиям AML/KYT провайдера “Шард”

Что такое мосты между блокчейнами?

Мост между блокчейнами – это технический механизм, который позволяет передавать цифровые активы между различными, изначально несовместимыми блокчейн-сетями. Каждый блокчейн представляет собой закрытую систему с собственными правилами подтверждения транзакций и учета баланса, поэтому токены одной сети не могут просто перемещаться в другую.

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

Мосты необходимы пользователям, поскольку блокчейны сегодня сильно изолированы друг от друга. Например, в одной сети могут быть низкие комиссии, в другой – нужные DeFi-приложения, а в третьей – ликвидность или торговые возможности. Без мостов пользователь оказался бы запертым в одной экосистеме, что часто бывает невыгодно.

Мосты делают криптоэкосистему более структурированной и связной. Они позволяют свободно перемещать капитал туда, где он нужен, и использовать различные блокчейны как единое пространство. Это особенно важно для DeFi-приложений, которые работают в нескольких сетях, и для которых возможность быстрой транспортировки ликвидности между ними является обязательной.

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

Перенос активов через мосты и история транзакций

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

Когда пользователь отправляет токен через мост, происходит не перемещение монеты как единого объекта, а изменение ее состояния в двух разных сетях. В исходном блокчейне актив обычно блокируется в смарт-контракте или сжигается, а в целевой сети появляется его эквивалент. С точки зрения блокчейна это два независимых события, которые не являются прямым продолжением друг друга.

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

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

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

Мосты в криминальных схемах

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

Среди технологий, которые наиболее часто фигурируют в таких схемах, выделяются децентрализованные протоколы обмена ликвидности, такие как THORChain, а также агрегаторы и кроссчейн-сервисы вроде Bridgers.xyz. По данным команды "ШАРД", около 12,2% отслеживаемых подозрительных потоков связано с THORChain, что объясняется его архитектурой, глубокой ликвидностью и возможностью обменивать средства между сетями без централизованного посредника.

Привлекательность мостов для злоумышленников объясняется несколькими ключевыми факторами:

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

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

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

Аналитики проводят комплексную работу, реконструируя путь средств через различные блокчейны. Эта информация оформляется в виде структурированных материалов, где поэтапно восстанавливается движение активов. Такие аналитические отчеты используются специалистами в области блокчейн-анализа и расследований, а также могут служить доказательной базой в правоприменительной практике, например при расследованиях неправомерных операций с цифровыми активами.

Есть ли у мостов связь с регуляторами?

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

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

С другой стороны, существует значительная часть полностью децентрализованных мостов, где контроль распределен между участниками сети, а управление осуществляется через смарт-контракты без централизованного органа принятия решений. В этих системах нет субъекта, который мог бы напрямую взаимодействовать с регуляторами или исполнять их требования. Хотя это и не означает полной бесконтрольности, такие мосты значительно ограничивают возможности внешнего воздействия, так как любые изменения требуют консенсуса или обновления протокола, что делает оперативное вмешательство затруднительным.

Восстановление цепочки транзакций

Когда аналитик обнаруживает факт перехода средств через мост, первым делом он фиксирует точку разрыва – момент, когда обычное отслеживание в рамках одной сети прекращается. Для этого используются базы данных разметки адресов, где адреса мостов уже классифицированы как инфраструктурные. Это позволяет быстро понять, что средства были направлены не на обычный кошелек, а в механизм кроссчейн-переноса.

Далее аналитик сосредотачивается на исходящей транзакции: устанавливает адрес отправителя, объем средств, тип актива и точное время операции. Эти параметры становятся отправной точкой для дальнейшего анализа. Параллельно исследуются связанные адреса, например кошельки, с которых происходила консолидация средств перед отправкой в мост, или адреса, участвовавшие в промежуточных операциях. Это помогает понять контекст транзакции: была ли она единичной или является частью более сложной схемы.

Следующий этап – определение целевой сети и реконструкция входящей части операции. Аналитик сопоставляет исходящую транзакцию с событиями в других блокчейнах, учитывая временные интервалы, объемы, структуру операций и особенности работы конкретного моста. Даже если имеются задержки или промежуточные преобразования активов (например, через обернутые токены или кроссчейн-обмены), обычно удается точно установить, в какую сеть были переброшены средства.

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

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

Зачем ЦОДу PAM? 7 глупых вопросов перед внедрением

Владимир Алтухов — Wed, 29 Apr 2026 14:50:28 GMT

При внедрении кибербезопасности в ЦОДах ключевыми становятся не столько модели угроз, сколько практическая польза, бюджет и риск создания громоздкой надстройки. Руководителям важнее понять, какую реальную задачу решит инструмент, а не следовать абстрактной теории.

Автор: Владимир Алтухов, руководитель технического отдела “АйТи Бастион”

Системы управления привилегированным доступом (PAM, от англ. Privileged Access Management) часто попадают в зону сомнений. Фактически такие решения напрямую вмешиваются в рабочие процессы, заставляя перестроить привычную рутину администрирования. Почему нельзя оставить все как есть, если команда небольшая? Зачем контролировать тех, кто и так работает по регламенту? Чем это отличается от уже внедренных средств защиты? Давайте разбираться.

Почему нельзя доверять админам? Они же наши сотрудники!

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

PAM устанавливается не для тотального контроля и не из-за недоверия к сотрудникам – человеческая память и журналы отдельных серверов попросту не образуют единой картины. В определенный момент компании понадобится не вера в специалистов, а воспроизводимость их действий – и тогда PAM окажется очень кстати. И, говоря откровенно, инсайдерская угроза будет актуальна всегда: списывать ее со счетов не стоит.

Чем плох общий аккаунт администратора на конкретную смену? Это ведь быстрее

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

Общий аккаунт может сильно ускорять работу до тех пор, пока не случится нештатная ситуация. Когда происходят ошибки в работе инфраструктуры ЦОД, сбои или компрометация, становится невозможно отследить ее источник: связь с конкретным человеком уже потеряна. В результате сложности будут возникать не только в расследовании инцидентов, но и при обычной эксплуатации системы. Помимо этого, общий аккаунт всегда чреват распространением учетных данных – в заметках, в личных переписках и даже в руках подрядчиков. Дело опять же не в злом умысле – просто людям так удобнее выполнять работу. Внедрение PAM не усложнит процедуру входа, но вернет возможность однозначно определять, что происходит и в результате чьих конкретно действий. Формально администратор продолжит работать от имени root-пользователя, но система будет знать, кто именно стоит за этой сессией.

У нас уже есть сетевой экран и антивирус, зачем нам тратить бюджет еще и на PAM?

Средства защиты периметра и контроля вредоносного кода решают свои конкретные задачи: первые – контролируют сетевые взаимодействия, вторые – поведение программ. Они рассчитаны на ситуации с попытками несанкционированного входа или запуск вредоносного ПО. В случае, когда вход выполняется под действующей учетной записью через штатный VPN, никакого нарушения модели угроз таких систем не происходит. С точки зрения сети, соединение разрешено, а с точки зрения антивируса, – никаких нареканий тем более нет.

В этом сценарии проблема лежит в использовании уже выданных привилегий. И здесь нужны инструменты другого класса, которые контролируют не факт подключения и не код, а сами действия внутри привилегированной сессии. Сегодня инциденты чаще построены не на обходе защиты, а на использовании того, что разрешено. Это значит, что, например, команда, выполненная в консоли сервера, будет логироваться так же, как повседневная администраторская работа. Без отдельного уровня контроля все такие действия (изменения в конфигурации, создание новых пользователей, выгрузка данных) будут оставаться легитимными по всем внешним признакам. PAM не дублирует защиту, он закрывает свой опасный участок, который не распознают другие инструменты.

У нас не было ни одного инцидента. Зачем доплачивать, когда все работает четко?

Отсутствие проблем не означает, что их нет. Вы можете о них просто не знать. Несанкционированные привилегированные операции не всегда вызывают незамедлительные последствия, обычно это игра в долгую. Ошибка может проявить себя через месяцы – исходные логи уже исчезли, а сотрудники и подавно не помнят, что происходило.

Это также распространенный вектор атак. После получения доступа злоумышленник не станет спешить что-то ломать. Напротив, его задача – закрепиться в инфраструктуре, понять ее устройство и завладеть контролем. Сначала появится дополнительная учетная запись, затем доступ к соседним системам, а после – к резервным копиям или системе управления. Каждое такое действие будет выглядеть вполне легально – как обычная административная операция.

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

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

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

Ограничения продукта по контролю доступа не помешают: подрядчик продолжит выполнять все необходимые операции, но для нерабочих задач система останется закрытой. К тому же, с помощью PAM очень удобно оценивать эффективность работы специалиста – если сессия активна несколько недель, а реальных действий в ней едва ли на два дня, возможно, стоит пересмотреть уровень оплаты подрядчика. Один из недавних примеров: кейс аэропорта "Пулково" и системы СКДПУ НТ, когда PAM помог сэкономить бюджет благодаря мониторингу удаленных подключений и возможности контролировать время работы подрядного специалиста1.

Почему нельзя просто вручную отключить временный доступ подрядчика?

Можно и нужно! Но ручное отключение предполагает, что кто-то обязательно должен вспомнить, что это надо сделать. На практике временный доступ практически всегда выдается во внештатной ситуации, после завершения которой внимание легко переключается, а отзыв откладывается.

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

Такая защита нужна только ЦОДам федерального значения. Зачем нам сложные решения, если у нас маленький ЦОД?

От размера площадки зависит разве что количество оборудования, но характер рисков остается тем же. Даже небольшой ЦОД обслуживает критичные для бизнеса сервисы, но при этом возможностей для длительного расследования и резерва на случай простоев у него нет. То есть последствия ошибок будут ощущаться раньше и больнее. В небольших инфраструктурах зависимость от конкретных специалистов куда выше, потому что производится много ручных операций. В таком случае система контроля привилегий играет роль не столько шлюза входа, сколько механизма упорядочивания хаотичной и ручной работы. Со временем она поможет экономить ресурсы: упростит и ускорит передачу смены, аудит, снизит время поиска причин сбоев и других инцидентов. Для небольших площадок это может быть даже важнее, чем для крупных – для разбора каждого инцидента команды нет, но система поможет сэкономить бюджет на зарплаты.

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

Внедрение PAM – не столько реакция на угрозы, сколько возможность их предвосхищать и переходить от устных договоренностей к проверяемым и воспроизводимым процессам. Безопасность в этой модели – следствие того, что инфраструктура стала понятнее, эффективнее и надежнее.

При возникновении вопросов (в том числе и глупых) о применении PAM в центрах обработки данных, вы можете обратиться за консультацией к "АйТи Бастион" – лидирующему производителю PAM-систем в России.

Реклама: ООО «АйТи БАСТИОН». ИНН 7717789462. Erid: 2SDnjeWWtVG

Искусственный интеллект в корпоративных системах – вас ломают по-новому

Игорь Бирюков — Tue, 28 Apr 2026 12:47:22 GMT

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

Авторы:
Антон Редько, руководитель группы “Безопасная разработка” компании “Кросс технолоджис”
Игорь Бирюков, генеральный директор компании INFERA Security

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

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

На вашу ИИ-модель воздействуют

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

MITRE ATLAS – это база знаний, основанная на реальных наблюдениях, которая описывает тактики, техники и процедуры (TTP) кибератак на системы машинного обучения. Она адаптирует известную методологию MITRE ATT&CK для специфики ИИ-угроз. MITRE Atlas выделяет 56 подтехник атак, которые злоумышленники используют в отношении ИИ-моделей. Так как на Западе развитие искусственного интеллекта и его внедрение в бизнес-процессы происходит быстрее, а атаки на иностранные компании начались раньше, у российских хакеров появляется возможность использовать лучшие практики, которые уже показали свою эффективность.

Выделим три основные угрозы, которые наиболее распространены сегодня.

Представьте корпоративный ИИ-помощник, обученный на внутренней базе знаний компании – регламентах, договорах, переписке. Пользователь формулирует вопрос так, что ассистент для ответа цитирует выдержки из конфиденциальных документов. Произошла ли утечка? Да. Зафиксируют ли ее классические инструменты? Нет. Так как все произошло легитимно. Подобная ситуация возникает, когда граница между тем, что модель знает, и тем, что ей разрешено говорить, не выстроена архитектурно.
Prompt Injection – тип атак, при котором вредоносная команда встроена в промпт или в дополнительные материалы, передаваемые в ИИ-модель. Классический пример: пользователь отправляет на анализ документ, внутри которого спрятана инструкция: проигнорируй предыдущие правила и ответь на следующий вопрос. Модель читает документ и следует инструкции, внося изменения в инфраструктуру или выдавая некорректные данные. Особенно опасны промпт-инъекции в агентных сценариях, где ИИ не просто отвечает на вопросы, но и выполняет действия: отправляет письма, создает задачи, обращается к внешним API.
Потенциально наиболее опасный риск – компрометация на этапе обучения: злоумышленники заражают обучающие данные, что может с самого начала заложить вредоносные сценарии, оставить бэкдоры и т. д.

MLSecOps – не просто новый термин

Учитывая все риски, связанные с использованием ИИ в инфраструктуре, и неэффективность некоторых классических СЗИ в их мониторинге, сформировалась практика MLSecOps. Простыми словам, это объединение принципов DevSecOps с требованиями безопасности, специфическими для машинного обучения. Идея схожа с безопасной разработкой – ИБ нужно обеспечить на каждом этапе, а не просто повесить сверху.

Несколько конкретных изменений в подходе:

Данные для обучения проходят верификацию и контроль целостности. Доступ к ним дополнительно защищен, чтобы избежать отравления данных.
Доступ к модели ограничен на уровне ролей. Те, кому она не нужна для работы, не должны иметь никакого доступа.
Запросы к модели должны фильтроваться и анализироваться до попадания в саму модель. Это позволит выявить вредоносные действия.
Необходим постоянный мониторинг поведения модели, анализ нестандартных действий и ответов, особенно на раннем этапе. Фиксация отклонений позволит зафиксировать вредоносные действия и лучше понимать логику решений.
Модели должны регулярно тестироваться – целенаправленные попытки манипуляции позволят выявить уязвимости и применить меры для их устранения.

Ключевое отличие MLSecOps от традиционной ИБ не в инструментах, а в объекте защиты. Мы защищаем не просто данные и инфраструктуру, а контролируем поведение системы, принимающей решения, а также процессы, в которых используется ИИ. Это требует другого уровня понимания и другого набора компетенций, но при этом повышает уровень безопасности и сокращает время вывода ИИ-продуктов в продакшен.

Для безопасного использования ИИ необходимо внедрять AI Firewall, регулярно использовать сканеры ML Red Teaming для симуляции атак с целью выявления слабых мест до их эксплуатации злоумышленниками. Серьезное внимание следует уделить вопросу управления правами доступа и ограничению прав ИИ-агентов, установку запрета на выполнение критических операций без участия человека.

Как обстоят дела на практике?

Чтобы понять, как атаки на ИИ-модели влияют на бизнес, рассмотрим их внедрение и риски на конкретных примерах, а также практики, которые были применены для защиты.

Кража клиентских данных в банке

Банки и страховщики – лидеры по зрелости внедрения ИИ. В одном из кейсов, с которыми столкнулись наши специалисты, банк использовал искусственный интеллект для детектирования мошенничества на основе поведенческих паттернов, персонализации предложений, автоматизации скоринга, клиентской поддержки. ИИ дал ощутимые операционные результаты: на 30% снизилось количество ложных срабатываний антифрода, на 15% снизилось число невозвратов кредитов за счет более точного скоринга, а 60% обращений клиентов обрабатывает ИИ, что позволило сократить штат поддержки и перераспределить нагрузку специалистов на сложные кейсы.

Однако банк столкнулся со следующим инцидентом: через фишинговую атаку злоумышленник получил доступ к учетной записи одного из ИТ-специалистов, который имел широкий доступ к элементам инфраструктуры. Получив доступ к модели, хакер реализовал промпт-инъекцию. Модель имела доступ к данным клиентов и выдала злоумышленнику актуальную базу данных. Инцидент удалось предотвратить на этапе вывода данных за пределы инфраструктуры – DLP-система зафиксировала подозрительное поведение пользователя, подала сигнал и аккаунт был заблокирован.

Для противодействия будущим промпт-инъекциям был внедрен AI Firewall для анализа и фильтрации запросов и ответов. Проведен аудит модели, доступ к ней предоставили только для специалистов, которым для реализации служебных задач она необходима, была усилена аутентификация.

Нарушение маршрутов поставок

В логистической компании ИИ-модель использовалась для оптимизации маршрутов. За счет оперативного анализа модели в среднем время доставки удалось сократить на 20%, что высвободило для компании дополнительные мощности и позволило брать дополнительные заказы.

Хакеры проникли в информационную инфраструктуру из-за незакрытого доступа к внешнему хранилищу. Находясь в инфраструктуре, злоумышленники добрались до базы данных, на которой ИИ-модель обучается, и подменили часть данных. В результате инцидента несколько грузовиков направились по неоптимальным маршрутам, что привело к задержкам в доставке. Потери компании оказались не настолько значительными (несколько сотен тысяч рублей), так как удалось вовремя зафиксировать сбой в работе и оптимизировать маршруты.

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

CRM-система в поставщике оборудования

У одного из заказчиков ИИ-модель использовалась для оптимизации работы коммерческого департамента с CRM-системой. ИИ заполняла карточки клиентов, расшифровывала звонки и добавляла комментарии. Модель была внешней, не встроенной в CRM-систему, взаимодействие между ними происходило через API.

Модель использовала для обучения все данные, которые собирала, хотя изначально это не подразумевалось. Ошибку удалось вскрыть до атаки, в результате применения сканера ML Red Teaming. Настройки ИИ-системы были изменены, из обучающих данных убрана конфиденциальная информация. При следующем анализе ошибка уже не повторилась.

Что мешает выстроить защиту ИИ?

Мы выделили три основных сложности для бизнеса сегодня в построении защиты ИИ-систем.

Организационные сложности

В большинстве компаний ИИ-проекты живут в периметре ИТ или бизнес-подразделений, а информационная безопасность подключается постфактум или не подключается вовсе. Это не злой умысел – просто ИИ-внедрения воспринимаются как продуктовая задача, а не как изменение профиля рисков. Пока эта установка не изменится, системной защиты не будет.

Нехватка компетенций

Специалистов, которые одинаково хорошо понимают машинное обучение и информационную безопасность, крайне мало. ИБ-команды зачастую не знают, как атакуют модели, а ML-команды не думают в категориях угроз. Это структурный дефицит, который нельзя закрыть покупкой инструмента – нужны инвестиции в обучение команды и новые роли.

Инструментальные проблемы

Классические средства защиты, такие как SIEM, DLP, WAF, не видят специфических угроз для ИИ-систем. Prompt Injection не выглядит как сетевая атака. Утечка через LLM не фиксируется как передача файла. Для полноценной защиты нужны специализированные инструменты, которые понимают контекст работы с моделями. Должна проводиться полная инвентаризация моделей, датасетов и версий GPU-драйверов, патчинг инференс-серверов.В заключение

ИИ в корпоративной среде уже реальность, от которой нельзя отказываться. При правильном внедрении бизнес получает множество выгод. Но такое изменение архитектуры создает специфические риски, которые необходимо учитывать. Компании, которые осознают это сегодня, получат преимущество – не только операционное, но и репутационное.

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

ИИ меняет бизнес-процессы и операционную деятельность. Безопасность ИИ – вопрос доверия новой структуре.

Теневые утечки через внешние модели ИИ

Тагир Кабиров — Tue, 28 Apr 2026 12:18:28 GMT

Похоже, бизнес не до конца осознает побочные эффекты использования LLM. Чем чаще сотрудники используют ИИ в работе, тем больше внутренних данных оказывается за пределами компании незаметно для нее самой. При такой теневой утечке нет злоумышленников – конфиденциальная информация уходит просто потому, что кто-то хотел сделать свою работу чуть быстрее.

Автор: Тагир Кабиров, руководитель направления средств контроля пользователей Innostage

Весной 2026 г. компания Anthropic случайно опубликовала [1] около полумиллиона строк исходного кода Claude Code. Всему виной человеческий фактор. Годом ранее из-за взлома сервиса OmniGPT (агрегатора, который объединял доступ к нескольким ИИ-моделям) в сеть попали [2] десятки миллионов пользовательских сообщений. Среди них API-ключи, корпоративные документы и рабочая переписка. До этого Samsung выяснила, что ее инженеры трижды за месяц загрузили в ChatGPT фрагменты исходного кода. После этого компания запретила [2] сотрудникам использовать сторонние ИИ. Примечательно, что такие запреты обычно появляются уже после утечек, до них никаких инструкций нет.

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

Как возникает теневая утечка

Среди всей информации, которую сотрудники передают в ИИ-сервисы, есть очевидно безобидные общие запросы. Проблема начинается там, где в ход идут рабочие материалы, потому что далеко не всегда сотрудник понимает, какие из них являются чувствительными. Обычно такие данные делятся на три категории:

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

Как это происходит на практике? Например, сотрудник загружает в ChatGPT отчет по информационной безопасности, чтобы проверить его на ошибки и отформатировать. Просит разобрать лог на предмет аномалий, прикладывая журнал системы и таблицу с правами пользователей. Он не планирует ничего сливать, просто хочет быстро проверить корректность настроенных доступов или подготовить презентацию. Задача выглядит рутинной, но в реальности это уже угроза для ИБ.

Сливы в ИИ – это реальная угроза

Во-первых, происходит накопление утечек. Информация постепенно покидает корпоративный контур. По отдельности фрагменты кажутся безобидными, но со временем из них складывается довольно точная картина того, как устроена компания: какие системы используются, как они связаны между собой, какие версии ПО развернуты, какие средства защиты применяются, где обновлены операционные системы, а где – нет.

Во-вторых, переданная информация может сохраняться в публичных моделях и участвовать в процессе обучения. В результате фрагменты корпоративных данных могут влиять на ответы, которые получают другие пользователи. ИИ не действует злонамеренно – он просто обучается на доступных данных, но в результате косвенно раскрывает, какие решения применяются в конкретных компаниях.

В-третьих, существует риск подмены сервисов. Пользователь может перейти по вредоносной ссылке или воспользоваться фальшивым ИИ-инструментом и передать конфиденциальные данные прямо злоумышленникам.

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

Классическая безопасность не справляется

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

Большинство защитных механизмов исторически строились вокруг периметра компании: сети, серверов, рабочих станций и т. д. Предполагалось, что главное – не пустить злоумышленника внутрь. Но поскольку в ситуации с ИИ данные покидают периметр добровольно, не происходит ничего подозрительного. Такую утечку сложно заметить и остановить. И почти невозможно устранить постфактум. Она не оставляет следов, характерных для классической атаки. Определенную пользу в этом аспекте могут принести решения класса DLP (если они контролируют отправку информации через формы в браузерах и приложениях) и SWG.
Во многих организациях существуют так называемые файлопомойки – папки и хранилища, куда сотрудники годами складывают документы на всякий случай. Там могут лежать выгрузки из систем, старые отчеты, списки пользователей или промежуточные версии документов. Формально такие файлы не классифицированы как конфиденциальные, но по факту могут содержать чувствительную информацию. При этом защита часто строится вокруг финальных документов – тех, которые официально помечены как коммерческая тайна. Но пока документ создается и редактируется, его копии и черновики могут оказаться в десятках разных мест внутри компании. Значительная часть таких данных фактически остается вне контроля. Когда сотрудник отправляет подобный файл в ИИ-сервис – например, чтобы проверить текст или проанализировать данные, он может даже не подозревать, что передает чувствительную информацию.
В компаниях постоянно создаются новые отчеты, появляются временные выгрузки, запускаются новые процессы, вовлекаются новые сотрудники. Объем информации быстро растет, и системы безопасности не всегда успевают отслеживать, какие данные появляются, где они хранятся и насколько они чувствительны. Типовые коробочные решения безопасности плохо учитывают эту динамику.
Сотрудникам дают доступ к системам для решения поставленных бизнес-задач, но затем его часто забывают отозвать. Со временем такие доступы накапливаются и создают дополнительные риски.

Все это приводит к тому, что значительная часть информации оказывается вне реального контроля. Именно в этой зоне и возникают теневые утечки.

Новая модель защиты

Отказаться от ИИ уже невозможно, это уже очевидно. Но можно наладить контролируемое использование технологии. Для этого достаточно выполнить пять шагов:

Вы должны понимать, какие данные у вас есть и где они хранятся.
Для работы с внешними инструментами можно использовать обезличенные или замаскированные данные, которые сохраняют структуру для анализа, но не содержат реальной конфиденциальной информации.
Формально за инциденты отвечает ИБ, но на практике безопасность зависит от действий всех сотрудников. Любой человек, даже не связанный напрямую с ИТ, может непреднамеренно стать причиной инцидента. Поэтому сотрудники должны иметь доступ только к тем данным, которые необходимы им для работы. Например, для бухгалтеров передача данных наружу должна быть максимально ограничена, а аналитики могут предоставлять обезличенные наборы.
Контролируйте использование ИИ-сервисов. Один из подходов – создание внутренних платформ или прокси-решений (LLM-прокси), через которые сотрудники работают с внешними моделями. Такие системы позволяют проверять запросы и фильтровать данные, блокируя передачу чувствительной информации. Еще безопаснее развертывание моделей в собственной инфраструктуре компании.
Data Governance (управление данными). Это комплексный подход, который объединяет все предыдущие пункты. Главная идея заключается в том, что бизнес, ИТ и ИБ совместно управляют корпоративными данными и понимают, какие данные есть в компании, где они хранятся, кто имеет к ним доступ, какую информацию можно передавать наружу, какие сотрудники могут использовать ИИ-инструменты и для каких задач.

Выводы

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

Но использование нейросетей должно стать более управляемыми. Отчасти этому будет способствовать развитие уже упомянутых LLM-прокси и внутренних платформ, которые позволяют контролировать взаимодействие сотрудников с ИИ. Отчасти – узкоспециализированные решения, предназначенные для конкретных задач: анализа кода, обработки логов, поиска уязвимостей или подготовки аналитических отчетов. Такие инструменты проще контролировать и интегрировать в корпоративные процессы. Возможно, появятся и новые механизмы ИБ. Но в любом случае без контроля все преимущества, которые ежедневно дает бизнесу ИИ, могут в одночасье перекрыться критическим ущербом.

Невидимая угроза: дрейф конфигураций разрушает архитектуру кибербезопасности

Сергей Овчинников — Fri, 24 Apr 2026 08:19:29 GMT

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

Автор: Сергей Овчинников, директор продуктового департамента компании “Газинформсервис”

В ИБ много говорят о целевых атаках, уязвимостях 0-day и APT-группировках. Однако если внимательно посмотреть на причины серьезных инцидентов последних лет, картина оказывается более прозаичной. Во многих случаях атакующие лишь воспользовались тем, что система уже была небезопасна. И причиной этого стала не злонамеренная активность каких-либо сотрудников организации, а накопленные изменения в конфигурациях – так называемый Configuration Drift, или дрейф конфигураций.

По данным Fidelis Security от ноября 2025 г., неправильная настройка облачных сервисов является причиной до 99% сбоев в системе безопасности. BI.ZONE TDR сообщает, что в среднем на одну конечную точку приходится 2-3 мисконфигурации – то есть, статистически, они присутствуют почти везде и постоянно. По оценке Yandex Cloud, в первом полугодии 2025 г. конечной целью 76% разобранных атак были облачные базы данных и S3-хранилища, при этом среди хронических недостатков, на которые опираются атакующие, прямо названы ошибки конфигурации. По мнению специалистов управления по организации борьбы с противоправным использованием информационно-коммуникационных технологий МВД России, ошибки конфигурации относятся к основным угрозам облачной безопасности. Примеры можно приводить бесконечно.

Рассматривая конкретные инциденты, становится очевидно, что в подавляющем большинстве случаев никто изначально не планировал делать инфраструктуру небезопасной. Изменения в конфигурации вносились по делу – при обновлении и модернизации, внедрении новых мощностей, для срочной интеграции, для устранения другого инцидента, при автоматических внесениях изменений, предоставлении временных доступов и прочее. Но, как часто бывает, планы разошлись с реальностью, и произошло это не сразу, а постепенно. Такая постепенность и является ключевой первопричиной проблем. Дрейф конфигураций – медленное поэтапное и неконтролируемое расхождение фактической конфигурации системы с эталонной архитектурой или политикой безопасности. Это явление происходит, когда мы делаем временные исключения из правил, а потом точечные изменения накапливаются, и их уже никто не контролирует. Или когда мы автоматизируем какой-то процесс, но не проводим последующую валидацию результата. Примеры, которые хорошо знакомы любому специалисту по ИБ: временно добавили правило на межсетевом экране, настроили NAT для пилотного проекта, изменили параметр операционной системы ради совместимости, собрали контейнер с dev-настройками и забыли пересобрать.

Дрейф конфигураций – это не единичная ошибка, а процесс, который неизбежно возникает практически в любой инфраструктуре. Чем активнее развивается ИТ-ландшафт, тем быстрее накапливается расхождение между тем, как должно быть, и тем, как есть на самом деле.

Что со всем этим делать и как решить проблему?

Первая реакция – усилить проверки на наличие уязвимостей. Однако решения класса Vulnerability Management показывают CVE, не отвечая на вопросы, которые относятся к архитектуре безопасности: нарушена ли сегментация, появились ли неожиданные маршруты трафика, соответствует ли фактическое состояние политике безопасности. Уязвимости характеризуют состояние отдельных компонентов системы, в то время как дрейф конфигураций – это состояние всей системы в целом.

SIEM также не решает проблему. Системы этого класса фиксируют уже совершившиеся события и подозрительную активность, связанные с последствиями, которые произошли в том числе из-за некорректной конфигурации. Но сам дрейф конфигураций – это не событие, а фоновое состояние среды (системы). Когда SIEM фиксирует подозрение на инцидент, расхождение в конфигурациях уже накопилось.

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

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

На уровне сети это означает:

ведение защищенной базы конфигураций сетевого оборудования;
построение актуальной карты топологии с учетом NAT и VPN;
моделирование маршрутов прохождения трафика;
проверку соответствия стандартам и лучшим практикам;
оценку влияния планируемых изменений до их внедрения.

Все это позволяет ответить на управленческий вопрос: действительно ли сегментация работает так, как задокументировано? Может ли трафик пройти по маршруту, о котором никто не подозревает?

На уровне узлов и приложений контроль включает в себя:

контроль целостности файлов;
мониторинг изменений конфигураций ОС и прикладного ПО;
проверку соответствия требованиям регуляторов и корпоративных стандартов;
контроль защищенности контейнеров и средств оркестрации;
формирование рекомендаций по приведению системы к эталону.

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

Рис. 1. Схема работы Efros DefOps в рамках контроля целостности

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

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

Какие выгоды дает контроль конфигураций?

На операционном уровне контроль конфигураций снижает количество инцидентов, вызванных накопленными негативными изменениями. Инженеры быстрее понимают текущее состояние среды, сокращается время расследования, снижается зависимость от человеческого фактора, который связан с наличием в штате сотрудников, владеющими "тайными знаниями" о ключевых настройках оборудования, общесистемного ПО и прикладных систем. Таким образом, безопасность становится частью повседневной эксплуатации.

На управленческом уровне CISO получает регулируемость и предсказуемость изменений. Появляется возможность на основе фактов подтверждать соответствие политики безопасности реальному состоянию инфраструктуры, оценивать риски до внедрения изменений и аргументированно обосновывать решения перед руководством.

На стратегическом уровне контроль конфигураций повышает зрелость архитектуры безопасности. Он создает основу для Zero Trust, автоматизированного реагирования и зрелого риск-менеджмента. Организация перестает бороться с последствиями и начинает управлять состоянием среды, масштабируя инфраструктуру без пропорционального роста рисков.

Configuration Drift – не техническая мелочь и не вопрос аккуратности администраторов. Это системное явление, которое неизбежно происходит в развивающейся ИТ-инфраструктуре. Игнорировать его – значит соглашаться с тем, что архитектура безопасности постепенно разрушается под давлением изменений.

В практической плоскости описанный подход реализуется через сочетание контроля сетевой архитектуры и контроля состояния узлов. В составе платформы Efros DefOps1 эти задачи решаются модулями Network Assurance и Integrity Check Compliance, которые охватывают сетевой и хостовый уровни и позволяют выстроить непрерывный контроль конфигураций как процесс, а не как разовую проверку.

Network Assurance (NA) фокусируется на сетевой инфраструктуре – той части ИТ-ландшафта, где дрейф особенно опасен, потому что напрямую влияет на маршруты трафика и границы сегментации. Решение формирует защищенную и актуальную базу конфигураций активного сетевого оборудования, анализирует их на соответствие стандартам и лучшим практикам, выявляет известные уязвимости (в соответствии с БДУ ФСТЭК, CVE, OVAL и др.). NA отображает топологию сети на интерактивной карте, моделирует маршруты прохождения заданного типа трафика и позволяет оценить, как изменится картина безопасности при внесении тех или иных изменений. Это принципиально важно, так как организация получает возможность увидеть потенциальный дрейф конфигураций до того, как он станет реальностью.

Отдельную ценность представляет контроль целостности конфигураций сетевого оборудования и возможность оперативного восстановления. В условиях, когда изменения вносятся часто, например в рамках проектов, инцидентов или модернизации, наличие эталонного состояния и механизма отслеживания отклонений позволяет удерживать конфигурации в управляемых границах. Таким образом, с помощью NA закрывается именно та часть проблемы, которая остается слепой зоной для классических VM и SIEM: соответствие реальной топологии сети той модели, которая изначально была задумана.

Если NA отвечает на вопрос "как устроена и работает сеть на самом деле", то Integrity Check Compliance (ICC) дает ответ на вопрос "в каком состоянии находятся системы и приложения". ICC обеспечивает контроль целостности файлов в различных операционных системах и средах виртуализации, отслеживает изменения конфигураций ОС и прикладного ПО, включая СУБД, системы виртуализации и другие критически важные компоненты. Это позволяет фиксировать и анализировать отклонения не только на уровне параметров, но и на уровне конкретных объектов защиты.

Важной частью ICC является осуществление проверок соответствия (Compliance) объектов защиты требованиям регуляторов, корпоративным стандартам безопасности. Таким образом, контроль конфигураций перестает быть исключительно технической задачей и становится инструментом управляемости и доказуемости соответствия. При выявлении отклонений система формирует рекомендации по внесению изменений для соответствия стандартам безопасности, что переводит процесс из режима обнаружения проблемы в практическую плоскость ее устранения.

В связке Efros DefOps NA и Efros DefOps ICC реализуется именно та концепция, о которой шла речь в статье, то есть переход от декларативного управления политиками к подтвержденному состоянию безопасности. NA обеспечивает прозрачность и управляемость сетевой архитектуры, а ICC – контроль состояния операционных систем и приложений. Вместе они позволяют не просто фиксировать последствия изменений, а системно удерживать инфраструктуру в заданных границах, предотвращая накопление дрейфа конфигураций и снижая вероятность возникновения инцидентов.

https://www.gaz-is.ru/produkty/zashchita-it-infrastrukturi/efros-do

Реклама: ООО «Газинформсервис». ИНН 7838017968. Erid: 2SDnjdYXqd4

DNS-трафик: скрытый фактор корпоративной уязвимости

Дмитрий Царев — Wed, 22 Apr 2026 14:55:59 GMT

DNS – это один из источников бизнес-метаданных, который позволяет понять, какие сервисы использует ваша компания, с кем она интегрируется, какие инструменты внедряет. Давайте посмотрим, как DNS-трафик может использоваться для анализа корпоративной инфраструктуры и какие риски это создает для бизнеса.

Автор: Дмитрий Царев, руководитель управления облачных решений кибербезопасности BI.ZONE

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

Что можно узнать о компании по ее DNS-трафику

DNS-трафик формируется в процессе обработки DNS-запросов, которые проходят через рекурсивные резолверы. В зависимости от архитектуры запросы могут обрабатываться внутри корпоративной сети либо передаваться внешним резолверам.

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

На основе этих данных можно сформировать профиль организации, включая посещаемые сервисы и используемые технологии. Поскольку исходный IP-адрес (source IP address) виден резолверу, иногда удается установить принадлежность трафика конкретной организации и даже восстановить используемый пул IP-адресов. Это особенно актуально, если хосты компании напрямую используют внешние резолверы или запросы проходят через корпоративный рекурсивный резолвер, по которому можно определить источник трафика.

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

Чтобы проверить, насколько информативными могут быть такие данные, в BI.ZONE провели эксперимент с использованием сервиса BI.ZONE Secure DNS. Эксперты выгрузили CSV-файл с DNS-запросами и ответами за несколько дней, проходившими через внутренний рекурсивный резолвер компании. Полученный массив данных был обработан локальной LLM-моделью для автоматического построения профиля организации.

Результаты оказались показательными. На основе DNS-трафика модель смогла достаточно точно определить направление деятельности компании и потенциальные проекты, в которых она может участвовать. Она также определила список подразделений, их специализацию, используемые программные решения, оборудование, операционные системы и даже инструменты, применяемые специалистами по тестированию безопасности.

Удалось также выявить информацию об используемых продуктах различных вендоров, популярных мессенджерах, посещаемых веб-ресурсах сотрудников, виртуальных машинах, имеющих доступ во внешнюю сеть, а также потенциальных проектах и взаимодействиях с внешними организациями. При этом все перечисленное – лишь часть возможных данных. Даже ограниченный набор DNS-запросов способен раскрывать значительно больше деталей о внутренней инфраструктуре и поведенческих паттернах пользователей.

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

Риски при использовании DNS

DNS-угрозы условно можно разделить на несколько категорий. Во-первых, это атаки на сами DNS-серверы и инфраструктуру разрешения имен. Во-вторых, использование DNS-запросов для взаимодействия между зараженными устройствами и управляющими серверами (C2). В-третьих, маскировка вредоносной инфраструктуры: например, через генерацию доменных имен или использование динамических доменных зон.

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

Злоумышленники используют DNS для скрытого управления вредоносными программами, вывода данных через туннели и обхода защитных механизмов сети. Нелегитимный DNS-трафик составляет заметную долю в общем объеме DNS-запросов, а его структура варьируется в зависимости от среды наблюдения. По данным BI.ZONE Secure DNS [1], DNSSEC-аномалии составили 25% нелегитимного трафика. Еще 6,8% приходятся на запросы к доменам, сгенерированным алгоритмами DGA, а около 6% – на попытки использования техники перепривязывания DNS (DNS Rebinding), позволяющей обходить защиту веб-приложений. Даже относительно редкие DNS-туннели фиксировались более тысячи раз за год, несмотря на наличие в инфраструктуре систем обнаружения вторжений (IDPS) и анализа сетевого трафика (NTA).

Сохраняются и угрозы, нацеленные прямо на DNS-инфраструктуру. Один из примеров – попытка отравления DNS-кеша (DNS Cache Poisoning). Сегодня реализовать такую атаку значительно сложнее, чем раньше: современные механизмы (DNSSEC, DNS cookies и дополнительные параметры сессии) существенно усложняют подбор UDP-порта, угадывание TXID и подмену ответа сервера.

Помимо атак на целостность данных, актуальными остаются и атаки на доступность DNS-сервисов. В частности, авторитетные DNS-серверы регулярно становятся целью DDoS-кампаний. Например, атак типа DNS Amplification или DNS-флуда, которые часто входят в стандартный инструментарий ботнетов.

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

Сложность выявления туннелирования дополнительно возрастает при использовании технологий, затрудняющих анализ DNS-трафика. Например, DNS over HTTPS шифрует запросы и ограничивает возможности их анализа, если трафик не терминируется на стороне рекурсивного сервера. Алгоритмы генерации доменов (DGA), применяемые вредоносным ПО, могут использоваться не только для динамической смены адресов управляющих серверов, но и в отдельных сценариях – как механизм передачи информации. В совокупности это усложняет выявление и блокировку каналов управления и передачи данных.

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

Отдельную категорию рисков формирует поведение пользователей внутри корпоративной сети. По данным BI.ZONE Secure DNS за 2025 г. [1], каждый второй нелегитимный DNS-запрос связан с попытками сотрудников получить доступ к заблокированным ресурсам. При этом 61,6% таких запросов приходится на переходы к доменам, запрещенным корпоративными политиками. Остальная часть связана со случайными переходами по устаревшим ссылкам или ошибками пользователей. Но даже такие запросы могут приводить к взаимодействию с фишинговыми или вредоносными ресурсами.

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

Как выбирать публичный DNS-резолвер?

Выбор DNS-резолвера – это вопрос доверия. Любой публичный резолвер обрабатывает данные о DNS-запросах, включая запрашиваемые домены и связанные с ними сетевые метаданные. Если резолвер не является доверенным, организация теряет контроль над тем, кто и как анализирует этот трафик, где он хранится и может ли быть использован для сторонних задач. В этом контексте выбор DNS-поставщика сопоставим с передачей части сетевой телеметрии за пределы периметра. Доверенность резолвера – это не характеристика по умолчанию, а набор проверяемых свойств.

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

Во-вторых, управляемость и наблюдаемость. Организация должна иметь доступ к DNS-телеметрии в объеме, достаточном для расследования инцидентов и построения детектирующих правил: как минимум – исходные IP-адреса, домены, ответы и временные параметры. Если эти данные недоступны или агрегированы на стороне провайдера, DNS становится слепой зоной.

В-третьих, возможность применения политик безопасности. Резолвер должен поддерживать не только базовую фильтрацию, но и более продвинутые сценарии: блокировку DGA-доменов, выявление аномалий, контроль DNS over HTTPS и ограничение обхода через сторонние резолверы. Без этого DNS остается каналом обхода защиты. Важно, чтобы резолвер встраивался в процессы кибербезопасности: интегрировался с SIEM, участвовал в корреляции событий и позволял реагировать на инциденты в режиме, близком к реальному времени.

Использование публичных или Open Source-резолверов без оценки этих параметров фактически приводит к потере контроля над DNS-трафиком. В таких сценариях компания не управляет ни логированием, ни политиками, ни механизмами детектирования, что создает как риски утечки данных, так и условия для незаметного развития атак.

На практике это приводит к двум моделям. Либо организация разворачивает собственные рекурсивные резолверы с полным контролем над логированием и политиками, либо использует специализированные решения, где требования к доверенности, прозрачности и безопасности реализованы на уровне архитектуры. В обоих случаях DNS рассматривается не как вспомогательный сервис, а как инструмент контроля и раннего предотвращения угроз. DNS – это первый шаг при установлении соединения. Если на этом этапе отсутствуют доверие и контроль, все последующие уровни защиты работают в условиях неполной видимости.

https://bi.zone/news/kazhdyy-2-y-nelegitimnyy-dns-zapros-popytka-sotrudnikov-pereyti-na-zapreshchennyy-domen/