Архив за месяц: Апрель 2026

Про уязвимость Elevation of Privilege - Linux Kernel "Copy Fail" (CVE-2026-31431)

5 комментариев

Про уязвимость Elevation of Privilege - Linux Kernel Copy Fail (CVE-2026-31431)

Про уязвимость Elevation of Privilege - Linux Kernel "Copy Fail" (CVE-2026-31431). Уязвимость локального повышения привилегий в компоненте ядра Linux AF_ALG, которая вызвана ошибкой работы с памятью, позволяет непривилегированному пользователю поднять привилегии до root-а. Проэксплуатировав эту уязвимость, злоумышленник может полностью захватить систему: читать и изменять любые файлы, включая пароли и ключи, подменять системные бинарные файлы, отключать защитные механизмы и средства мониторинга, незаметно устанавливать бэкдоры и закрепляться в системе, скрывать следы своей активности, использовать хост как плацдарм для атак на другие сетевые активы.

⚙️🛠 1 апреля патчи, устраняющие уязвимость, были внесены в основную ветку Linux Kernel. 22 апреля был заведён CVE идентификатор уязвимости. 29 апреля эксперты компании Theori опубликовали разбор уязвимости и публичный эксплойт. Эксплуатабельность уязвимости была подтверждена на актуальных версиях популярных дистрибутивов Linux: Ubuntu, Amazon Linux, RHEL, SUSE.

👾 1 мая уязвимость была добавлена в CISA KEV, что свидетельствует об эксплуатации уязвимости в реальных атаках.

Что отличает эту уязвимость от подобных EOP/LPE в Linux?

В Linux Kernel уже были громкие уязвимости повышения привилегий. Dirty Cow требовала выигрыша в race condition. Часто приходилось делать несколько попыток, и иногда это приводило к падению системы. Dirty Pipe была привязана к конкретным версиям и требовала точных манипуляций с pipe buffer.

Но, в отличие от Dirty Cow и Dirty Pipe, как сообщают исследователи, Copy Fail - это прямолинейная логическая ошибка. Она срабатывает без гонок, повторных попыток или нестабильных временных окон, приводящих к сбоям.

🧬 Портируемость. Один и тот же скрипт эксплуатации работает на всех протестированных дистрибутивах и архитектурах, включая Ubuntu, Amazon Linux, Red Hat Enterprise Linux и SUSE Linux Enterprise. Никаких оффсетов под конкретный дистрибутив. Никакой перекомпиляции. В эксплоите нет проверок версии.

✧ Минимализм. Весь эксплойт - это короткий скрипт на Python, использующий только стандартные модули библиотеки os, socket, zlib. Требуется Python 3.10+ для os.splice. Никаких скомпилированных нагрузок, никакой установки зависимостей.

🥷 Скрытность. Операция записи выполняется, минуя обычный путь записи VFS ("ordinary VFS write path"). Повреждённая страница никогда не помечается ядром как dirty в механизме writeback. Стандартные инструменты контроля целостности файлов, сравнивающие контрольные суммы на диске, не заметят эксплуатацию, потому что файл на диске не изменяется. Повреждается только кэш страниц в памяти.

📦 Межконтейнерное воздействие. Кэш страниц разделяется всеми процессами в системе, в том числе между контейнерами. Copy Fail - это не просто локальное повышение привилегий. Это примитив выхода из контейнера и вектор компрометации узла Kubernetes.

Как устранить уязвимость?

Для устранения уязвимости пользователям необходимо обновиться до версий ядра Linux 6.18.22, 6.19.12 и 7.0. Ядро можно собрать самостоятельно или дождаться, когда обновления пакетов ядра выпустит вендор вашего Linux-дистрибутива. По состоянию на 4 мая вышли обновления для Ubuntu, Debian, RHEL, Fedora, SUSE, CloudLinux, Arch Linux, ROSA Linux.

В качестве workaround-а исследователи предлагают заблокировать создание сокетов AF_ALG:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Добавить комментарий

