Апрельский Linux Patch Wednesday

Апрельский Linux Patch Wednesday

Апрельский Linux Patch Wednesday. В апреле Linux вендоры начали устранять 1035 уязвимостей, почти в 2 раза больше, чем в марте. Можно было бы предположить, что это опять в основном уязвимости Linux Kernel, но нет! Уязвимостей в Linux Kernel было относительно немного - 209. Остальные уязвимости распределены среди 200+ уязвимых продуктов. Есть две уязвимости с признаками эксплуатации вживую:

🔻 RCE - Apache ActiveMQ (CVE-2026-34197). Выполнение удалённого кода осуществляется через Jolokia API (/api/jolokia/), при этом аутентификация не требуется. Уязвимость оставалась скрытой в кодовой базе в течение 13 лет до её обнаружения с помощью ИИ. Уязвимость в CISA KEV с 16 апреля. На GitHub доступно множество эксплоитов.

🔻 RCE - Chromium (CVE-2026-5281). Use-after-free в Dawn (графический слой и реализация WebGPU в Chromium) в Google Chrome до версии 146.0.7680.178 позволяет удалённому атакующему, получившему контроль над процессом рендеринга, выполнить произвольный код через специально сформированную HTML-страницу. Уязвимость в CISA KEV с 1 апреля.

Ещё для 133 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Наиболее интересные, на мой взгляд:

🔸 RCE - Cockpit (CVE-2026-4631). Cockpit - это веб-инструмент для администрирования серверов в Linux-системах, который позволяет пользователям управлять серверами, контейнерами, хранилищем и сетевыми конфигурациями через браузерный интерфейс. Атакующий с сетевым доступом к веб-сервису Cockpit может отправить один HTTP-запрос на страницу входа, который позволяет внедрить вредоносные SSH-опции или команды и выполнить код на сервере Cockpit без валидных учётных данных.

🔸 RCE - CUPS (CVE-2026-34990 + CVE-2026-34980). CUPS (Common UNIX Printing System) - это система печати для Unix-подобных операционных систем, включая Linux и macOS. Цепочка уязвимостей может позволить удалённому атакующему без аутентификации и привилегий перезаписывать файлы с правами root (по сути, получать root-доступ на типичной Linux-системе) по сети.

🔸 RCE - KVM Tool (CVE-2021-45464). KVM Tool - это легковесный инструмент для запуска виртуальных машин на базе KVM (Kernel-based Virtual Machine) в Linux. kvmtool до коммита 39181fc содержит уязвимость out-of-bounds write, которая позволяет пользователю гостевой операционной системы выполнять произвольный код на хост-машине.

🔸 PathTrav - tar (npm) (CVE-2026-31802, CVE-2026-24842). До версии 7.5.11 пакет позволял создать символическую ссылку, указывающую за пределы каталога распаковки, что вело к перезаписи файлов.

Из остальных можно обратить внимание на:

🔸 RCE - Handlebars (CVE-2026-33937), tiemu (CVE-2017-20225), Netwide Assembler (CVE-2026-6067), openexr (CVE-2026-34545), Axios (CVE-2026-40175), hdf5 (CVE-2026-29043)
🔸 CodeInj - GLPI (CVE-2025-66417), glances (CVE-2026-30930, CVE-2026-32611), Handlebars (CVE-2026-33938, CVE-2026-33940), dynaconf (CVE-2026-33154), icalendar (CVE-2026-33635)
🔸 SFB - ormar (CVE-2026-27953), cpp-httplib (CVE-2026-34441), Safari (CVE-2026-20643), rack (CVE-2026-34835), wolfssl (CVE-2026-5194), Traefik (CVE-2026-32695), glances (CVE-2026-32632, CVE-2026-32634), Vert.x-Web (CVE-2026-1002), ecdsa (CVE-2026-33936), glibc (CVE-2026-4438), incus (CVE-2026-33542), Mongoose (CVE-2026-2968)
🔸 AuthBypass - scitokens_cpp_library (CVE-2026-32725, CVE-2026-32726), Node.js pbkdf2 (CVE-2026-32633), rack-session (CVE-2026-39324), Traefik (CVE-2026-33433), grpc (CVE-2026-33186), nltk (CVE-2026-33231)
🔸 ArbFileWrite - Rust (CVE-2026-33056)
🔸 CmdInj - Netty (CVE-2026-33870), awstats (CVE-2025-63261)
🔸 EoP - Keycloak (CVE-2026-4636), QEMU (CVE-2026-33711), glances (CVE-2026-33641)

