Архив рубрики: ФСТЭК

Централизация репортинга уязвимостей

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

Централизация репортинга уязвимостей

Централизация репортинга уязвимостей. Раз уж последний пост на эту тему набрал много реакции (хоть и отрицательных 😅) и даже породил дискуссию, я расписал как бы мог работать гипотетический государственный регулятор "Инициатива Нулевого Дня" ("ИНД"; отсылка к ZDI 🙂), контролирующий репортинг уязвимостей в продуктах вендоров из недружественных стран.

Исследователь, обнаруживший уязвимость в продукте вендора из недружественной страны, передаёт результаты ресёрча в ИНД. Эксперты ИНД проводят анализ и выносят решение:

🔹 Если уязвимость представляет интерес с точки зрения национальной безопасности, исследователь подписывает соглашение о неразглашении и ему выплачивается вознаграждение от ИНД. Вендор не уведомляется. Также как NSA годами использовали EternalBlue и не сообщали MS. 😉

🔹 Если уязвимость не представляет интереса, ИНД либо сообщает о ней вендору, либо даёт разрешение исследователю сообщить вендору самостоятельно. Уязвимость заводится в БДУ.

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

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

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать. Моё мнение относительно правильного детектирования уязвимостей в Linux-дистрибах. 🙂

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

🔹 Если VM-вендор в ходе проверок обнаруживает, что в бюллетенях Linux-вендора описаны не все уязвимости, он должен ему об этом сообщить. ✉️ Если реакции нет, VM-вендор должен реализовать правила детектирования по своей логике. В том числе, "опускаясь до базового дистриба".

🔹 При отсутствии реакции VM-вендор должен сообщить регуляторам (ФСТЭК и Минцифры?) о том, что Linux-вендор пренебрегает своими обязанностями по описанию и устранению уязвимостей. Желательно, чтобы это влияло на присутствие ОС в реестре и наличие у неё сертификата. 😉

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

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

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117. Приказ устанавливает требования о защите информации, содержащейся в ГИС, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений. Приказ опубликован 17.06.2025, вступает в силу с 01.03.2026. Он заменяет приказ ФСТЭК №17.

Требования к Управлению Уязвимостями раскрыты в пункте 38. Они устанавливают:

🔹 Общую структуру процесса: выявление, оценка, приоритизация, контроль устранения.

🔹 Сроки устранения уязвимостей критического и высокого уровня или исключение возможности их эксплуатации компенсирующими мерами. 24 часа и 7 дней соответственно. Для остальных уязвимостей сроки определяются внутренним регламентом.

🔹 Необходимость сообщать о выявлении уязвимостей, отсутствующих в БДУ ФСТЭК, в течение 5 рабочих дней.

Как видим, требования более чем облегчённые. Особенно если сравнивать с ранними драфтами. 😉

Может ли ФСТЭК БДУ заменить NIST NVD (и MITRE CVE Program)?

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

Может ли ФСТЭК БДУ заменить NIST NVD (и MITRE CVE Program)?

Может ли ФСТЭК БДУ заменить NIST NVD (и MITRE CVE Program)? Ок, импортозамещение - это задача стратегическая. А что в краткосрочной перспективе? Если все-таки американские базы уязвимостей перестанут работать, отечественная БДУ ФСТЭК нас спасёт? 🙂

В прошлом году на PHDays проходила дискуссия по поводу национальных баз уязвимостей. И я тогда на правах модератора спрашивал (02:30, 08:04) у Виталия Сергеевича Лютикова, на тот момент заместителя директора ФСТЭК, позиционируется ли БДУ как потенциальная замена NIST NVD. Ответ был отрицательным. БДУ собирает уязвимости в продуктах, которые могут использоваться в российском госсекторе, на объектах КИИ и в отечественном ПО. Задача собирать ВСЕ уязвимости (как в NVD) никогда не ставилась. Поэтому, если вы ищете полноценную российскую замену NVD, то это не БДУ. Во всяком случае в текущем понимании её целей и задач.

Более реалистичной заменой NVD будут являться отечественные Vulnerability Intelligence порталы и платформы. 😉

Методические рекомендации ЦБ по управлению уязвимостями и пентестам

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

Методические рекомендации ЦБ по управлению уязвимостями и пентестам

