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

Посмотрел вчера вебинар 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, посвящённый презентованному на прошлой неделе релизу 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 показали следующие кейсы (см. скриншоты):

🔻 Провели inventory-скан (показали новую карточку скана с фильтрами ошибок), определили хосты Cisco, создали и запустили простое правило для перемещения хостов в группу по типу ОС. В итоге наполнили группу "Сетевое оборудование Cisco".

🔻 Провели сканирование с аутентификацией группы "Сетевое оборудование Cisco", с помощью правила задали рейтинг и уровень критичности для продетектированных уязвимостей.

🔻 Добавили уязвимость Cisco, которой не было в базе, через обновление и определили её ретроспективным аудитом на хостах. Проговорили, что в случае детектирования трендовой уязвимости можно автоматически отправлять алерт админу. 🚨

Также они поделились достижениями, статистикой, роадмапом и ближайшими мероприятиями.

Основное достижение - это перевод R-Vision на новую платформу EVO (до версии 5.4 были на платформе RVN).

R-Vision VM в цифрах (2025-2026):

🔹 +15 новых проектов (есть заказчики с 30k+ активов)
🔹 +50 пилотных проектов у клиентов
🔹 +25 пилотных проектов у партнёров
🔹 +55 обученных технических специалистов
🔹 +133 трендовые уязвимости в базе (дайджесты доступны на сайте R-Vision)
🔹 +180 поддерживаемых продуктов в режиме Audit
🔹 +88 поддерживаемых продуктов в режиме Pentest
🔹 +70 новых стандартов для режима Compliance

Роадмап ("R-Vision VM завтра"):

🔹 Поддержка аудита контейнерных сред
🔹 Поддержка аудита веб-приложений
🔹 Расширение аудита гипервизоров (ESXi, vCenter, …)
🔹 Расширение аудита сетевого оборудования (Qtech, S-Terra, Eltex, VipNET, UserGate, MikroTik, …)
🔹 Мастер первичной настройки
🔹 Сертификат ФСТЭК России (на VM EVO)
🔹 + Секретная функциональность ❗️ (анонс на R-Evolution Conference 2026)

Сам я на R-Evolution Conference, к сожалению, в этом году не попадаю. 😔 Но рекомендую сходить, был там несколько раз, мероприятие душевное.

На R-Evolution Conference будет несколько VM-ных докладов:

🔹 12:55 - 13:15 Смена двигателя на лету: год большой перестройки VM и куда дальше? (Бизнес-трек)
🔹 14:00 - 14:20 Опыт ТМХ: как выстроить управляемый VM на десятках тысяч активов (Бизнес-трек)
🔹 15:20 - 15:40 Где ломается VM: подводные камни инвентаризации в инфраструктуре на 18К+ активов, ЗАО ПАТИО (Технотрек - новинка, в прошлом году технотрека не было 👍)

Плюс обещают демозону с R-Vision VM, работающую весь день. 🔥

В Q&A секции понравились вопросы:

🔹 Какая функциональность будет востребована в системах VM в ближайшие 2-3 года?
"Управление экспозициями" (прямо так и сказали, было приятно услышать именно такую формулировку 😇), пути атаки, ИИ, возможность переваривать большую инфраструктуру, автоматизация.

🔹 Можно ли сейчас использовать решения R-Vision для построения путей атаки?
Сказали, что тема хорошая, но задача сложная, особенно для большой инфраструктуры. Пока они не говорят, что могут это делать, но тренд им нравится.

🔹 Сколько человек, занимающихся VM-ом, требуется для организации с 10k активов?
Ответили, что 10000 активов → минимум 10 человек в IT, минимум 5-7 человек в ИБ. В ИБ люди будут шарить роли. Как минимум нужен один человек, который будет часть времени выделять на VM-ные задачи. Автоматизировать всё можно, но кто-то должен отслеживать сбои.

На прошлой неделе, 16 марта, прошло весьма интересное VM-ное мероприятие

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

На прошлой неделе, 16 марта, прошло весьма интересное VM-ное мероприятие

На прошлой неделе, 16 марта, прошло весьма интересное VM-ное мероприятие - заседание совета по развитию цифровой экономики при Совете Федерации (секция по обеспечению технологического суверенитета и ИБ РФ) по теме "О мерах по снижению количества уязвимостей в публично доступной ИТ-инфраструктуре и отечественном программном обеспечении, также о повышении защищенности КИИ". На ВК Видео доступна двухчасовая запись. Задачей заседания было сформировать единую позицию по трём направлениям работы с уязвимостями, собрать единый протокол, чтобы дальше направить письма в органы и заниматься либо нормативным регулированием, либо оказывать помощь в устранении уязвимостей "в узких местах".