Закончу разбирать основной VM-ный пункт 3.3. Управление уязвимостями (КУ) из недавно опубликованного методического документа Мероприятия и меры по защите информации, содержащейся в информационных системах, и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. В прошлый раз я расписал Цели и Требования к реализации, сегодня рассмотрю Требования к документированию и Требования к усилению.

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

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

👥 Подразделения / работники

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

Получается, что подразделения (работники) делятся на:

🔹 ответственных за организацию и контроль управления уязвимостями;
🔹 участвующих в реализации процессов управления уязвимостями.

Для каждого подразделения (работника) необходимо расписать:

🔹 обязанности (функции);
🔹 права (полномочия).

Напрашивается таблица следующей структуры:

Подразделение (работник); За что отвечает; В реализации каких процессов участвует; Обязанности (функции); Права;

📋 Операции

Требования по документированию операций имеют идентичную структуру:

"описание операций, осуществляемых при {название этапа (подпроцесса)}, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при {название этапа (подпроцесса)}"

Буквально вот так:

"описание операций, осуществляемых при мониторинге уязвимостей и оценке их применимости, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при мониторинге уязвимостей и оценке их применимости;
описание операций, осуществляемых при оценке уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при оценке уязвимостей;
описание операций, осуществляемых при определении методов и приоритетов устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при определении методов и приоритетов устранения уязвимостей;
описание операций, осуществляемых при устранении уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при устранении уязвимостей;
описание операций, осуществляемых при контроле устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при контроле устранения уязвимостей;"

Напрашивается таблица следующей структуры:

Этап (подпроцесс); Наименование операции; Описание операции; Перечень исполнителей; Продолжительность реализации; Входные данные; Выходные данные;

Типовые операции и их описания можно взять из Таблиц 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2 "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

🗺️ Схемы

"схемы взаимодействия подразделений (работников) при реализации операций по управлению уязвимостями."

Интересно, что здесь требуются схемы взаимодействия при реализации операций. А операция, в терминах РУУ23, - это что-то более-менее атомарное, чем занимается один исполнитель. Например, "Анализ информации об уязвимости" или "Корректировка механизмов мониторинга". Это не тот уровень, где подразумевается взаимодействие. Есть подозрение, что авторы здесь имели в виду не конкретные операции, а этапы (подпроцессы). По аналогии с тем, как этапы разрисованы в РУУ23 на Рисунках 2.2, 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2. Здесь требуется разъяснение регулятора, какие именно схемы должны быть приведены в регламенте. Текущая формулировка неоднозначна.

📜 Какие различия с драфтом?

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

Остальные правки касались только орфографии.

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

ТРЕБОВАНИЯ К УСИЛЕНИЮ

Насколько вообще обязательны требования из этого раздела? Читаем в сноске в пункте 3.1:

"Усиления мероприятий (процессов) по защите информации, приведенные в подразделах «требования к усилению» раздела 3, применяются по решению оператора (обладателя информации) для повышения эффективности реализации мероприятий по защите информации и повышения уровня защищенности информационных систем и содержащейся в них информации, а также для снижения возможности нарушителей по реализации угроз безопасности информации.

⚙️ Автоматизация

1) для управления уязвимостями используются автоматизированные системы управления уязвимостями;

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

👾 Анализ угроз

2) для мониторинга уязвимостей применяются средства анализа угроз, в том числе TI-платформы;

Фактически это требование означает, что управление уязвимостями должно стать частью CTEM (Continuous Threat Exposure Management) и учитывать данные о реальной эксплуатации уязвимостей: какие из них уже используются атакующими, какие техники применяются и в каких сценариях. В связке с анализом путей атаки это позволяет понимать, как уязвимости используются злоумышленниками для проникновения к целевым активам, и соответственно приоритизировать их устранение.

🗃️ CMDB

3) для оценки применимости уязвимостей используются данные, содержащиеся в автоматизированных системах сбора и хранения данных об объектах инвентаризации и их конфигурациях (СMDB-системы); (в документе в "СMDB" кириллическая С 🤷‍♂️)

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

🤝 Смежные процессы

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

