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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры?

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры?

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры? В блоге Qualys сегодня появилась интересная новость. Они совместно с компанией Converge, специализирующейся на киберстраховании, запускают совместное решение по андеррайтингу киберрисков в реальном времени. Андеррайтинг - это процесс, в котором страховая компания оценивает риск и решает: страховать компанию или нет, сколько будет стоить полис, какие ограничения будут в страховке (например, что покрывается, а что нет). Так вот, большинство андеррайтеров по-прежнему полагаются статические анкеты самоотчётности (self-reported static questionnaires) - документы, которые долго заполняются, отличаются от организации к организации и по сути не отражают реальное состояние безопасности инфраструктуры организации. В результате страховые премии (сумма, которую компания платит за страховку, обычно раз в год) формируются на основе предположений о практиках безопасности организации.

Получается, что руководители ИБ инвестируют значительные бюджеты и усилия в снижение риска. Они внедряют управление уязвимостями. Обеспечивают управление патчами. Мониторят конечные точки. А затем при продлении полиса киберстрахования снова заполняют ту же статическую анкету, что и 12 месяцев назад, вручную, по памяти, без связи с проверенными данными, уже находящимися в их платформе безопасности. Этот разрыв в данных стоит организациям денег. Андеррайтеры, работая с неполной информацией, оценивают риск консервативно. Организации с действительно сильной программой безопасности фактически субсидируют более слабые.

Для решения проблемы Qualys сделали Converge Connect Insurance Report (CCIR), который фиксирует данные по ИБ-решениям Qualys, используемым в организации:

🔹 Enterprise TruRisk Management (ETM)
🔹 Vulnerability Management, Detection & Response (VMDR)
🔹 Возможности управления патчами TruRisk Eliminate
🔹 Endpoint Detection & Response (EDR)

Этот отчёт передаётся в Converge через назначенного брокера (Symphony Risk Solutions), дополняя традиционную анкету и снижая количество вопросов в процессе страхования. Андеррайтеры получают проверенные данные. Организации получают премию, отражающую реальный уровень киберриска.

Предложение доступно клиентам Qualys в США в большинстве отраслей с выручкой до 5 млрд долларов. Минимальное требование - активная подписка на VMDR.

Интерес Qualys в этой инициативе довольно понятный и многослойный.

1️⃣ Они усиливают ценность своих продуктов. Раньше Qualys продавал инструменты для управления уязвимостями, патчами и endpoint-ами как способ снизить киберриски. Теперь это подаётся гораздо сильнее: не просто "вы снижаете риск", а "вы потенциально снижаете стоимость киберстраховки". Для бизнеса это уже более осязаемый финансовый эффект.

2️⃣ Это стимулирует расширение использования их экосистемы. В программе участвуют только клиенты с определёнными продуктами Qualys. Чем больше модулей используется, тем полнее данные, тем качественнее отчёт для страховщика и тем выше шанс на снижение страховой премии. Это классический механизм увеличения проникновения внутри клиента.

3️⃣ Появляется эффект привязки к платформе. Если страховая начинает учитывать данные Qualys при оценке риска и расчёте цены, переход на другого вендора становится сложнее. Исторические данные, отчёты и привычный формат оценки риска оказываются завязаны на одну систему.

4️⃣ И наконец, Qualys фактически расширяет своё присутствие за пределы классического рынка кибербезопасности. Они заходят в смежную область - киберстрахование и управление финансовым риском. В перспективе это превращает их не просто в security-вендора, а в один из ключевых источников данных для оценки киберрисков на рынке.

Конкурирующие с Qualys вендоры могут делать то же самое, ведь у них тоже есть данные о состоянии безопасности, на основе которых можно строить риск-отчёты для страховых. Но ключевой вопрос не в наличии данных, а в доверии и стандартизации: страховые должны признавать эти метрики объективными и использовать их в андеррайтинге.

На сайте ФСТЭК 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 приказе или проекте "Мероприятий и мер". 🤷‍♂️

Qualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate

Qualys представили AI-powered Patch Reliability Score в составе TruRisk EliminateQualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate

Qualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate. Эта фича предназначена для оценки надёжности обновлений до их массового развертывания.

🤖 ИИ оценивает публичные сигналы о патчах (технические обсуждения, отзывы пользователей, сообщения о сбоях и другие индикаторы, появляющиеся после выхода патча) и формирует динамический Patch Reliability скор.

📊 High означает, что обновление можно внедрять быстрее и увереннее, Low - стоит провести дополнительное тестирование или отложить раскатку.

🧪 По данным компании, при проверке на наиболее часто откатываемых патчах 2025 года (таких как USN-7545-1, KB5063878, KB5065426, KB5055523, KB5066835) система заранее присваивала им низкую оценку.

Этот скор может использоваться для автоматизации Patch Management-а и митигаций.

Это в тему, что автоматическое устранение уязвимостей реализуемо, но требует тщательной проработки. 😉

Про обновление third-party приложений через платформу оркестрации Windows Update

Про обновление third-party приложений через платформу оркестрации Windows Update

Про обновление third-party приложений через платформу оркестрации Windows Update. Все мы знаем, что системные обновления Windows накатываются удобным и централизованным образом. А вот с обновлением прикладного ПО под Windows от разных вендоров - тут кто во что горазд. 🤪 Приложение могут самообновляться в фоне, могут показывать разнообразные нотификации. Могут ничего не показывать, оставляя отслеживание обновлений пользователям (или админам/VM-щикам организации). 😏