🗒 Полный отчёт Vulristics

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства. При этом зачастую его апологеты пропагандируют вещи откровенно вредные. Что уметь программировать больше не нужно. Разбираться во фреймворках и библиотеках - тем более не нужно. Достаточно просто поставить задачу, даже в самом общем виде, волшебному кодогенератору да докинуть токенов облачного AI-сервиса. А дальше ОНО ВСЁ ДЕЛАЕТ САМО! 🪄 И через несколько часов получаешь нужный результат.

А главное, что это не обман. Таким образом действительно можно получить программное решение, которое РАБОТАЕТ (пусть и не с первой итерации). Правда, фиг его знает, как оно написано и какие там могут быть сюрпризы - но кого ж это волнует, правда? 😏

В результате:

🔹 В ширнармассах возникает весьма понятное ощущение - вот оно! 🤑 Теперь для того, чтобы слепить стартап, больше не нужны технари! Волшебная машинка, накормленная токенами, выдаст приложульку сама. А фаундер может целиком посвятить себя окучиванию инвесторов и получению прочих бенефитов.

🔹 Да и состоявшиеся корпорации тоже не прочь по возможности сэкономить на разработчиках. 😇

К чему это приведёт в обозримом будущем? К тому, что разработкой (генерацией) кода начнёт заниматься огромное количество новых игроков, абсолютно незрелых и безответственных. Без какого-либо понимания о процессе безопасной разработки, правильной архитектуре, способах определения уязвимостей в собственном (лол 😅) коде и зависимостях (зачастую в такой же безответственной генерёнке 🤷‍♂️), нормальном выпуске обновлений с бюллетенями безопасности, CVE-шками и прочим.

И будьте покойны, эти новые игроки нагенерят ОГРОМНОЕ количество чёрти как работающего кода. Как коммерческого, так и опенсурсного. Настолько много, что все традиционные более-менее ответственные игроки потеряются на фоне массы этой новой вайбкодерной гопоты. И либо не смогут толком конкурировать с ней, либо сами деграднут до её уровня. 😏

Мы ещё будем с ностальгией вспоминать то благословенное время, когда код писали ручками, профессиональные программисты. Решение проблем с ПО, с которыми мы сталкивались раньше, было сродни плесканию на мелководье. А сейчас на нас надвигается цунами и что с этим делать, не особенно понятно.

Коллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VM

Коллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VMКоллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VM

Коллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VM. Я отсмотрел это видео и выписал основные моменты.

Позиционирование решения: RedCheck VM - это простая и готовая к использованию система управления уязвимостями, которая снижает сложность внедрения и настройки и позволяет сосредоточиться на закрытии уязвимостей, а не на работе с инструментом.

Анонс фич, которые следует ждать до конца года:

📊 Оценка уязвимостей по методике ФСТЭК (в релизной версии)
🔧 Анализ и контроль несоответствий конфигураций
📦 Расширенная инвентаризационная информация по хостам

Ещё будущие фичи без сроков:

🛡️ Обогащение инвентаризации аудитами в режиме Pentest
🔗 Интеграция с таск-трекерами (помимо почты)

Что по сертификату? Полнофункциональный модуль RedCheck VM планируется включить в действующий сертификат RedCheck в следующем году.

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

Демо бета-версии продукта

Интерфейс. Стандартный веб-интерфейс. Светлая/тёмная тема.