Это требование означает, что контроль устранения уязвимостей должен опираться на перекрёстные проверки из уже существующих процессов - мониторинга ИБ, управления обновлениями и управления конфигурациями. Такой подход снижает риск ошибок, когда устранение уязвимости подтверждается только средством анализа защищённости (САЗ), но фактически проблема в системе сохраняется. Использование нескольких независимых источников позволяет подтвердить факт устранения с разных сторон и повысить достоверность контроля.

📜 Какие различия с драфтом?

В релиз не вошло требование "для мониторинга уязвимостей и оценки их применимости используются результаты контроля (оценки) уровня защищенности информации;"

Очень жаль, что убрали этот пункт, потому что результаты пентестов и независимого анализа защищённости часто выявляют уязвимости, которые по каким-то причинам не обнаруживаются штатными САЗ, используемыми в процессе управления уязвимостями. Такие находки являются индикатором проблем в процессе: недостаточного покрытия активов, низкого качества детектирования или несоблюдения сроков устранения. Они позволяют объективно оценить эффективность VM-процесса и улучшить его.

Остальные исправления касаются опечаток и косметических изменений.

---

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

Апрельский "В тренде VM": уязвимость в Microsoft SharePoint

1 комментарий

Апрельский В тренде VM: уязвимость в Microsoft SharePoint

Апрельский "В тренде VM": уязвимость в Microsoft SharePoint. Представляю традиционную ежемесячную подборку трендовых уязвимостей по версии Positive Technologies. Она снова моновендорная, майкрософтовская, и в этот раз компактнее некуда. Если в прошлом мартовском было четыре трендовые уязвимости, то в этом апрельском только одна. В следующем майском ожидаем как минимум три трендовые уязвимости. 😉

🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Уязвимость из январского Microsoft Patch Tuesday:

🔻 RCE - Microsoft SharePoint (CVE-2026-20963). Уязвимость сначала считалась менее опасной из-за требования аутентификации PR:L, но после пересмотра Microsoft выяснилось, что аутентификация для эксплуатации не нужна PR:N. Уязвимость добавили в CISA KEV, а значит злоумышленники уже эксплуатируют её в реальных атаках. Публичных эксплоитов пока нет.

🟥 Полный список трендовых уязвимостей смотрите на портале

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса

Добавить комментарий

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса. Об этом в своём блоге пишет Daniel Stenberg - создатель и ведущий разработчик проекта curl. В конце прошлого года он показывал статистику багрепортов на HackerOne: подтверждённых уязвимостей становилось меньше, а общее число репортов при этом росло, в основном за счёт низкокачественной AI-генерёнки. Ситуация усугубилась в начале 2026 года до той степени, что 1 февраля curl закрыли свою баг-баунти программу на HackerOne и начали принимать репорты только на GitHub. Но спустя месяц они вернулись на HackerOne ("как только поняли, что GitHub недостаточно хорош") и обнаружили, что характер сдаваемых репортов о проблемах безопасности изменился:

📈 Больше объём, выше качество. Проблема со slop-ом больше не актуальна. Частота поступления репортов выше, чем когда-либо. В последнее время она примерно в два раза выше, чем в 2025 году, который и так более чем вдвое превышал предыдущие годы. Качество выше. Доля подтверждённых уязвимостей вернулась на уровень до эпохи AI в 2024 году и даже превысила его примерно на 15-16%. Кроме того, значительно выросла доля репортов с багами, а не с уязвимостями.

🤖 Почти каждый репорт сейчас в той или иной степени формируется с использованием AI. Это видно по формулировкам, стилю изложения и по тому, что даже повторные репорты об уже известной проблеме выглядят тщательно проработанными ("and also by the fact that they now easily get very detailed duplicates"). Люди вручную не могут так писать. Однако разница по сравнению с прошлым в том, что сейчас большинство таких репортов очень высокого качества.