Методические рекомендации ЦБ по управлению уязвимостями и пентестам. 21 января был утверждён документ "Методические рекомендации Банка России по проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка".

Документ на 21 страницу. Он содержит общие положения и рекомендации:

🔹 по проведению пентестов
🔹 по проведению анализа уязвимостей
🔹 по самостоятельному проведению этих работ и с привлечением сторонней организации
🔹 по информированию ЦБ о результатах работ (с формой отчёта)

В части Управления Уязвимостями наиболее важными видятся рекомендации:

🔻 3.7. проводить работы по анализу и устранению уязвимостей по руководству ФСТЭК по организации VM-процесса от 17.05.2023 ‼️
🔻 3.4. оценивать критичность уязвимостей по методике ФСТЭК от 28.10.2022 ❗
🔻 использовать сертифицированные ФСТЭК средства детектирования уязвимостей инфраструктуры 3.3. и исходного кода 3.5.

Отечественная инициатива по поиску уязвимостей в СПО для виртуализации

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

Отечественная инициатива по поиску уязвимостей в СПО для виртуализации

Отечественная инициатива по поиску уязвимостей в СПО для виртуализации. Тестирование проводили специалисты компании "Базис", ИСП РАН и испытательной лаборатории "Фобос-НТ" на стенде Центра исследований безопасности системного ПО, созданного ФСТЭК России на базе ИСП РАН. Студенты МГТУ им. Баумана и ЧГУ помогали с разметкой данных и настройкой целей для фаззинга.

Проверяли nginx, ActiveMQ Artemis, Apache Directory, libvirt-exporter, QEMU. Особое внимание уделяли libvirt.

Всего выявили 191 дефект:

🔹 178 нашли SAST-ом (больше всего в ActiveMQ Artemis и Apache Directory)

🔹 13 нашли фазингом (в Apache Directory LDAP API и libvirt)

Исправления интегрировали в основные ветки проектов.

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

Выложил свой перемонтированный доклад с PHDays 2 "Кризис NVD и светлое БуДУщее"

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

Выложил свой перемонтированный доклад с PHDays 2 "Кризис NVD и светлое БуДУщее". Снимали на PHDays в этот раз по-богатому. На несколько камер. Даже летающая камера на кране была. А профессиональная команда в реальном времени сводила это всё в очень красивую картинку. Казалось бы, всё круто. Но при этом переключений на слайды почему-то не было вообще. 🤷‍♂️ Ни разу. Только съёмки экрана за моей спиной на общих планах. 🤦‍♂️ Формат съёмки был явно не для технических докладов.

Я выкачал видяшку, чуть подрезал, добавил слайды поверху и стало гораздо смотрибельнее. ✂️👨‍🎨

🎞 Выложил на VK Видео, Rutube и YouTube.

Удивительно, но с мая месяца доклад не сильно устарел. Кризис NVD не спешит заканчиваться, а команда NIST-а продолжает выкладывать странные послания и демонстрировать свою беспомощность. 🧐

Содержание:

00:00 Приветствие и кто я вообще такой
00:35 О чём будем говорить?
01:02 Как связаны базы NIST NVD и MITRE CVE, почему они растут с ускорением и при этом неполны?
06:44 Как ретроспективно развивался кризис NVD 2024 года?
08:12 В чём важность контента в NVD?
10:42 Чем объясняли кризис NVD в NIST?
12:38 Как реагировало сообщество безопасников на кризис в NVD и чем отвечали на это в NIST?
16:10 Какие меры предлагались сообществом и CISA для уменьшения зависимости от NVD?
18:00 NVD и БДУ ФСТЭК: возможно ли для российских организаций использовать только БДУ?
19:11 Уязвимости, которые присутствуют только в БДУ ФСТЭК: общее количество, распределение по годам, типы уязвимостей, уязвимые продукты; также про использование Vulristics для анализа уязвимостей БДУ
27:32 Выводы
31:11 Вопрос про статусы CVE уязвимостей DISPUTED и REJECTED
32:14 Вопрос про VM продукт для частного использования
34:16 Вопрос про достоверность оценки угроз от ФСТЭК
35:48 Вопрос про проверку причин отсутствия ссылок на CVE в БДУ