Одним из основных драйверов импортозамещения ИТ-систем в промышленности является требование регуляторов. Для субъектов КИИ переход на отечественное программное обеспечение, в том числе инженерное, обязателен в соответствии с требованиями указов Президента РФ и руководящих документов ФСТЭК России и ФСБ России. Остальные («не-КИИ») принимают решение исходя из собственной оценки рисков эксплуатации иностранного ПО. Посмотрим на ситуацию с точки зрения практики информационной безопасности.
Требования по ИБ — теперь к подрядчикам
Если юридическое лицо не относится к субъектам КИИ или субъектам регулирования других требований по защите информации (Приказы ФСТЭК России №17 2013 года, № 31 2017 года), то в каком объеме на него распространяются нормы и требования по защите информации? Практики информационной безопасности показывают, что один из основных способов атак на хорошо укрепленные, эшелонированные системы защиты – это атаки через цепочку подрядчиков. В современном цифровом мире никто не в состоянии организовать «натуральное хозяйство». Понятие «непрофильных» активов прочно входит в обиход даже среднего бизнеса, а уж представить себе высокотехнологичное и масштабное производство без двух, а иногда и трех уровней подрядчиков попросту невозможно. Анализ актуальных результатов расследования инцидентов показывает, что злоумышленники все чаще прибегают к изощренным тактикам и не штурмуют хорошо защищенные корпоративные системы в лоб. Атаки последних лет строятся на поиске наиболее уязвимого звена, в котором уровень защиты ниже, но все еще сохраняется возможность проникнуть в защищаемую сеть. Подрядчики могут не иметь никакого статуса, обязывающего их соблюдать требования по защите информации, и даже не иметь доступа к защищаемой информации. Но в силу естественных причин, таких как «открытость информационных систем», «единое информационное пространство», «сквозной цикл» и других модных трендов цифровой трансформации, даже поставщики самых нижних уровней могут получать доступ к инфраструктуре основного объекта защиты. И при отсутствии должного уровня контроля такие структуры становятся слабым звеном в системе защиты, выпадая при этом из области нормативного регулирования.
Регулятор учитывает эту ситуацию, и нормотворческая деятельность ФСТЭК России направлена на устранение этого пробела. В марте этого года вступают в силу основные положения приказа ФСТЭК России №117 «Требования о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений». Как прямая норма права, он относится к государственным и подведомственным учреждениям, но как косвенная норма распространяется практически на весь реальный сектор экономики.
В федеральных органах исполнительной власти (ФОИВ) изданы ведомственные распоряжения, которые определяют, что все, кто с этими ФОИВами взаимодействуют, должны выполнять требования приказа 117 – в части, касающейся подрядчиков. В госкорпорациях также выпущены внутренние документы о том, что информационные системы, предназначенные для обработки информации ограниченного доступа, должны соответствовать требованиям данного приказа.
Поясним на примере. Конструкторское бюро разрабатывает продукцию специального назначения и в соответствии с требованиями государственного заказчика должно было выполнять требования по безопасности информации в объеме Приказа №17 ФСТЭК России от 2013 года, который не распространялся на его подрядчиков. Теперь, после вступления в силу Приказа №117 (которым отменяется действие Приказа №17), конструкторское бюро должно ознакомить подрядчиков с требованиями по информационной безопасности, а подрядчики обязаны их соблюдать. Если подрядчик в силу необходимости выполнения своих работ получает доступ к PLM-системе конструкторского бюро, то требования по защите информации от несанкционированного доступа в объеме Приказа 117 для данного подрядчика становятся обязательными, а если конструкторское бюро является субъектом КИИ, то и существенные требования Приказа ФСТЭК России №239 (в частности, в п. 29.3 – требования к прикладному программному обеспечению, к которому относится инженерное ПО). Если проанализировать основной перечень вышеуказанных требований регуляторов, то мы поймем, что их выполнение для иностранного программного обеспечения, мягко говоря, крайне затруднительно, так как одним из основных требований является анализ уязвимостей программного обеспечения, для проведения которого в большинстве случаев необходимо наличие исходных текстов и среды сборки программного обеспечения. Очевидно, что выполнение данных требований предполагает привлечение разработчика программного обеспечения в том или ином объеме.
В этом состоят организационные риски эксплуатации иностранного ПО, которые принято связывать с «бумажной безопасностью». Есть и технологические.
Не каждый Linux – доверенная ОС
В ноябре 2025 года «Трансмашхолдинг», один из лидеров мирового транспортного машиностроения, сообщил о тестировании системы проектирования «Компас-3D» на операционной системе Astra Linux. Компания пользуется отечественной CAD-системой более двух лет, а теперь встал вопрос её работы в ОС на базе Linux. В качестве основной предпосылки к этому шагу представители холдинга назвали «уход зарубежных вендоров ОС с рынка РФ и риск потери управляемости безопасностью ИТ ландшафта; также существует риск снижения качества прикладных программных продуктов отечественных вендоров из-за отсутствия полного доступа к документации и поддержке ушедших вендоров ОС и риск повышения давления регуляторов по расширению контура объектов КИИ».
Почему для замены Windows были выбраны не распространенные и популярные среди Linux-энтузиастов клоны Ubuntu или Mint? В целях информационной безопасности разработчики отечественных платформ ограничили состав допущенного к эксплуатации в их экосистеме ПО и ввели дополнительные меры ограничения и контроля. И это абсолютно обосновано. Известны инциденты, связанные с внедрением вредоносного ПО в репозитории разработчиков ПО для некоторых известных деривативов Debian, а также информация о компрометации репозиториев широко используемых фреймворков.
Если меры ограничения и контроля не вводить и «подтягивать» все необходимы зависимости из открытых репозиториев, то мы рискуем вытянуть в нашем неводе вместе с крабами пару диверсантов. Это принцип так называемого «композиционного» анализа – элемента безопасной разработки ПО, введенной ФСТЭК России в качестве одной из основных мер безопасности. В создаваемые экосистемы на базе «доверенных» отечественных ОС входным пропуском является декларация соответствия требованиям безопасной разработки программного обеспечения. Поэтому тем, кто ранее успешно тестировал и создавал элементы инфраструктуры на базе «открытых» клонов Linux, настало время озаботиться переходом на аналоги, которые входят в Реестр отечественного ПО и при разработке которых соблюдаются меры по безопасной разработке в соответствии с ГОСТ Р 56939.
Отключение лицензий – по всей кооперационной цепочке
Со стороны западных вендоров усиливается контроль в отношении механизмов защиты программного обеспечения от несанкционированного копирования. Чем дальше, тем больше возможностей отключить любой инстанс. Даже в отношении тех вендоров, которые занимают относительно лояльную позицию, есть риски, что при усилении давления на них будут произведены силовые отключения лицензий, принадлежащих российским компаниям.
Здесь мировая бюрократия солидарна независимо от ведомственной принадлежности: если предприятие является участником кооперационной цепочки в разработке или поставке техники двойного назначения, это уже достаточное основание распространить все требования на всех участников этой цепочки. Поэтому риск отключения лицензий существует не только для тех, кто непосредственно находится в санкционных списках. Для цепочки подрядчиков эти риски также подлежат рассмотрению и оценке.
Уязвимости ПО – управлять и устранять
Сегодня самые широкие массы приобщены к специальной терминологии инфобезопасности. Многие уже знают, что такое уязвимости, что есть такая дисциплина как «управление уязвимостями», которая направлена на снижение рисков, связанных с объективным наличием уязвимостей в абсолютно любом программном обеспечении.
Уязвимости есть и в российском ПО, разумеется. Но основа любого управления – информация. Достаточность и полнота информации – условие адекватного управления. Для отечественного программного обеспечения ведется масштабная работа по систематизации и классификации уязвимостей, их анализу, исследованию и устранению. ФСТЭК России постоянно совершенствует систему защиты информации и вводит новые технологические подходы, направленные на снижение количества уязвимостей в отечественном ПО и их максимально быстрое устранение. И большинство российских разработчиков активно участвуют в этих инициативах, предоставляют свои технологические площадки и стремятся максимально быстро внедрять рекомендуемые ФСТЭК России подходы. Можно ли ожидать такого же сотрудничества от западных вендоров? Каким образом и кто будет отвечать за устранение уязвимостей в иностранном ПО? Особенно, если в определенный момент есть риск, что придется заморозить версии и вообще прекратить обновления. Исходные тексты на иностранное ПО в основной своей массе недоступны, также как и затруднительно возложить на западного вендора обязательства оперативно устранять уязвимости и предоставлять информацию по компенсирующим мерам для ликвидации последствий от наличия таких уязвимостей. А значит и снижается эффективность управления рисками (и управления уязвимостями) в ИТ-инфраструктуре, где используется иностранное ПО.
Защита – внутри инфраструктуры
И наконец, затронем такие тонкие материи, как отладка и комплексирование средств защиты информации.
Мы входим в период, когда защита внешнего периметра становится лишь первичной, но далеко не основной мерой. Все наиболее известные инциденты кибербезопасности последних лет были связаны с успешными атаками, развивавшимися внутри инфраструктуры атакуемого объекта. Пути проникновения рассматривать не будем – это предмет отдельной проработки, скажем лишь, что контур обороны сместился внутрь объекта и уже все модели угроз рассчитываются исходя из того, что нарушитель попал внутрь инфраструктуры. А это значит, что внутри защищаемой сети нам необходимо настраивать различные средства защиты, обеспечивающие защиту от «горизонтального перемещения» – термин, обозначающий движение злоумышленника от одного компьютера к другому по сети атакованного объекта.
Средства защиты, устанавливаемые на рабочие станции и серверы с инженерным ПО, требуют тонкой настройки и отладки совместно с инженерным ПО. Особенно с ПО, связанным с использованием графических ускорителей (GPU), ресурсоемкими инженерными расчетами. Средства защиты встраиваются в файловые и сетевые стеки операционной системы и требуют настройки прикладного ПО, чтобы обеспечить бесконфликтную работу. А для такой отладки и комплексирования нужно знать детально, как работает инженерное ПО (внутренние программные интерфейсы, взаимодействие с ядром операционной системы, дисковой подсистемой, сетью и т.д.). Отечественные вендоры инженерного ПО развивают такую активность исходя из требований ФСТЭК России. А вот для западных вендоров подобный запрос не является приоритетным. Даже наоборот: закрытость проприетарных решений – давно известная проблема, которая сильно усложняет любые интеграции. Таким образом и при встраивании механизмов защиты информации (независимо от субъектности КИИ, так как защищаемые активы есть не только у субъектов КИИ) применение иностранного ПО создает серьезный технологический барьер.
Материал подготовлен Тимуром Белкиным, аналитиком по информационной безопасности АСКОН.
Возврат к списку