📊 Такая картина не только с curl. Daniel Stenberg провёл быстрый неформальный опрос в Mastodon, чтобы выяснить, наблюдают ли другие open source проекты аналогичные тенденции. И, как оказалось, да. Представители ряда проектов подтвердили, что также фиксируют данный тренд. Речь о Apache HTTP Server, BIND, curl, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL… Разумеется, конкретные показатели и масштабы различаются, однако это указывает на то, что явление не является специфичным для какого-либо одного проекта. Daniel Stenberg предполагает, что этот список проектов - просто случайная выборка тех, кто увидел его опрос. Проектов наверняка больше.

💥 Взрывной рост количества уязвимостей. Когда команда curl выпустит curl 8.20.0, в конце апреля 2026 года, там пофиксят как минимум шесть новых уязвимостей. Если предположить, что тренд сохранится хотя бы до конца года, а Daniel Stenberg считает это разумным предположением, то в этом году проект curl пофиксит рекордное количество CVE. В 2026 году может быть опубликовано около 50 уязвимостей curl. Что-то подобное должно ожидаться и в других проектах, т.к. тренд универсальный.

Что будет дальше?

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

🔻 Некоторые эксперты предполагают, что с AI ресёрчем и репортингом через несколько лет наступит плато, как было с фаззинг-тестированием. В настоящее время остаётся лишь наблюдать за дальнейшей эволюцией этого процесса.

🔻 Данная лавинообразная динамика, вероятно, ещё больше усилит нагрузку на мейнтейнеров. Ряду проектов будет сложно справляться с ростом бэклога без привлечения дополнительной поддержки.

🔻 Можно предположить, что в текущих условиях это также создаёт благоприятные возможности для злоумышленников: используя аналогичные инструменты, они могут находить значительное количество проблем быстрее, чем у проектов появятся ресурсы для их устранения.

🔻 В дальнейшем всем пользователям потребуется обновляться до новых исправленных версий пакетов, что, как ожидается, может занять значительное время.

Таким образом, отрасль, вероятно, ожидает период повышенной нестабильности.

От себя могу добавить, что рост количества исправляемых CVE в Linux-софте (не только в ядре!) виден и в рамках Linux Patch Wednesday. В апреле количество CVE было максимальным (1035) за всё время (май 2024 года исключаем, там высокое значение было связано с изменением алгоритма). Будем наблюдать и анализировать. 😉

На выходных ходили в Пушкинский музей на детское занятие "Кто живет в музее?"

Добавить комментарий

На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?На выходных ходили в Пушкинский музей на детское занятие Кто живет в музее?

На выходных ходили в Пушкинский музей на детское занятие "Кто живет в музее?". Вот умеют в Пушкинском выстроить вокруг экспонатов интересную историю:

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

По детским экскурсиям Пушкинский однозначно топ! 🙂

Один из моих самых любимых экспонатов в Пушкинском - канделябр с фигурой Фавнессы. Франция, вторая половина XVIII века. По модели Клодиона (Клод Мишель, 1738–1814), бронза, золочение; камень. К нему в пару есть канделябр с Фавном, но он мне нравится меньше. 😅

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки

1 комментарий

Начну разбирать основной VM-ный пункт 3.3. Управление уязвимостями (КУ) из недавно опубликованного методического документа Мероприятия и меры по защите информации, содержащейся в информационных системах, и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. Также сделаю предположения, откуда были взяты формулировки. Номер и название пункта остались теми же "3.3. Управление уязвимостями", но добавился двухбуквенный маркер "КУ", который, по всей видимости, означает "Контроль Уязвимостей".

Формулировка цели. "Цель: Своевременное выявление уязвимостей информационных систем, оценка их критичности, определение методов и приоритетов устранения уязвимостей, а также контроль за устранением уязвимостей". Она полностью совпадает с тем, что было в драфте. Фактически это перечисление этапов (или подпроцессов) VM-процесса. Имхо, цель должна отвечать на вопрос не "что делаем", а "какого результата достигаем": снижение уровня риска информационной безопасности, уменьшение количества эксплуатабельных уязвимостей или повышение защищенности информационных систем. Но сформулировано как сформулировано. 🤷‍♂️

