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

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1
Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1. Резюме маркетологов R-Vision: "в релизе особое внимание было уделено тому, что важно в ежедневной работе: ускорении поиска уязвимостей, гибкой приоритизации и автоматизации рутинных процессов".

Подробности и демо, видимо, стоит ожидать на вебинаре 24 марта и на конференции R‑EVOlution 9 апреля.

В пресс-релизе R-Vision сделали акцент на следующие фичи:

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

С технической точки зрения здесь речь идёт о повторной корреляции уже собранных атрибутов активов (например, CPE, версии ПО, установленные пакеты, баннеры сервисов, результаты аутентифицированных проверок, конфигурационные артефакты) с обновлённой базой уязвимостей (в случае R-Vision речь, видимо, идёт о правилах детектирования уязвимостей на OVAL-like языке). За счёт того, что сбор актуальных данных о хосте не производится, новые уязвимости могут быть выявлены практически мгновенно, без нагрузки на сеть и хосты.

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

🧠 Графический конструктор расчёта рейтинга уязвимостей. Фича позволяет настраивать формулу приоритизации уязвимостей прямо в интерфейсе, используя атрибуты уязвимости, оборудования или групп ИТ-активов. Формула может учитывать различные типы данных (числовые, текстовые и справочники), что позволяет гибко адаптировать расчёт рейтинга под особенности конкретной ИТ-инфраструктуры.

Пример формулы для расчёта рейтинга уязвимости:

round((mean({calculation:calculate_cvss}) * (mean({calculation:calculate_k}) + mean({calculation:calculate_l}) + mean({calculation:calculate_p})) *
(mean({calculation:calculate_lat}) + mean({calculation:calculate_limp}))) * 10) / 10

Доступны преднастроенные варианты, включая основанный на Методике оценки уровня критичности уязвимостей (ФСТЭК 30.06.2025).

С технической точки зрения это реализация движка кастомного скоринга, где итоговый рейтинг вычисляется через пользовательское выражение, а UI выступает как визуальный конструктор над ним. В формуле используются атрибуты из разных источников (уязвимость, актив, контекст), а пересчёт выполняется автоматически при изменении данных. Это позволяет уйти от статичного CVSS к контекстной приоритизации уязвимости. Однако следует учитывать, что сложность таких моделей быстро растёт, их трудно валидировать и поддерживать, а итоговое качество напрямую зависит от полноты и актуальности данных об активах и уязвимостях.

⚙️ Новый механизм политик управления активами и уязвимостями. Он позволяет задавать правила, которые автоматически срабатывают при наступлении заданных условий (по событию или по расписанию). Заявляется, что политики могут изменять атрибуты любых объектов системы или выполнять нужные действия: например, создавать задачу на устранение уязвимости при ее появлении, менять статус актива при обновлении данных или автоматически переводить уязвимость в нужную категорию на основании ее параметров. Поддерживается работа со всеми полями объектов. Это позволяет реализовывать сложные пользовательские сценарии – как в части управления уязвимостями, так и при построении ресурсно-сервисных моделей активов.

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

📂 Сканирование групп IT‑активов. Теперь группы IT‑активов можно использовать в задачи сканирования (как в списке целей, так и в исключениях). Состав таких групп может автоматически изменяться, что позволяет использовать одну задачу для актуальных групп активов и упрощает организацию процесса сканирования. Пример групп активов со скриншота: "Критичные устройства", "Критический ГИТ". Сканирование выполняется по IP или FQDN хоста.

Ценность - снижение операционных затрат и уменьшение ошибок. Ограничения - зависимость от корректности группировки: при ошибках в логике формирования групп возможны пропуски или избыточное сканирование, а также меньшая предсказуемость состава целей в конкретный момент времени.

📊 Улучшение информативности карточки задачи сканирования. Туда добавили статистику выполнения, отображение прогресса и ошибок подключения или сбора данных, что упрощает диагностику и контроль хода сканирования.

На последнем скриншоте можем видеть историю запусков. Для запуска показывается статус (завершён/отменён), статистику выполнения сканирования по целям, четырёхсегментный индикатор для статуса сканирования каждого таргета. Довольно симпатично. 🙂

⏱️ Настройка работы агентного сканирования. Появилось настраиваемое расписание, позволяющее задавать периодичность и время сбора данных.

Это должно помогать оптимизировать нагрузку на сеть и хосты. Интересно, как обрабатываются ситуации, когда синхронизация агента с сервером по каким-то причинам невозможна. Агент будет ждать следующего запуска по расписанию или выполнит синхронизацию ASAP?

