Архив рубрики: Регуляторика

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет!

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

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет!

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет! Был опубликован приказ ФСБ России от 24.12.2025 № 540 «О внесении изменений в Положение о Национальном координационном центре по компьютерным инцидентам, утвержденное приказом ФСБ России от 24 июля 2018 г. № 366».

Среди прочего, он добавляет такой пункт:

"5. В целях выполнения предусмотренных настоящим Положением задачи и функций НКЦКИ в пределах своей компетенции имеет право:
…
5.9. Запрашивать для выполнения задачи и осуществления функций НКЦКИ у субъектов критической информационной инфраструктуры, центров ГосСОПКА и органов (организаций) результаты проведенных мероприятий, направленных на защиту от компьютерных атак в отношении принадлежащих им информационных ресурсов Российской Федерации, а также информацию об устранении уязвимостей информационных ресурсов Российской Федерации."

Похоже, планируют стимулировать устранение уязвимостей, и это не может не радовать. 🙂👍

В России проработают вопрос создания центра проведения сравнительного анализа средств защиты информации

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

В России проработают вопрос создания центра проведения сравнительного анализа средств защиты информации

В России проработают вопрос создания центра проведения сравнительного анализа средств защиты информации. Поручение об этом дал Михаил Мишустин по итогам форума "Цифровые решения".

🫡 Ответственные: Минцифры, Минобрнауки, ФСТЭК и ФСБ совместно с заинтересованными органами власти.

⏳ Срок: до 30 января 2026 г.

Инициатива выглядит интересно и актуально. 🔥 ИБ-вендоров в России множество, а продуктов - тем более. Насколько эти продукты адекватно решают заявленные задачи - вопрос нетривиальный. 🤯

По-хорошему тут нужно выделять классы СЗИ и для каждого класса прописывать типовые функциональные возможности и сценарии тестирования. Затем проводить тестирование вживую на стендах и делать выводы о качестве реализации функциональных возможностей в каждом конкретном решении. 🤔

Тогда можно будет выдавать достаточно объективные рекомендации:

⚖️ Организациям по выбору СЗИ
💡 ИБ-вендорам по доработке СЗИ

Было бы круто как-нибудь поучаствовать там по теме САЗ. 😇

Вчера на сайте ФСТЭК был опубликован важный VM-ный документ - "Методика анализа защищённости информационных систем" от 25 ноября 2025 г

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

Вчера на сайте ФСТЭК был опубликован важный VM-ный документ - Методика анализа защищённости информационных систем от 25 ноября 2025 г

Вчера на сайте ФСТЭК был опубликован важный VM-ный документ - "Методика анализа защищённости информационных систем" от 25 ноября 2025 г. Основное назначение методики - описать работы по анализу защищённости (выявлению уязвимостей) при аттестации объектов информатизации (77 приказ), а конкретно в ходе:

🔹 аттестации информационных систем (ИС) на соответствие требованиям по защите информации (ЗИ);
🔹 контроля уровня защищённости конфиденциальной информации от НСД и её модификации в ИС;
🔹 оценки соответствия ИС требованиям по ЗИ (испытания) и достаточности принимаемых мер по ЗИ (обеспечению безопасности).

Кроме того, это (первая? 🤔) попытка регулятора определить, что такое Анализ Защищённости (АЗ) как услуга.

Особенно интересны:

🔻 Раздел 3.4. Оценка выявленных уязвимостей. Здесь определяются критерии успешности АЗ.

🔻 Таблицы 2 и 3, содержащие перечни работ в ходе внешнего и внутреннего сканирования и, фактически, определяющие требования к функциональности средств АЗ. 😉

Завершая тему компрометации F5, стоит отметить, что подобные атаки неизбежно будут проводиться и против отечественных IT/ИБ вендоров

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

Завершая тему компрометации F5, стоит отметить, что подобные атаки неизбежно будут проводиться и против отечественных IT/ИБ вендоров

Завершая тему компрометации F5, стоит отметить, что подобные атаки неизбежно будут проводиться и против отечественных IT/ИБ вендоров. У них также могут слить незакрытые задачи на устранение уязвимостей и исходный код, что приведёт к массовой эксплуатации 0day уязвимостей. 😱 Как снизить такие риски? 🙂

Имхо, государству стоит определить вендоров, наиболее интересных злоумышленникам - прежде всего разработчиков решений, доступных из Интернет: систем удалённого доступа, CMS, CRM, e-learning, почты, мессенджеров и т.п.

Помимо повышенных требований к этим "периметровым" продуктам (отсутствие НДВ), необходимо ужесточить требования к вендорам:

🔻 Их инфраструктура должна соответствовать современным требованиям ИБ (хотя бы в объёме 117 приказа ФСТЭК).
🔻 Они обязаны отвечать за уязвимости и их сокрытие, а данные об уязвимостях должны быть доступны для изучения.
🔻 Их продукты должны быть выставлены на багбаунти.

Кто не тянет - тем не место в "импортозамещательных" реестрах. 😉

Обновлённая методика оценки критичности уязвимостей ФСТЭК от 30.06.2025

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

Обновлённая методика оценки критичности уязвимостей ФСТЭК от 30.06.2025

Обновлённая методика оценки критичности уязвимостей ФСТЭК от 30.06.2025. Документ выложили вчера. Большая новость для всех VM-щиков России. Думаю мы будем ещё долго обсуждать тонкости новой версии методики. 🙂 Но начнём с главного - кардинального снижения зависимости от CVSS! 🎉👏

🔹 Больше не требуется использовать временную и контекстную метрику CVSS. 👋 Для расчёта потребуется только CVSS Base score, который можно брать из NVD/Mitre, от вендора или ресёрчера.

🔹 Бесполезного перехода на CVSS v4 не случилось. 👍🔥 Закреплена версия CVSS 3.1. Но в случае отсутствия оценки по 3.1 допускается использовать другую версию CVSS.

Фактически реализовано то, что я предлагал в ОСОКА: фиксируем базовые метрики CVSS v3(.1), а вместо временных и контекстных метрик CVSS вводим свои простые и автоматизируемые. 😉

Новые компоненты:

🔻 Iat - наличие эксплоитов и фактов эксплуатации вживую

🔻 Iimp - "последствия эксплуатации" (= тип уязвимости)

Я очень доволен. 😇

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

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

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

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

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

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

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

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

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

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

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

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

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

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