Требования к реализации. Раздел начинается с перечисления того, что управление уязвимостями должно предусматривать. Это также перечисление этапов (подпроцессов), но несколько по-другому сформулированных. Они совпадают с этапами из "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

Распишу маппинг формулировок из требований к реализации / РУУ23 и целей управления уязвимостями:

🔹 мониторинг уязвимостей и оценка их применимости → выявление уязвимостей информационных систем
🔹 оценка уязвимостей → оценка критичности уязвимостей
🔹 определение методов и приоритетов устранения уязвимостей → определение методов и приоритетов устранения уязвимостей ✅
🔹 устранение уязвимостей → ❓
🔹 контроль устранения уязвимостей → контроль за устранением уязвимостей

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

Далее по каждому этапу (подпроцессу) перечисляются требования к реализации.

🔎 Мониторинг уязвимостей и оценка их применимости

"В ходе мониторинга уязвимостей и оценки их применимости осуществляются выявление уязвимостей на основании данных, получаемых из внешних (базы данных известных уязвимостей, официальные ресурсы разработчиков программных средств, специализированные публикации, форумы, иные источники) и внутренних (средства анализа защищенности, иные средства защиты информации, данные о составе программных, программно-аппаратных средств) источников, и принятие решения о применимости уязвимостей к информационным системам." (в оригинальном документе после слова "получаемых" лишний перенос строки)

Очевидно, эта формулировка частично взята из описания соответствующего этапа в РУУ23: "На этапе мониторинга уязвимостей и оценки их применимости осуществляется выявление уязвимостей на основании данных, получаемых из внешних и внутренних источников, и принятие решений по их последующей обработке". Были только добавлены примеры внутренних и внешних источников данных.

В этом пункте регулятор предписывает выстроить полноценную работу по выявлению уязвимостей, в которой автоматизированные средства анализа защищенности (САЗ) являются лишь одним из источников данных. Если детектирование уязвимостей для какого-то класса систем или технологий не поддерживается имеющимися САЗ, это не означает, что детектирование и устранение уязвимостей в них можно вовсе не осуществлять. Для каждой уязвимости, актуальной для инфраструктуры, необходимо понимать, как и чем она будет детектироваться. В случае отсутствия готовых САЗ может потребоваться разработка собственных средств автоматизации либо проведение анализа на наличие уязвимостей вручную. Поэтому использование САЗ с наилучшим качеством детектирования уязвимостей становится в том числе способом снизить объем in-house разработки и ручной работы.

⚖️ Оценка уязвимостей

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

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации)". При этом в драфте было: "В ходе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации) в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств, утвержденной ФСТЭК России." В драфте оценка критичности уязвимостей была возможна исключительно по методике ФСТЭК. То есть процесс был жестко регламентирован. В релизе это требование убрано, и осталась только общая обязанность определять уровень критичности уязвимостей.

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

Можно возразить: сроки устранения устанавливаются напрямую 117 приказом. Да, но эти сроки зависят от критичности уязвимости, которая будет определяться непонятно как. 🤷‍♂️ В целом, на мой взгляд, в драфте было сформулировано лучше. Хочется надеяться, что я ошибаюсь и необходимость использовать методику ФСТЭК по оценке уровня критичности уязвимостей всё-таки закрепляется где-то в другом месте. Здесь нужны разъяснения регулятора.

🧭 Определение методов и приоритетов устранения уязвимостей

"В ходе определения методов и приоритетов устранения уязвимостей определяется приоритетность устранения уязвимостей и выбираются методы их устранения: обновление программного обеспечения и (или) применение компенсирующих мер защиты информации." (в оригинальном документе после слова "методы" лишний перенос строки)

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе определения методов и приоритетов устранения уязвимостей определяется приоритетность устранения уязвимостей и выбираются методы их устранения: обновление программного обеспечения и (или) применение компенсирующих мер защиты информации". Различий с драфтом нет. Фактически здесь фиксируются только методы устранения уязвимостей: обновление программного обеспечения или применение компенсирующих мер. Про приоритизацию ничего не пишут, но, видимо, предполагается, что она будет выполняться в соответствии с оценкой критичности уязвимости из предыдущего пункта. Добавить несколько слов о приоритизации было бы неплохо. Например, что приоритизация должна проводиться с учетом уровня критичности уязвимостей, их реальной эксплуатабельности и использования в потенциальных путях атаки. При этом приоритет устранения уязвимостей должен определяться с акцентом на разрыв критических путей атаки и предотвращение компрометации ключевых активов.