📊 Улучшение информативности интерфейса. Добавлены полноэкранные карточки оборудования и уязвимостей, расширен набор отображаемых параметров, поддерживается перевод полей уязвимостей на русский язык, улучшены фильтры и представление данных.

В целом, по описанию все фичи выглядят интересно. Ждём демо. 🙂

На сайте ФСТЭК 12 марта вышло информационное сообщение с разъяснениями по 117 приказу

На сайте ФСТЭК 12 марта вышло информационное сообщение с разъяснениями по 117 приказу

На сайте ФСТЭК 12 марта вышло информационное сообщение с разъяснениями по 117 приказу. Прочитал и сделал выжимку:

📅 Новые требования к защите информации (ЗИ) в ГИС и иных системах госорганов, ГУПов и учреждений (приказ ФСТЭК России №117 от 11.04.2025) действуют с 1 марта 2026 года.

🛡 Требования определяют процессы и меры ЗИ для организаций, систем и инфраструктуры.

📑 В первую очередь необходимо утвердить политику, внутренние стандарты и регламенты по ЗИ.

🖥 Новые системы после 1.03.2026 создаются по новым требованиям; до утверждения новых "Мер и мероприятий" - по "Меры защиты информации в ГИС" (ФСТЭК, 11.02.2014).

🔧 Действующие системы приводятся к новым требованиям; после модернизации проводятся доп. аттестационные испытания (приказ №77) и переоформление аттестата соответствия новым требованиям.

📜 Договоры до 1.03.2026 выполняются по прежним требованиям (приказ №17).

💡 Рекомендуется разработать план поэтапного перехода с мероприятиями и сроками.

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем. Документ на 6 страниц, содержит требования, оформленные в 8 групп (символом ✳️ я отметил то, что непосредственно относится к Управлению Уязвимостями):

1. Администрирование, управление конфигурацией и эксплуатацией сетевых устройств: 1.1 администрировать пограничные устройства с изолированных рабочих мест; 1.2 использовать сертификаты или сложные пароли; 1.3 применять уникальные пароли; 1.4 контролировать и журналировать изменения конфигурации; ✳️ 1.5 выявлять и блокировать нелегитимные внешние сервисы; ✳️ 1.6 вести учёт устройств на сетевом периметре; ✳️ 1.7 управлять устройствами с истекающей поддержкой; 1.8 запретить внешнее удалённое администрирование; 1.9 согласовывать изменения с ИБ; 1.10 использовать безопасные протоколы мониторинга.

2. Повышение устойчивости к DDoS-атакам: 2.1 настроить блокировку неразрешённого трафика; 2.2 фильтровать трафик через WAF; 2.3 включить защиту от DDoS; 2.4 ограничивать подключения с одного IP; 2.5 взаимодействовать с оператором связи для противодействия DDoS.

3. Сегментация сети и контроль доступа для защиты ключевых сегментов: 3.1 сегментировать сеть VLAN и локальными сетями; 3.2 контролировать трафик через ACL; 3.3 внедрить ZTNA; 3.4 запретить удалённое администрирование ядра сети; 3.5 создать DMZ с ограниченным доступом к внутренним сегментам.

4. Резервное копирование конфигов: 4.1 назначить ответственного за резервное копирование; 4.2 хранить ≥3 копий на разных носителях, одну отдельно; 4.3 копировать ежемесячно; 4.4 определить права на копирование; 4.5 сохранять критичные конфигурации (ACL, VLAN, NAT, учетные записи); 4.6 проверять восстановление каждые три месяца.

✳️ 5. Управление уязвимостями: 5.1 реализовать управление уязвимостями по Методике анализа защищенности (ФСТЭК 25.11.2025) и Руководству по управлению уязвимостями (ФСТЭК 17.05.2023); 5.2 устанавливать обновления безопасности на пограничных устройствах и тестировать их по Методике тестирования обновлений безопасности (ФСТЭК 28.10.2022) и Методике оценки критичности уязвимостей (ФСТЭК 30.06.2025).

6. Аутентификация и управление доступом: 6.1 централизованный контроль доступа через NAC и межсетевые экраны; 6.2 многофакторная аутентификация для админ-доступа; 6.3 разграничение ролей с минимальными привилегиями.

7. Регистрация и анализ событий ИБ: 7.1 централизованный сбор и анализ событий через SIEM; 7.2 хранение детальных журналов безопасности с временными метками; 7.3 оповещение администраторов о подозрительных действиях и изменениях.

8. Регулярные учения по реагированию на инциденты для проверки их эффективности и восстановления инфраструктуры.

Интересный и подробный документ. 👍 По VM-ной части весьма примечательно, что VM-процесс для периметра рекомендуют строить в соответствии с

