Сегмент коммерческих SOC растет быстрее рынка

Сегмент коммерческих SOC растет быстрее рынка

Сегмент коммерческих SOC растет быстрее рынка

Сегмент коммерческих центров мониторинга киберугроз (SOC) демонстрирует самые высокие темпы роста на рынке информационной безопасности. По оценкам экспертов, его текущая насыщенность составляет не более 50%. Основными клиентами коммерческих SOC остаются компании среднего бизнеса.

Согласно подсчётам компании «Спикател», которые привёл «Коммерсантъ», в первом квартале 2025 года этот сегмент вырос на 20% в годовом выражении.

По итогам всего года, как отметил в комментарии для издания ведущий аналитик по мониторингу ИБ «Спикател» Алексей Козлов, рост может достичь 60%. Общий объём российского рынка SOC он оценил в 25–27 млрд рублей. В среднем услуги коммерческого SOC обходятся заказчику в 5–10 млн рублей в год.

При этом всё больше клиентов заказывают дополнительные услуги, выходящие за рамки базового пакета. По словам директора центра мониторинга противодействия кибератакам IZ:SOC компании «Информзащита» Александра Матвеева, растёт интерес к углублённым расследованиям инцидентов.

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

Управляющий директор Positive Technologies Алексей Новиков также отмечает интерес к гибридным моделям SOC, сочетающим внутренние и внешние ресурсы. Такие решения позволяют эффективнее противодействовать угрозам, соответствовать требованиям регуляторов и при этом оптимизировать затраты. По его словам, даже представители малого бизнеса начинают проявлять интерес хотя бы к базовым сервисам SOC.

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

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

Руководитель департамента мониторинга и реагирования «Инфосистемы Джет» Ринат Сагиров в числе причин отказа от внешних подрядчиков также называет риски, связанные с атаками на цепочки поставок, и возможное расширение поверхности атаки.

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

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

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

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