Минцифры обсуждает включение ERP систем в перечень КИИ

Минцифры обсуждает включение ERP систем в перечень КИИ

Минцифры обсуждает включение ERP систем в перечень КИИ

Минцифры совместно с рядом других ведомств рассматривает возможность отнесения ERP-систем к объектам критической информационной инфраструктуры (КИИ). Также обсуждается введение ответственности за несвоевременный переход с иностранных ERP-решений на отечественные аналоги, в том числе в виде налоговых санкций.

О том, что власти обсуждают включение ERP-систем в перечень объектов КИИ, сообщило издание РБК со ссылкой на источники в ИТ-отрасли и госструктурах.

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

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

Как отметил Николай Комлев, глава АПКИТ и руководитель центра компетенций и разработки ERP, около 30% российских компаний по-прежнему используют зарубежные ERP-системы, прежде всего SAP. Остальные перешли на отечественные продукты, 80% из которых построены на платформе «1С».

Заместитель гендиректора «Консист Бизнес Групп» Владимир Егоров сообщил, что на сегодня отсутствуют кейсы полного отказа от SAP в пользу российских систем. Максимум — это замена отдельных функциональных блоков. По словам коммерческого директора департамента 1С ГК «КОРУС Консалтинг» Рената Черныша, среди крупных компаний с выручкой более 50 млрд рублей проекты полного импортозамещения SAP также неизвестны. Чаще всего переход идет поэтапно.

Согласно информации источников РБК, SAP до сих пор используют «Северсталь», ВТБ, «Аэрофлот», «Внуково», «Сибур Холдинг» и ведущие телеком-операторы. При этом компании в ответ на запросы СМИ заявили, что намерены отказаться от SAP из-за отсутствия обновлений и риска уязвимостей. Например, в «Северстали» отмечают, что российские системы пока проигрывают по скорости закрытия отчетных периодов и качеству планирования.

Председатель Ассоциации крупнейших потребителей ПО и оборудования Рената Абдулина обратила внимание, что большинство отечественных ERP-решений изначально создавались для малого и среднего бизнеса. В результате крупные компании сталкиваются с ограничениями масштабируемости, сложностями внедрения и высокой стоимостью перехода. Также остаются проблемы с совместимостью с российскими ОС и СУБД.

«Обсуждаемая сейчас мера поможет ускорить переход на отечественные и менее уязвимые системы. При этом отстающие отрасли, как нерадивые школьники, придумывают оправдания, чтобы не замещаться», — отметил Николай Комлев. Он подчеркнул, что необновляемая ERP-система, находящаяся в центре управления предприятием, постепенно накапливает уязвимости и становится мишенью для атак.

Директор центра компетенций управления предприятием холдинга Т1 Алексей Стоянов считает, что ужесточение требований со стороны регулятора станет дополнительным стимулом к переходу на отечественные решения. Он напомнил, что ERP-системы обрабатывают значительные объёмы данных, включая персональные.

«Мы уверены, что до завершения перехода можем гарантировать стабильную работу существующей ERP. Основным риском остаётся отсутствие поддержки со стороны западных вендоров. Мы компенсируем его рядом «наложенных» мер и использованием отечественных решений в области информационной безопасности», — отметил директор по развитию ИТ «Т2 РТК Холдинга» Дмитрий Попов.

В то же время Ренат Черныш полагает, что инициатива по отнесению ERP к КИИ вряд ли ускорит переход: «Такой процесс требует основательной подготовки: от методологии и архитектуры до квалифицированных команд и соответствующей IT-инфраструктуры. Без этого есть риск, что компании пойдут по пути формального исполнения без реального импортозамещения».

Заместитель гендиректора по науке «СиСофт Девелопмент» Михаил Бочаров подтвердил наличие тенденции к созданию формальных проектов с параллельными системами отчетности. При этом основная работа по-прежнему ведётся в SAP. По его мнению, включение ERP-систем в перечень КИИ не решит ключевые проблемы — нехватку кадров, зрелых решений и сложности внедрения.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

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

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

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

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

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

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

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

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru