Рынок ИБ жалуется, но переходит на отечественный софт

Рынок ИБ жалуется, но переходит на отечественный софт

Рынок ИБ жалуется, но переходит на отечественный софт

ИБ сегодня испытывает большие трудности. Преодолеть их можно, объединив усилия всех участников рынка. Такое общее мнение высказывали эксперты на полях Positive Hack Days 11, который проходил на днях в Москве.

«Ситуацию на российском рынке ИБ напоминает игру в шахматы, — говорит представитель "Ростелеком-Солар" Владимир Дрюков. — Ферзь, ладья и другие сильные фигуры вдруг исчезли с доски защищающейся стороны. И эти фигуры надо спешно заменить, одновременно пытаясь какими-то способами увидеть атаки и отбить их пешками».

Эксперты видят в этой «партии» и плюсы. Компании, которые раньше только конкурировали, теперь объединились и стали вместе бороться с новыми угрозами. Они обмениваются информацией по TI, утечкам и поставкам ПО.

«Крайне важно, чтобы информация по атакам не окуклилась внутри заказчика, а была донесена до сообщества — через НКЦИ, ФСТЭК и все доступные возможности», — подчеркивает Дрюков.

Процесс импортозамещения в ИБ начался задолго до 24 февраля. Многие решения существовали раньше, но интересовались ими только единицы.

«Сейчас эти продукты, которые словно ждали своего часа, выходят на поверхность и неизбежно будут завоевывать рынок», — полагает генеральный директор Axoft Global Вячеслав Бархатов.

«Ускоренное импортозамещение» связано с двумя рисками: сокращение бюджетов у заказчика и отсутствие аппаратных платформ. Уход иностранных вендоров резко повысил интерес к продукции российских производителей, но у тех — пробелы в оборудовании.

«Вопрос с железом довольно острый, — рассказывает директор по продажам и развитию бизнеса компании «КриптоПро» Павел Луцик. — Мы тоже столкнулись с задержками по поставкам серверов и другого оборудования. Критической ситуации нет, но увеличились сроки».

Спикеры PHD соглашались: российский рынок ИБ получил сильный толчок в развитии. Отечественные продукты активно развиваются, в них появляются технологии, которых еще полгода назад не было.

Но не все так оптимистичны. В «РТК-Солар» приводят такие цифры:

«Более 80% решений в нашем портфеле — это отечественное ПО. По экосистемам, по незаметности для пользователей наше ПО пока отстает», — говорит директор центра комплексных проектов направления «Solar Интеграция» Николай Белобров. Он считает, что не нужно второпях заниматься «востокозамещением» западных решений:

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

Баги в ядре 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