Импортозамещение ИБ перестало быть заменой названий

Российские компании уже прошли первый, самый нервный этап импортозамещения в информационной безопасности.

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

В 2026 году этот вопрос выглядит иначе. На рынке уже есть российские решения в ключевых классах: межсетевые экраны, SIEM, EDR, средства защиты конечных точек, сканеры уязвимостей, IAM, DLP, NTA и другие продукты. Государство задало жесткий вектор: для госорганов, госкомпаний и субъектов КИИ переход на отечественные средства защиты перестал быть вопросом предпочтения. Приказ ФСТЭК № 117, вступивший в силу 1 марта 2026 года, дополнительно закрепил движение к эшелонированной защите, мониторингу инцидентов, управлению уязвимостями и безопасному циклу разработки.

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

На практике она уже изменилась.

Больше нельзя искать копию западного продукта

Самая понятная, но самая опасная логика - искать российский продукт, который повторит ушедшее западное решение один к одному. Такой подход кажется безопасным: был Fortinet, нужен максимально похожий межсетевой экран; был QRadar, нужна похожая SIEM; был Microsoft Defender for Endpoint, нужен EDR с близким набором функций.

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

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

«К задаче импортозамещения надо подходить комплексно. В любом случае это перепроектирование системы. Не надо копировать зарубежное решение один в один - надо отталкиваться от реальных задач и сценариев использования. На практике обычно не нужен весь передовой функционал - можно решить задачу более простыми способами», - говорит Владислав Ганжа, директор Лаборатории кибербезопасности UDV Group.

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

Импортозамещение стало архитектурным проектом

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

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

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

Если межсетевой экран, EDR, SIEM, сканер уязвимостей и ServiceDesk живут раздельно, безопасность снова превращается в набор экранов. События есть, но контекста мало. Алерты есть, но маршрут инцидента нужно собирать вручную. Требования выполнены, но эксплуатация остается сложной.

Поэтому зрелое импортозамещение - это не закупка российского продукта вместо иностранного. Это пересборка процессов защиты вокруг реальной инфраструктуры компании.

Пилот стал обязательным фильтром

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

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

Особенно важно пилотировать решения под нагрузкой, близкой к реальной. Для NGFW нужно проверять производительность с включенными функциями защиты, IPS, VPN, кластеризацией и политиками, а не только пропускную способность в идеальном режиме. Для SIEM - подключение конкретных источников, скорость поиска, правила обнаружения и трудозатраты SOC. Для EDR - поддерживаемые ОС, полноту телеметрии, сценарии реагирования и совместимость с текущими процессами эксплуатации.

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

Совместимость нельзя проверять общей формулировкой

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

Новый ИБ-продукт должен жить именно в этой среде. Поэтому фразы «поддерживает Linux», «интегрируется с SIEM», «работает с каталогом пользователей» или «имеет API» недостаточны. Важны конкретные версии, форматы событий, способы интеграции, ограничения агентов, поведение после обновлений, влияние на производительность и порядок восстановления при сбое.

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

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

Миграция данных - не второстепенная работа

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

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

«Любое новое решение, не важно, российское или зарубежное, может не подойти для решения задачи по разным причинам. Это можно минимизировать четкими требованиями в ТЗ и предварительным пилотированием. Миграция данных действительно может быть довольно трудоемкой - далеко не всегда есть возможность перенести данные один в один. Работы по переносу данных - важная часть проекта, про это не надо забывать», - отмечает Владислав Ганжа, директор Лаборатории кибербезопасности UDV Group.

Это особенно важно для SIEM, EDR, DLP, IAM и систем управления уязвимостями. Там ценность продукта часто находится не только в установленном ПО, но и в накопленной операционной логике. Если ее потерять, новая система может быть современнее прежней, но первое время хуже защищать компанию, потому что команда заново учится видеть важные события.

Самый опасный период - между старой и новой системой

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

Это одна из самых недооцененных угроз. Если прежняя SIEM уже отключена, а новая еще не получает все нужные события, SOC видит только часть картины. Если старый EDR снят, а новый агент еще не развернут на критичных узлах, часть рабочих станций остается без нормальной телеметрии. Если DLP, IAM или сканер уязвимостей меняются без параллельной эксплуатации, компания может временно потерять контроль над каналами данных, доступами или уязвимостями.

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

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

Российские аналоги есть, но выбор нельзя делать по таблице

На рынке уже сформировались российские решения, которые чаще всего рассматриваются как альтернатива ушедшим зарубежным продуктам. Для Fortinet FortiGate компании смотрят на UserGate NGFW и Ideco NGFW. Для IBM QRadar - на MaxPatrol SIEM, Security Vision SIEM и Kaspersky Unified Monitoring and Analysis Platform. Для Microsoft Defender for Endpoint - на решения Kaspersky для защиты конечных точек и EDR, MaxPatrol EDR, Security Vision EDR.

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

Поэтому корректнее говорить не о «полноценной замене в вакууме», а о проверенной замене для конкретного сценария. В ИБ универсальных ответов почти нет. Есть требования, нагрузка, архитектура, команда, регуляторика и риск, который компания готова или не готова принять.

Бумажная безопасность стала слишком дорогой

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

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

Такая безопасность опасна тем, что создает ложное чувство завершенности. Компания считает, что замена произошла, хотя на самом деле только началась эксплуатационная работа.

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

Следующий этап - управляемая экосистема

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

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

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

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