Первый доклад был от начальника отдела по надзору за исполнением законов в сфере информационных технологий и защиты информации Генеральной прокуратуры Олега Кипкаева. Приведу его содержание.

Олег Вячеславович сообщил, что в Рунете функционируют ~70 млн. сервисов, более половины исследованных хостов содержат нарушения базовых требований информационной безопасности. "Практика показывает, что в основе многих инцидентов лежат не какие-то исключительные обстоятельства, а несвоевременное обновление программного обеспечения, использование уязвимых версий сервисов, слабая парольная политика, открытый доступ к административным интерфейсам, отсутствие необходимых средств защиты, иные известные недостатки в настройке и эксплуатации информационных систем". Уязвимость внешнего цифрового периметра не проблема конкретной организации, а вопрос общей устойчивости цифрового пространства. Количество кибер-атак на отечественные организации продолжает расти, их цель нанесение существенного вреда. Необходимы упреждающие действия со стороны государства, регуляторов, правоохранительных органов и владельцев информационных систем. Правовая основа для работы создана: законодательство о безопасности КИИ, решение президента РФ, обязательные требования в сфере защиты информации, функционируют механизмы выявления/предупреждения/ликвидации последствий компьютерных атак. Но есть проблемы:

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

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

🔻 Сохраняется разрыв между установленными требованиями и фактическим уровнем защищённости. "Результаты обследования ЗоКИИ свидетельствуют о многочисленных нарушениях обязательных требований в сфере защиты информации". Во многих организациях минимально необходимый уровень защищённости до настоящего момента не обеспечен.

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

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

🔹 Необходимо повысить уровень контроля за исполнением обязательных требований в сфере защиты информации, в первую очередь субъектов КИИ, органов публичной власти, системообразующих организаций и иных владельцев значимых информационных ресурсов.

🔹 Требует дальнейшего развития практика регулярного внешнего мониторинга публично доступных сервисов. Результаты такого мониторинга должны доводиться до уполномоченных должностных лиц. "Каждый руководитель должен иметь объективное представление о состоянии подведомственной инфраструктуры и понимать меру своей ответственности за непринятие своевременных мер".

🔹 Следует рассмотреть вопрос о совершенствовании мер ответственности за неустранение критических уязвимостей в случаях, когда такое бездействие "создаёт угрозу причинения существенного вреда государственным, общественным и частным интересам". Подход должен быть взвешенным. Если устранение уязвимости в кратчайшие сроки невозможно по объективным причинам, в т.ч. в связи с отсутствием необходимого обновления или необходимостью серьёзной технологической перестройки, должны незамедлительно приниматься компенсирующие меры защиты, позволяющие минимизировать риски.

🔹 Отдельное значение имеет координация усилий всех регуляторов, правоохранительных органов, операторов связи, владельцев информационных систем, организаций, осуществляющих мониторинг угроз, а также разработчиков отечественных решений в сфере ИБ. Сегодня необходимо добиваться не только реагирования на совершённые атаки, но и последовательно устранять условия, способствующие к их совершению.

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

❓ Уточняющий вопрос от Владимира Бенгина про то, касаются ли эти предлагаемые меры не только КИИ. Олег Кипкаев подтвердил, что всё так. "Регулирование КИИ, гос. информационных систем, информационных систем органов власти в целом урегулированы. Если говорить о бытовых информационных устройствах, которые используются гражданами в частных целях, а также юридическими лицами, это сейчас является самым уязвимым сектором в сети Интернет." Эта инфраструктура используется для DDoS атак на КИИ. Менее защищённая инфраструктура является опорной точкой для атаки на более защищённую инфраструктуру и её нельзя отсечь по GEO IP и т.д., т.к. эта угроза идёт уже изнутри РФ.

#️⃣ В целом, мои впечатления от доклада очень положительные. Эта инициатива может привести к появлению методических указаний по контролю сетевого периметра (возможно уточнению VM-ных методик ФСТЭК). Также помимо 274.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 представили на днях новую версию системы управления уязвимостями 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. Сетевой доступ по чёрным и белым спискам