Всеслав Соленик, СберТех: Защита технологий и данных становится базовым условием существования бизнеса

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

Очень актуально сейчас обсудить, какие системные меры применяются в кибербезопасности финансового сектора: в феврале 2026 в Екатеринбурге проходил форум «Кибербезопасность в финансах». О чём там говорили эксперты и насколько это отражало реальное положение вещей?

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

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

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

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

Фокус смещается в сторону реагирования и восстановления. Меньше внимания уделяется отдельным средствам защиты, больше — комплексным подходам: экосистемам и интегрированным решениям.

А если говорить о борьбе с кибермошенничеством, есть ли у нас ощутимые результаты?

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

Существенная часть усилий направлена на повышение осведомлённости. Практически все зрелые организации системно работают с клиентами, объясняя распространённые сценарии мошенничества. Речь идёт о типовых схемах: звонки от имени «сотрудников органов», атаки с подменой руководителя и другие варианты социальной инженерии. Сегодня уже сложно встретить человека, который не сталкивался с подобными сценариями. Компании, в том числе через службы информационной безопасности (ИБ), ведут постоянную информационную работу и транслируют её максимально широкой аудитории: клиентам и гражданам.

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

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

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

Значительная доля атак связана с компрометацией цепочек поставок — до 80 % случаев. Речь идёт о сценариях, когда злоумышленники получают доступ через подрядчиков или вендоров, а уже через них выходят на защищённые организации, в том числе финансовые. Этот подход давно используется: при высокой защищённости целевой организации атака переносится на менее защищённые звенья — подрядчиков или их контрагентов.

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

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

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

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

Я на форуме услышала такую формулировку, что Приказ ФСТЭК России № 117 — это лопата, которой мы будем всё разгребать. Хотелось бы задать вопрос: как сейчас воспринимается бизнес в контексте безопасности? Это по-прежнему вендор, который приносит коробочное решение и закрывает все задачи? Или это уже партнёрская модель? Либо речь идёт о синергии всех участников процесса? И как в этом случае правильно выстраивать и понимать такие взаимоотношения?

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

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

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

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

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

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

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

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

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

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

Если перевести это на язык практических кейсов, какие конкретные решения сейчас используются?

В.С.: В портфеле есть несколько классов решений, связанных с кибербезопасностью. Первый блок — решения в области защиты данных и управления доступом. Platform V IAM — набор инструментов для управления доступом к информационным ресурсам. Он проверяет права доступа на вызовы API и совершение действий сервисом платформ. Решение рассчитано на высокую нагрузку, ориентировано на повышенные требования к безопасности и имеет сертификацию.

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

Отдельно выделяется направление IDM (Identity Management) — Platform V IDM. Это собственная разработка, созданная на фоне того, что существующие на рынке решения в какой-то момент не закрывали требуемый набор задач. По масштабу внедрения это одна из крупнейших инсталляций в стране. Есть реализованные кейсы миграции с зарубежных платформ, включая Oracle Identity Management (Oracle IDM) и IBM Identity and Access Management (IBM IAM).

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

В 2025 году решение было доведено до промышленной эксплуатации и развито до уровня Web Application Firewall (WAF) с расширенной логикой фильтрации. В составе платформы реализована среда исполнения правил и политик безопасности: от регулярных выражений до моделей машинного обучения (ML) и языковых моделей (LLM), с возможностью оркестрации и обработки высокой нагрузки.

В текущем виде продукт позиционируется как WAF. Platform V SOWA — API Security Gateway, который защищает и интегрирует API как внутри организации, так и с внешними системами. Он демонстрирует устойчивый интерес со стороны заказчиков в рамках текущих трансформаций ИТ-ландшафтов.

Всеслав, вы затронули вопрос доверия к подрядчикам. Как вы внутри решаете эту проблему?

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

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

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

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

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

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

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

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

Проверка проводится для open source, проприетарного ПО, репозиториев, прошивок пакетов и мобильных приложений. В 2025 году выполнена работа по направлению AI-рисков, включая анализ датасетов, RAG-баз, приложений и моделей open source на предмет возможной компрометации или отравления данных.

В рамках этой деятельности также предоставляются услуги для внешних заказчиков: программное обеспечение может быть направлено на анализ через защищённый портал-репозиторий, где уже проверено более 8000 дистрибутивов. Дополнительно доступен инструментарий для развёртывания собственной лаборатории анализа. Он включает контейнерную безопасность, статический и динамический анализ, а также более 60 различных инструментов — как разработанных самостоятельно, так и адаптированных open source-решений.

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

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

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

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

А какая философия СберТеха в кибербезопасности? Вы выросли из инсорс (поручение задач или проектов сотрудникам или отделам внутри организации вместо обращения за помощью к третьим лицам — прим. ред.)? У вас всё-таки экосистемность или вы можете встраиваться в другие истории?

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

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

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

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

В модели отсутствует привязка к одному стеку или жёсткий vendor lock-in (привязка к одному поставщику). Экосистема открыта и позволяет интегрировать как собственные технологии, так и решения, которые необходимы заказчику в его текущей инфраструктуре.

Сейчас, по сути, есть 2 подхода: экосистемный и отказ от моновендора. В вашем случае какой ближе?

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