⚙️ Устранение уязвимостей

"В ходе устранения уязвимостей принимаются меры, направленные на устранение или исключение возможности использования (эксплуатации) нарушителем выявленных уязвимостей. Время, в течение которого должны быть приняты меры по устранению уязвимостей, определяется исходя из уровня критичности уязвимости и в соответствии с требованиями о защите информации, утвержденными ФСТЭК России." (в оригинальном документе после слова "направленные" лишний перенос строки)

Очевидно, первое предложение взято из описания соответствующего этапа в РУУ23: "На этапе устранения уязвимостей принимаются меры, направленные на устранение или исключение возможности использования (эксплуатации) выявленных уязвимостей." Добавлено только слово "нарушителем". Второе предложение - отсылка к требованиям по срокам устранения из 117 приказа. Различий с драфтом в формулировке нет. Этот абзац вызывает вопросы тем, что вводится некое "исключение возможности использования (эксплуатации) нарушителем выявленных уязвимостей", которое формально отличается от "устранения уязвимостей". Хотя по сути речь идет об устранении уязвимостей методом применения компенсирующих мер (см. предыдущий пункт). В результате становится непонятно, определяются ли требования по SLA на "исключение возможности эксплуатации" исходя из уровня критичности уязвимости (непонятно как определяемого 🙄) в соответствии с 117 приказом или нет. Зачем вводить дополнительные сущности и создавать неоднозначности - непонятно. 🤷‍♂️ При этом здесь никак не регламентируется, как должен быть выстроен процесс взаимодействия между VM и IT. Допустимо ли передавать в IT (прямо в почту CTO 😅) огромные отчеты без конкретных рекомендаций по устранению? Формально, исходя из этого пункта, так делать можно. Но насколько это будет эффективно - большой вопрос. 😏

🔭 Контроль устранения уязвимостей

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

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе контроля устранения уязвимостей осуществляется сбор и обработка данных о процессе управления уязвимостями и его результатах, а также принятие решений по улучшению данного процесса". В релизе исправлена грамматика: "осуществляется сбор и обработка данных" заменено на "осуществляются сбор и обработка данных". В текущем виде пункт не про контроль устранения уязвимостей и соблюдение SLA как таковых. Он смещён в сторону более высокого уровня и описывает сбор и анализ данных о том, как в целом работает процесс управления уязвимостями, оценку его результатов и принятие решений по его улучшению. То есть речь идёт не об операционном контроле закрытия конкретных уязвимостей, а о мониторинге и повышении эффективности всего VM-процесса. Улучшение процесса - это важно, но хотелось бы, чтобы пункт "контроль устранения уязвимостей" был прежде всего про контроль устранения конкретных уязвимостей, раз уж он так называется.

Итого, что же можно сказать об описании требований к реализации этапов (подпроцессов). Очевидно, авторы хотели описать их так, чтобы РУУ23 им полностью соответствовал, поэтому формулировки были взяты оттуда с небольшими изменениями. Но проблема в том, что для РУУ23 раздел 2.1 - это лишь самое общее описание, а полноценно и подробно требования раскрываются в соответствующих разделах РУУ23. Поэтому неполнота и неточность формулировок в 2.1 РУУ23 вполне простительны, а при перенесении в рассматриваемый документ вызывают вопросы и недоумение. Имхо, правильно было бы формулировки требований переработать и расширить (имея ориентиром всё тот же РУУ23). Ну или прямо предписать использование РУУ23. 😉

🔄 Завершается раздел требованиями по актуализации сведений об уязвимостях:

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