Microsoft решили поменять ситуацию, предложив разработчикам ПО инструмент, через который они могут описывать обновления своих продуктов и требования по их установке: скрипты для скачивания и установки, скрипт для завершения процессов перед установкой, необходимость перезагрузки и т.п. Такие обновления будут предлагаться пользователям к установке так же как и системные обновления Windows.

Концепция выглядит интересно. Другим вендорам ОС, в том числе отечественным, стоит присмотреться. 😉

Patch Management в Vulns.io VM

Patch Management в Vulns.io VM
Patch Management в Vulns.io VM

Patch Management в Vulns.io VM. Попалась на глаза новая раздатка. 🙂 В ней делают акцент на том, что в Vulns.io добавили не просто автопатчилку, а систему управления обновлениями, работающую в некотором процессе:

1. Сбор и отображение информации об обновлениях, исправляющих детектируемые уязвимости.

2. Загрузка обновлений в локальное хранилище с проверкой целостности. Обновления для прикладного ПО под Linux и Windows сейчас скачиваются с сайтов вендоров, но скоро будут скачиваться централизованно из облака Vulns.io. Системные обновления берутся напрямую из MS Updates/WSUS или Linux-репозиториев.

3. Проверка безопасности обновлений и ручной перевод обновления в "доверенное". Проверку нужно выполнять самостоятельно, возможно по методике ФСТЭК.

4. Создание задач на автоматическую установку "доверенных" обновлений.

Актуальный перечень систем и софтов, для которых поддерживается обновление, содержится в файле (раздел "Обновляемое программное обеспечение"). 😉

Уязвимости Шрёдингера и безусловный патчинг

Уязвимости Шрёдингера и безусловный патчинг

Уязвимости Шрёдингера и безусловный патчинг. Сегодня в канале Алексея Лукацкого вышел пост в продолжение нашей заочной дискуссии: нужно ли устанавливать все обновления безопасности выпускаемые вендором, или можно устанавливать только те, которые исправляют эксплуатабельные критичные уязвимости?

Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо ASAP, может с задержкой на недельку-другую ("patch may be delayed" как пишут в ISA/IEC TR 62443-2-3 – 4.1), но НЕ ДОЛЖНО БЫТЬ опции вообще его не ставить только потому, что исправленная уязвимость выглядит как некритичная. Каждая продетектированная уязвимость должна находиться в процессе устранения (планового или приоритетного). Во всяком случае нужно к этому стремиться. 😉

А почему я так считаю, хотя сам делаю утилиту для приоритизации уязвимостей и участвую в определении трендовых уязвимостей? Пчёлы против мёда? 🐝🍯 К сожалению, мир уязвимостей так устроен, что о большей части из них мы не знаем практически ничего, кроме небольшого абзаца текста. 🐈 Кот Шрёдингера в коробке одновременно и жив, и мёртв. А у нас уязвимость одновременно и критичная эксплуатабельная, и нет. 🤷‍♂️ До момента пока не появятся детали: write-up, эксплоит, подтверждения эксплуатации вживую.

Далеко ходить не нужно, смотрим августовский Patch Tuesday с прошлой недели:

🔻 Вот Remote Code Execution - Windows TCP/IP IPv6 (CVE-2024-38063), от которой все на ушах стоят и ждут подробностей.

🔻 А вот Security Feature Bypass - Windows Mark of the Web "Copy2Pwn" (CVE-2024-38213), которую, по данным ZDI, запатчили в июне, а сообщили о ней только в августе. Вот так и принимай решение на основе данных об уязвимостях, когда вендор о них даже не сообщает, а исправляет тихонько. 😏

Инфа по уязвимостям практически всегда неполная!
Выход из этого дурацкого подвешенного состояния один - запатчиться поскорее.

В упомянутой Алексеем Лукацким TSA Security Directive Pipeline-2021-02D в III.E.1 на 7 странице так прямо и написано, что необходимо иметь Patch Management стратегию, которая гарантирует, что все критические системы запатчены:

"A patch management strategy that ensures all critical security patches and updates on Critical Cyber Systems are current"

И только если установка патча ведёт к деградации операционных возможностей (III.E.3, стр.8), тогда нужно исправлять уязвимость workaround-ами с подробным описанием почему мы применяем такие экстраординарные формы митигации (ну и параллельно запрашивать вендора, что это за фигня с патчами, которые функциональность оплаченную портят):

"If the Owner/Operator cannot apply patches and updates on specific Operational Technology systems without causing a severe degradation of operational capability to mect necessary capacity, the patch management strategy must include a description and timeline of additional mitigations that address the risk created by not installing the patch or update."

А как же уязявимости CISA KEV? Где-то написано, что нужно патчить только их? Нет, написано, что список этих уязвимостей нужно учитывать при приоритизации исправления (III.E.2, стр.7):

"2. This strategy required by Section III.E.1. must include:

b. Prioritization of all security patches and updates on CISA’s Known Exploited Vulnerabilities Catalog."

И я соглашусь, что CISA KEV-овские уязвимости нужно исправлять раньше других (понимая, что они туда могут попадать с большой задержкой). Как и с тем, что патчи нужно катать не абы как, а после тестирования и в соответствии с рекомендациями из NIST-800-82-r3 и IEC TR 62443-2-3, которые Алексей Лукацкий перечислил в своём посте. Перечень вполне толковый. 👍

В общем, приведённые в посте документы только укрепили меня в моей позиции. Противоречий моей позиции и указанных best practicies не вижу. 😉