Игорь Бедеров: «Зрелая киберзащита начинается с простой мысли: мы — цель»

Основатель компаний «Интернет-Розыск» и руководитель департамента расследований компании T.Hunter

Атаки сегодня все чаще бьют не только по инфраструктуре, но и по управлению. Один инцидент может одновременно затронуть ИБ, PR, юристов, подрядчиков, топ-менеджмент и ключевые бизнес-процессы. В интервью IT-World Игорь Бедеров, председатель совета по противодействию технологическим правонарушениям КС НСБ России, говорит о том, как использовать LLM, не теряя контроль над решениями, как защититься от атак с применением дипфейков, где OSINT помогает перехватить инициативу и зачем бизнесу нужны такие учения, после которых меняется не только версия софта, но и поведение всей системы.

Сегодня многие говорят о применении LLM в SOC. Где, на ваш взгляд, эта технология уже начинает приносить реальную пользу?

LLM уже сегодня помогают SOC работать быстрее и эффективнее. Одна из самых трудоемких задач в SOC — обработка огромного потока оповещений (алертов) от систем SIEM, EDR, сетевых сенсоров и т. д. Многие из них оказываются ложными срабатываниями, но каждое нужно проверить. LLM тут помогают классифицировать алерт по типу инцидента; выделять ключевые индикаторы компрометации (IoC); составлять черновик первичного отчета на основе сырых логов. В результате их работы аналитик получает не просто сырые данные, а структурированную выжимку с гипотезами — и может сосредоточиться на действительно сложных случаях. LLM автоматизируют и отчеты для руководства или регуляторов.

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

Как устроены языковые модели и почему LLM выглядят разумными

LLM также способны на лету составлять или адаптировать плейбуки (алгоритмы реагирования) под конкретный инцидент или тренировку персонала. Это особенно ценно в условиях дефицита опытных SOC-аналитиков — модель выступает своего рода «умным ассистентом», подсказывающим лучшие практики.

А где использование LLM в SOC пока скорее создает новые риски, чем помогает защите?

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

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

Многие коммерческие LLM работают как black box: их логика принятия решений непрозрачна. В результате аналитик не может понять, почему модель классифицировала событие как угрозу. Без этого невозможно проверить вывод и принять обоснованное решение. Если решение принято на основе «мнения» LLM, подтвердить его обоснованность почти невозможно.

Злоумышленники уже используют LLM. И если SOC полагается на LLM, не учитывая эту угрозу, он рискует оказаться в проигрыше: скорость и масштаб атак могут превысить возможности защиты.

Если компания встраивает ИИ в процессы мониторинга и реагирования, как должна меняться зона ответственности людей, принимающих решения?

Современные системы на базе ИИ способны обрабатывать огромные массивы данных в реальном времени — например, анализировать логи сотен серверов и сетевого оборудования; выявлять аномалии, которые человеческий аналитик мог бы пропустить из-за «шума» данных; классифицировать инциденты по степени критичности с помощью алгоритмов машинного обучения; автоматически выполнять типовые действия: изолировать зараженный узел, блокировать подозрительный IP-адрес, запускать резервное копирование; прогнозировать развитие атак на основе исторических данных и индикаторов компрометации (IoC).

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

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

Читайте также

Владислав Мещеряков: Когда код начинает тормозить бизнес. Как компании сами создают технический долг

О том, почему компании сами формируют технический долг, в какой момент он начинает тормозить развитие продукта и можно ли управлять этим процессом системно, IT-World рассказал технический лидер и frontend-архитектор Владислав Мещеряков.

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

Готов ли российский бизнес к эре цифровых сотрудников? Обзор рынка ИИ-агентов

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

Если смотреть на ИИ как на объект атаки, какие риски сегодня недооцениваются больше всего?

Безопасность часто сводится к защите серверов и сетей, а логика ИИ считается «черным ящиком», который не нужно дополнительно защищать.

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

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

Третий — извлечение модели. Тут злоумышленник «копирует» чужую ИИ-систему, многократно отправляя запросы и анализируя ответы. Риск этот растет с распространением API-доступа к моделям. Причем владельцы часто не отслеживают аномальные паттерны запросов, считая, что открытая точка доступа по определению безопасна.

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

Где сегодня проходит периметр защиты AI- и ML-систем, если говорить не в теории, а на практике?

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

С 1 марта 2026 года в России действуют новые требования к безопасности AI-систем в госсекторе. Они включают защиту от несанкционированного доступа к данным; предотвращение вмешательства в работу систем; запрет на использование конфиденциальных данных госсистем для обучения моделей; контроль взаимодействия пользователя с AI, включая ограничение ввода и вывода данных, проверку достоверности ответов.

По каким признакам можно понять, что программа Security Awareness действительно работает, а не существует для галочки?

Важно понимать, что Security Awareness — это не просто разовое обучение, а непрерывный процесс. Если после внедрения программы процент сотрудников, попадающихся на фишинг, заметно упал (например, с 30 до 5%), это прямой показатель успеха. Одновременно сотрудники начинают активно сообщать ИБ-отделу о подозрительных письмах, ссылках или звонках. Люди не просто знают правила, а следуют им. Топ-менеджмент участвует в обучении и подает пример соблюдения правил ИБ. Наконец, материалы программы актуализируются с учетом новых угроз.

Как, по вашему опыту, должно быть выстроено взаимодействие ИБ, PR, юристов и руководства, когда компания сталкивается с информационной атакой?

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

Читайте также

Наталья Остроухова: «Разработчики ТИМ-решений все внимательнее смотрят на средний и малый бизнес»

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

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

Как вы оцениваете реальную практическую ценность OSINT для корпоративной безопасности и анализа киберугроз?

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

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

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

Что отличает действительно полезный пентест или Red Team-упражнение от формальной проверки, после которой в компании почти ничего не меняется?

Рынок переполнен предложениями «проверить на проникновение», и большинство компаний довольствуются именно формальной проверкой. Формальный пентест — это экзамен, где ученик знает билеты. Компания получает PDF, кладет его на полку и живет дальше до следующего года.

Полезный пентест или Red Team — это спарринг. Это не проверка уязвимостей, это проверка людей и процессов. Хорошая команда не будет стучаться в лоб в файрвол. Она начнет с фишинга на бухгалтерию, с поиска открытых сессий RDP в теневом интернете, с анализа мусорных корзин (физических и цифровых). Она попытается не просто пробить стену, а найти дверь, которую забыли закрыть, или уговорить секретаря открыть ее.

Формальный отчет вы просто читаете, а после хорошего упражнения у вас меняется регламент взаимодействия с подрядчиками, сотрудники перестают открывать письма от «Госуслуг», а админы начинают использовать двухфакторную аутентификацию для RDP. Меняется поведение системы, а не просто версия софта.

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

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

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

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

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

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