Всё сводится к решению задачи заказчика. Я сам как заказчик, поскольку занимаюсь цифровыми технологиями и являюсь заказчиком всех средств безопасности внутри своей компании. Когда мы общаемся с вендорами, часто звучит позиция: либо вы берёте весь стек одного производителя, либо не работаете с нами. Или, условно, «все продукты одного цвета либо никак». Но на практике заказчик видит, что разные продукты могут сильнее закрывать разные задачи, и логично комбинировать их.

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

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

Есть и вопрос работы с open source. Многие вендоры либо ограничивают его использование, либо стараются от него дистанцироваться. На практике же это нормальная модель: часть задач решается на open source, затем при необходимости система переводится на поддерживаемые, сертифицированные решения.

В нашей логике важно, чтобы у заказчика была свобода выбора. Есть несколько вариантов: дорабатывать самостоятельно, работать через партнёров или привлекать нас как вендора. Мы стараемся не формировать жёсткий vendor lock-in. Наоборот, подход строится так, чтобы обеспечить максимальную гибкость для заказчика.

У СберТеха есть ряд сертифицированных продуктов. Расскажи подробнее об этом и почему им можно доверять.

В.С.: Если говорить о сертификации, то речь идёт о средствах, которые так или иначе относятся к классу средств защиты информации.

Это IAM, реализующий функции авторизации и идентификации с элементами безопасности. Он сертифицирован, постоянно обновляется. Ещё примеры: СУБД Platform V Pangolin DB, операционная система Platform V SberLinux OS, система контейнеризации Platform V DropApp. Всего сейчас порядка шести сертифицированных поддерживаемых продуктов. Плюс существует отдельный контур работ по сертификации, когда это требуется рынку.

Необходимость сертификации определяется тем, что в ИТ-продуктах и средствах кибербезопасности реализуются функции защиты информации. В рамках, например, приказов № 239, № 17, № 117, заказчик использует эти функции для выполнения регуляторных требований. В этом контексте и возникает потребность в сертификации. Например, решение класса IDM не имеет сертификата ФСТЭК, поскольку на рынке оно чаще рассматривается как средство автоматизации, а не как средство защиты информации. В таких случаях достаточно включения в реестр отечественного ПО.

Отдельно стоит отметить, что внутри компании конвейер разработки ПО также сертифицирован по ФСТЭК целиком. Компания является второй на рынке и одной из примерно девяти организаций, обладающих сертификацией конвейера разработки по ГОСТ Р 56939-2024. В рамках требований, в том числе приказа № 117 ФСТЭК России, такая сертификация подтверждает, что конвейер разработки соответствует установленным практикам безопасной разработки и прошёл внешний аудит. Это означает наличие формализованных процессов, мер контроля и подтверждение того, что ПО разрабатывается в соответствии с требованиями безопасности.

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

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

Вы упомянули, что один продукт не сертифицирован, потому что этого не требуется. А вы бы рекомендовали использовать сертифицированные продукты даже там, где это не нужно? Или всё-таки это индивидуально?

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

Плюс, сертификация создаёт определённый lock-in (эффект технологической привязки). Даже срок в 3–4 месяца остаётся задержкой: фактически приходится ждать завершения пересертификации версии, прежде чем вводить её в эксплуатацию. Это влияет на time-to-market (время вывода продукта или версии на рынок), и в ряде случаев этот цикл можно и нужно сокращать.

Перейдём к более горячему направлению — искусственному интеллекту. Он также находился в повестке Уральского форума. Его сейчас много и в кибербезопасности, и в других областях: где-то его уже слишком много, а где-то, наоборот, пока недостаточно.

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

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

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

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

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

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

Но там, где важно покрытие, это уже позволяет решать задачу. Например, в SOC, когда есть большой поток срабатываний и их необходимо обрабатывать на уровне объёма. При этом часть кейсов всё равно требует участия человека, особенно те, где необходима экспертная оценка. Либо другой пример — анализ уязвимостей. У нас есть уязвимости, которые выявляются сканерами, и их число очень большое. Критические и высокие уязвимости можно, как правило, обрабатывать вручную. Мы, например, не пропускаем ни одной — ноль критических и high-уязвимостей. Но low-уязвимостей настолько много, что их ручная обработка становится крайне дорогой.

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

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

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

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

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

В.С.: Я считаю, что нам принципиально нужен суверенный искусственный интеллект. Более того, он у нас уже есть.

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

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

Как вы видите развитие того, о чём говорили на Уральском инфофоруме? Если смотреть горизонт в 3–5 лет, или даже в пределах ближайшего года, какие изменения в кибербезопасности и смежных направлениях нас ожидают? Что можно считать наиболее вероятным сценарием развития?

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

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

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

Ещё одно направление — переход к AI-безопасности. Если раньше ключевыми активами были ИТ-системы и данные, то в перспективе искусственный интеллект станет таким же критически важным элементом, без которого невозможна работа бизнеса. Мы должны будем научиться защищать процессы, организации, государство и связанные с ними риски в условиях роботизированной ИИ-среды и, в определённой степени, дегуманизированного ландшафта.

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