По сравнению с драфтом изменили только орфографическую ошибку. Очевидно, формулировка взята из 2.2 РУУ23: "Процесс управления уязвимостями организуется для всех информационных систем органа (организации) и должен предусматривать постоянную и непрерывную актуализацию сведений об уязвимостях и объектах информационной системы. При изменении статуса уязвимостей (применимость к информационным системам, наличие исправлений, критичность) должны корректироваться способы их устранения". Разница: в релизе "информационные системы оператора", а не "системы органа (организации)". Если это критично, тогда странно, почему в требованиях выше остались "органы (организации)"? 🤔 "Объекты информационной системы" расписаны как "состав программных и программно-аппаратных средств информационных систем", что, наверное, действительно лучше. Изменение "критичность" на "уровень критичности" тоже можно приветствовать.

По сути, если уязвимость была запланирована в задаче на патчинг через месяц, но для неё появились эксплоиты и признаки эксплуатации вживую, её нужно исключить из этой задачи и перепланировать устранение в рамках срочного патчинга. 👍 Единственное, что в отрыве от РУУ23 "корректировка способов устранения уязвимостей" может пониматься по-разному. Было бы лучше, если бы было конкретизировано, что речь о том, что если уязвимость стала объективно более критичной, то это изменение нужно отследить и устранить уязвимость в более сжатые сроки.

❌ И закончить этот пост хотелось бы двумя требованиями к реализации, которые были в драфте, но из релиза были исключены:

🔹 "Процесс управления уязвимостями должен быть взаимоувязан с другими процессами и процедурами деятельности органа (организации) в области защиты информации и информационных технологий."

Это фактически пункт 2.3 РУУ23: "Процесс управления уязвимостями связан с другими процессами и процедурами деятельности органа (организации)". Речь там идёт о процессах мониторинга информационной безопасности, оценки защищенности, оценки угроз безопасности информации, управления конфигурацией, управления обновлениями, применения компенсирующих мер защиты информации. В целом, идея правильная, но, возможно, этому пункту в данном документе действительно не место.

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

Это фактически сокращённый пункт 2.4 РУУ23: "Участниками процесса управления уязвимостями являются…". Также не вижу большого вреда от отсутствия этого пункта в документе, так как перечень участников процесса и выполняемых ими операций будет сильно зависеть от конкретной организации.

На этом пост заканчиваю, "Требования к документированию" и "Требования к усилению" рассмотрю в следующей части.

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026

Добавить комментарий

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026. Там в аналитике основные моменты: количество вакансий сокращается, а искусственный интеллект начинает играть всё большую роль. Об этом можете подробнее у Евгения Баклушина почитать. У меня же в связи с этой публикацией основной вопрос другой: а где в этой статистике по ИБ-специалистам VM-щики? Ну или даже шире, где здесь инфраструктурная безопасность? Большая проблема в том, что нас (VM-щиков) не видно, незаметно. В отличие от пентестеров, AppSec, DevSecOps, SOС-оводов, архитекторов ИБ и методологов.

Нас вообще вроде как бы и нет. 🤷‍♂️ Нет отдельных дискуссионных площадок или специализированных конференций. Соответственно нет и понимания, что под VM должны быть выделенные роли в организации, а специалистам на этих ролях необходимо платить достойную зарплату. Даже VM-вендоры говорят, что VM-щик на part time - это норма (на самом деле не так 🙄).

Что делать с этим? 🤔 Имхо, кроме нас самих VM-ную тему в России никто качать не будет. Давайте как-то развивать нашу идентичность. Если вы в этой области трудитесь, неважно, на стороне клиента, вендора или интегратора, подумайте, как вы могли бы заявить о себе. Если у вас ещё нет канала или блога, заведите (и подсветите в avleonovchat). Делитесь в нём своими мыслями по профессиональным темам. Завязывайте дискуссии. Подайтесь с докладом на ближайшую ИБ-конференцию в вашем городе. Спросите у организаторов, будет ли там секция по VM. Предложите собрать круглый стол из знакомых VM-щиков.

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