Дашборды. На данный момент есть девять стартовых выборок: Хосты, Хосты на периметре, Уязвимости, Уязвимости на периметре, Уровни критичности по статусам, Хосты по сетевым зонам, Просроченные уязвимости по ответственным, Актуальность сканирования, Динамика хостов. Новые информеры будут добавляться с обновлениями, и в дальнейшем можно будет их переключать, сохраняя фокус внимания на важном.

Интеграция со сканерами RedCheck. Настройка начинается с указания адреса, порта Rest API и учетных данных сканера RedCheck. Все полученные данные агрегируются в выбранной сетевой зоне, при этом интерфейс позволяет создавать новые объекты напрямую из меню. Ключевым этапом является настройка расписания синхронизации в формате cron (секунды, минуты, часы, дни, месяцы, дни недели). По умолчанию в бета-версии установлен ежечасный опрос, однако его можно изменить (например, на ежедневный запуск в 23:00). Стоит учитывать, что экземпляр RedCheck сохраняет собственный регламент работы и может параллельно использоваться другими сотрудниками для внутренних задач. Отдельно управлять учётными записями можно в соответствующем списке.

Справочники. Позволяют редактировать различные сущности. В настоящее время доступны справочники: Теги хостов, Теги уязвимостей, Сетевые зоны, Ответственные, Почтовые адреса.

Хосты. После синхронизации со сканерами RedCheck данные о хостах импортируются в RedCheck VM. Каждому объекту присваиваются соответствующие параметры: сетевые зоны, ответственные лица и теги. В карточке хоста отображаются результаты инвентаризации и перечень выявленных уязвимостей. В таблице уязвимостей видны колонки: ALTXID, Уязвимость, Эксплойт (наличие эксплойта - пиктограмма восклицательный знак; использование в атаках - пиктограмма стрелка), Тип уязвимости, Теги уязвимости, Тип устранения, Статус обработки (Не обработана, В работе IT), Ответственный.

Карточка уязвимости. Карточка уязвимости (в примере уязвимости Firefox) содержит идентификаторы CVE и сведения об эксплойте. В ней указаны уязвимые компоненты, рекомендации по обновлению для различных ОС и меры по смягчению последствий (mitigation), если оперативное исправление невозможно.

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

Рабочий стол контроля устранения. Позволяет фильтровать задачи. Для фильтрации доступны следующие параметры: FQDN, IP-адрес, Дата публикации, Теги хоста, ALTXID, Уязвимость, Критичность, Тип уязвимости, Теги уязвимости, Статус, Тип устранения, Статус SLA, Ответственный ИТ. Так, Статус может быть в значении: В работе ИТ, Требует проверки, Просрочена, Устранена, Принят риск.

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

Анализ уязвимостей. Это перечень всех уязвимостей в базе RedCheck VM, в том числе, с распределением обнаружения на хостах в системе. Здесь отдельно можно поработать с уязвимостями по необходимым фильтрам, например, по дате обнаружения в инфраструктуре или дате публикации уязвимости. "Например, пятнадцатого января и с информацией об эксплоите".

Сходили вчера в Третьяковскую галерею на детскую экскурсию по выставке "Арктика. Полюс цвета"

Сходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цветаСходили вчера в Третьяковскую галерею на детскую экскурсию по выставке Арктика. Полюс цвета

Сходили вчера в Третьяковскую галерею на детскую экскурсию по выставке "Арктика. Полюс цвета". Попали аккурат в последний день. Выставка проходила в новом корпусе на Кадашёвской набережной, открывшемся осенью 2024 года. Очень красивое современное здание. Внутри просторно, много естественного света (даже в пасмурный день), доминирующий белый цвет в сочетании с красным кирпичом. Люблю такое. 😇👍

