Архив метки: FSTEC

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем

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

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем. В документе 6 страниц текстовых рекомендаций и таблица на 9 страниц, содержащая объекты контроля (параметры, роли, сервисы и учетные записи), действия, безопасные значения/результаты и наименования продуктов, требующих настройки.

Рекомендации разделены на 12 групп:

1. Управление обновлениями
2. Учётные записи и пароли по умолчанию
3. Неиспользуемая функциональность и сервисы
4. Открытые интерфейсы и администрирование
5. Параметры профиля и конфигурации безопасности
6. Шифрование и защита каналов связи
7. Контроль доступа и разделение полномочий
8. Доверенные соединения и RFC
9. Логирование и аудит
✳️ 10. Безопасность данных
✳️ 11. Управление доступом и безопасной разработки
✳️ 12. Использование отладчика

Последние 3 группы ✳️ не отражены в таблице, только в тексте документа.

Документ интересный и, на фоне медленного импортозамещения ERP-систем, более чем актуальный. 👍

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

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

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

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

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

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

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

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

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

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

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

Завершая тему компрометации 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-вендор пренебрегает своими обязанностями по описанию и устранению уязвимостей. Желательно, чтобы это влияло на присутствие ОС в реестре и наличие у неё сертификата. 😉

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

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

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

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

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

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

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

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

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