🔹 Руководством по Анализу защищённости. Имеются в виду периодические внешние аудиты периметра сторонней организацией с соответствующими критериями успешности? 🤔

🔹 Руководством по организации процесса управления уязвимостями в органе/организации. Был весьма удивлён, т.к. давненько не встречал прямую ссылку на него в документах ФСТЭК. 😲 Всё больше общие требования к VM-процессу, как в 117 приказе или проекте "Мероприятий и мер". 🤷‍♂️

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ "ГНИИИ ПТЗИ ФСТЭК России", в рамках своего доклада "Ландшафт актуальных угроз безопасности информации и тенденции их развития" на ТБ Форум

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ Форум

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ "ГНИИИ ПТЗИ ФСТЭК России", в рамках своего доклада "Ландшафт актуальных угроз безопасности информации и тенденции их развития" на ТБ Форум. Очень красиво. 👍

🔹 Можно видеть основные "скопления": Аппаратное обеспечение, Windows, Linux/Unix, Прикладное ПО, Beб, Библиотеки (где-то в середине, не подписано).

🔹 Подсвечены кластеры по вендорам и типам уязвимостей. Правда, если присматриваться, есть вопросики. Почему, например, Chrome в Linux/Unix, а не в Прикладном ПО? Или стоит ли выделять COVID19 в отдельный кластер? 🙂

🔹 Показаны уязвимости БДУ ФСТЭК, уязвимости без CVE, непроанализированные уязвимости, уязвимости с эксплоитами и признаками эксплуатации. Были ещё картинки по CWE-шкам, но я не стал их все выкладывать.

Идея для визуализации крутая. 🔥 Если трендовые уязвимости PT на такой карте показывать, около половины окажутся в кластере Windows. 😉

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware. Документ на 13 страниц содержит 19 рекомендаций различного объёма и детализации:

1. Настройка журналов событий
2. Переадресация журналов событий на удалённый сервер
3. Передача журналов в SIEM (таблица "Перечень журналов событий")
4. Оповещение администраторов безопасности посредством SIEM о наступлении событий (список 9 событий)
5. Резервное копирование
6. Многофакторная аутентификация
7. Отключение доступа по SSH
8. Харденинг доступа по SSH (если п.7 невозможен)
9. Ограничение VMware Network API
10. Блокировка VMware Installation Bundles
11. Ограничение HTTPS, клиента vSphere и vMotion
12. Регулярные обновления ПО (с тестированием)
13. Минимизация привилегий
14. Регулярная смена паролей
15. Безопасный режим ESXi
16. Флаг execInstalledOnly
17. Политики безопасности Portgroup
18. Сетевая сегментация
19. Сетевой доступ по чёрным и белым спискам

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux. Документ на 18 страниц содержит 12 групп рекомендаций:

1. Парольные политики Windows и Linux
2. Доступ и логирование событий в MySQL/MariaDB, PostgreSQL, MS SQL Server
3. Отключение SMBv1 в Windows
4. Отключение NTLMv1 в Windows
5. Удаление учётной записи "Гость" из групп "Администраторы" в Windows
6. Хранение учётных данных и ограничение доступа к конфигурационным файлам Windows и Linux
7. Аудит и блокирование неиспользуемых открытых портов
8. Отключение автовхода пользователя в Windows
9. Безопасная настройка SSH в Linux
10. Назначение прав доступа на файлы и директории в Windows и Linux
11. Отключение неиспользуемых служб и компонентов операционной системы в Windows и Linux
12. Отключение неиспользуемых учётных записей и ограничение записей с избыточными правами в Windows и Linux

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

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

Вчера ФСТЭК выложили в открытый доступ проект документа "Мероприятия и меры по защите информации, содержащейся в информационных системах". ФСТЭК предлагает "специалистам в области защиты информации заинтересованных государственных органов власти и организаций" рассмотреть документ и направить предложения по установленной форме на otd22@fstec.ru до 19 февраля.

❗️ Согласно пункту 1.3, "методический документ детализирует мероприятия (процессы)" по защите информации (ЗИ) и "определяет содержание мер" по ЗИ в соответствии с требованиями из 117-го приказа ФСТЭК.

Документ объёмный, 185 страниц.

Структура документа:

1️⃣ Общие положения
2️⃣ Факторы, влияющие на ЗИ
3️⃣ Мероприятия по ЗИ (45 страниц) -❗️ Среди них 3.3. Управление Уязвимостями (рассмотрю содержание подробно в последующих постах)
4️⃣ Меры по ЗИ (129 страниц)

Слово "уязвимость" в различных формах встречается по тексту 104 раза в разных частях документа. 🕵️‍♂️ Будет что пообсуждать. 😉😇