Выставка была посвящена тому, как менялось восприятие Арктики с XVIII века до наших дней - от романтизированных образов далёкого и загадочного Севера к более точному, документальному взгляду эпохи освоения и современным художественным интерпретациям. Через живопись, графику, скульптуру, фотографию и мультимедиа показано, как художники, исследователи и участники экспедиций по-разному осмысляли этот регион, превращая его из мифа в пространство реального опыта и культурного значения. На выставке были представлены произведения художников, скульпторов и фотографов конца XIX - начала XXI века, многие из которых лично бывали в Арктике и вдохновлялись её природой и атмосферой. Среди авторов — Александр Борисов, Константин Коровин, Фёдор Решетников, Фёдор Конюхов и другие. Наибольшее впечатление на меня произвела работа Климента Редько "Полуночное солнце" (1925).

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

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

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

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что у них лапки, и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее

Ну раз КУ, значит КУ (3 раза)

Ну раз КУ, значит КУ (3 раза)

Ну раз КУ, значит КУ (3 раза!). Извините, не удержался. 😅

"Владимир Николаевич, у тебя на периметре дыра, админ - бездельник, AD-шка не пропатчена, а ты тут мозги пудришь. Плохо кончится, родной…"

"- Ну вот у вас в организации, как вы определяете - кто уязвимости фиксить должен и в какой срок?
- Ну, это на глаз…
- Дикари!"

"- У меня такое предложение, родной. Ты нам сервак сейчас запатчишь, а мы тебе потом VM-ный мерч привезём, идёт?"

"- Стой! Стой, я говорю! Ты кто? Я спрашиваю: ты кто?
- Lead DevOps Engineer.
- Нет. Ты ITшник. А ты кто?
- Я ведущий разработчик.
- Не-ет, ты тоже ITшник. Ты ITшник, ты ITшник и он ITшник. А я VM-щик, и они VM-щики! Так что ты репорт открой и уязвимости фикси, ясно?"

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах"

На сайте ФСТЭК 12 апреля выложили методический документ Мероприятия и меры по защите информации, содержащейся в информационных системах

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах". Проект этого документа выкладывали в феврале.

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

🔹 в ИС, АСУ и сетях госорганов, ГУП, госучреждений и организаций, включая субъектов КИИ
🔹 в Тех. средствах, ПО и БД, используемых для создания и эксплуатации ГИС и иных ИС госорганов, доступ к которым предоставляется по сети
🔹 в ИТ-инфраструктурах общего назначения, обеспечивающих функционирование указанных ИС, а также обеспечивающих безопасность ЗОКИИ, принадлежащей органам (организациям)

Фактически это детализация 117-го приказа ФСТЭК и замена методического документа ФСТЭК России от 11 февраля 2014 года "Меры защиты информации в государственных информационных системах".

Документ объёмный, 255 страниц (по файлу в формате ods). Я посмотрел, в каких разделах встречается слово "уязвимости" в различных формах (звёздочками условно отметил частоту упоминания):

✳️✳️✳️✳️✳️ 3.3. Управление уязвимостями (КУ)
✳️✳️✳️✳️✳️ ЗКО.8 Выявление и устранение уязвимостей в контейнерной среде
✳️✳️✳️✳️ II. ФАКТОРЫ, ВЛИЯЮЩИЕ НА СОСТОЯНИЕ ЗАЩИТЫ ИНФОРМАЦИИ, СОДЕРЖАЩЕЙСЯ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
✳️✳️✳️ 3.18. Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)
✳️✳️ 3.4. Управление обновлениями (КО)
✳️✳️ 3.12. Обеспечение разработки безопасного программного обеспечения (БР)
✳️✳️ ЗИВ.4 Контроль целостности
✳️ 3.1. Выявление и оценка угроз безопасности информации (ВУ)
✳️ 3.19. Проведение периодического контроля уровня защищенности информации, содержащейся в информационных системах (ПК)
✳️ РСБ.2 Анализ событий безопасности и реагирование на них
✳️ ЗСВ.1 Доверенная загрузка средств виртуализации и виртуальных машин
✳️ ЗКО.2 Регистрация событий безопасности в контейнерных средах
✳️ ЗБД.3 Защита пользовательских данных
✳️ ЗБД.4 Контроль целостности

Ниже привожу полную структуру документа.
Читать далее