Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной

Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями со мной.

00:00 Паша торжественно бьёт в дуршлаг, здороваемся, я рассказываю чем занимаюсь и пиарю свои телеграмм-канальчики. 🙂
01:32 Как я начал заниматься безопасностью и VM-ом. Рассказываю как я довольно случайно прошёл на ИУ8 МГТУ Баумана по собеседованию для медалистов. VM-ом начал заниматься из-за первой работы в Позитиве и вот так дальше пошло-поехало.
04:06 Пригодился ли мне универ? Рассказываю, что, как и многие, не понял прикол с дикими объемами дискретки. Но безусловно базу дало. Не устаю пиарить курс Валентина Цирлова по ТОИБАС.
06:00 Начинаем с определения уязвимости. Определяю как багу, которую может использовать злоумышленник. Миша накидывает про мисконфигурации. Я вспоминаю про CCE и CCSS.
08:23 Классическая тема: сканеры уязвимостей, Vulnerability Management решения, Vulnerability Management процесс. Выражаю скепсис по поводу принципиальной разницы между сканером уязвимостей и VM-решением. Вспоминаю про шведов с Антифишингом в VM-ме. Паша накидывает: а нужен ли в VM-е контроль целостности? VM-процесс он про исправление уязвимостей, причём силами IT.
13:36 Миша спрашивает: "Что входит в процесс управления уязвимостями"? По факту на вопрос не отвечаю, а рассказываю почему основа VM-а это управление активами. 😏
18:59 Обсуждаем CVSS и методику оценки критичности уязвимостей ФСТЭК. Вспоминаю ОСОКу. Трендовых уязвимостей тоже касаемся. Агитирую за безусловный патчинг, указывая на куцые описания уязвимостей из MS Patch Tuesday. Вспоминаю про Linux Patch Wednesday.
30:38 Безусловные обновления плохо сочетаются с требованиями по проверке патчей западного ПО, включая open source. Выход? Импортозамещение! Рекомендательный алгоритм НКЦКИ и методика оценки обновлений ФСТЭК, что из этого более приоритетно? Вопрос к методологам.
34:40 Призываем отечественных вендоров публиковать уязвимости.
37:38 Vulnerability Management процесс в организации сложно построить? Какие люди нужны? Организации разные. Начинать нужно с руководства. Рассказываю про докажи-покажи.
43:21 Можно ли построить VM-процесс на open source решениях? Вполне реально сканить порты, детектить линуксовые уязвимости по пакетам. Но есть ограничения детектирования и спросить вам будет не с кого. С Windows всё плохо.
48:16 Обсуждаем уход западных VM-решений с российского рынка. Как это было?
50:17 Обсуждаем должен ли Compliance Management входить в VM и в чём проблема текущей реализацией CM в VM решениях и текущих стандартов конфигурирования.
56:52 Какая функциональность должна быть реализована в VM решении это вопрос регуляторный. Может нужна сертификация? 🤔
58:24 Крутое VM-решение для каждого клиента своё. Кому-то нужна "коробка", кому-то только детекты.
01:02:11 Вопрос VM-вендорам: почему такая разница в результатах детектирования между решениями от двух вендоров? Может сертификация нужна? 🤔 Паша и Миша накидывают кейсы по MS, которые могут давать расхождения. Хорошо, когда логика детектирования прозрачна и доступна для изучения.
01:07:00 Как я вижу развитие VM решений. Хотелось бы хорошего качества детектирования с фокусом в сторону импортозамещающей инфры. Также хотелось бы возможностей по добавлению уязвимостей со стороны и собственных детектов.
01:11:09 Торжественное вручение мне ведра с подарками. 😁

Подписывайтесь на КиберДуршлаг на удобных вам платформах по ссылкам в официальном посте!

XSpider-у 25 лет

XSpider-у 25 лет

XSpider-у 25 лет. Ура! 🥳 Имхо, 25 лет назад и начался весь современный Vulnerability Management. 1998 год - вышел XSpider и Nessus. Nmap, правда, вышел чуть раньше, 1 сентября 1997, но не суть. 🙂

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545)

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545)

Грядет опасная уязвимость cURL и libcurl (CVE-2023-38545). Пока это всё, что известно. Daniel Stenberg, основатель и ведущий разработчик cURL и libcurl, собирается сообщить подробности 11 октября около 06:00 UTC вместе с релизом curl 8.4.0. Учитывая, как он не так давно возмущался сомнительной CVE-шкой, которую завели без его ведома, вряд ли он стал бы наводить панику из-за ерунды. Вполне возможно, что там будет уязвимость, которая существенно затронет софт, использующий libcurl. Так что ждём. 🙂

А из нашего окна

А из нашего окна

А из нашего окна. Вид на Храм Преображения Господня в Преображенском. Выглядит настолько органично, как будто всегда здесь стоял. На самом деле построен на месте сквера в 2015 году. Помню как его строили. 🙂 А до сквера тут также был храм с 1768 по 1964 г. Снесли его под предлогом строительства метро. Собственно этот снесённый исторический храм и был восстановлен на основе чертежей 1883 года и архивных фотографий.

В новостях активно разгоняют про EoP в Atlassian Confluence (CVE-2023-22515)

В новостях активно разгоняют про EoP в Atlassian Confluence (CVE-2023-22515)

В новостях активно разгоняют про EoP в Atlassian Confluence (CVE-2023-22515). Злоумышленник может создавать неавторизованные аккаунты администратора Confluence и получать доступ к инстансам Confluence. Atlassian пишут, что некоторых их клиентов, у которых Confluence наружу торчит, таким образом уже поломали. Если это EoP у злоумышленника должен быть аккаунт какой-то, так ведь? А вот непонятно. Может там и обход аутентификации есть, уж больно CVSS большой. Уязвимы версии 8.*, а более старые версии неуязвимы (включая 7.19 LTS с EOL date: 28 Jul 2024). Если уязвимы, то обновляйтесь до 8.3.3, 8.4.3, 8.5.2 или применяйте workaround. Хотя лучше мигрируйте с продуктов Atlassian куда подальше.

Быстро же появился PoC для glibc EoP/LPE (CVE-2023-4911) "Looney Tunables" от заслуженного ресерчера

Быстро же появился PoC для glibc EoP/LPE (CVE-2023-4911) Looney Tunables от заслуженного ресерчера

Быстро же появился PoC для glibc EoP/LPE (CVE-2023-4911) "Looney Tunables" от заслуженного ресерчера. Пишет, что write-up Qualys-ов был более чем подробным.

А вдруг в продуктах Cisco есть root-овые учётки с захардкоженными паролями, которыми могут воспользоваться злоумышленники? Звучит как полный бред и паранойя, но видимо такое возможно

А вдруг в продуктах Cisco есть root-овые учётки с захардкоженными паролями, которыми могут воспользоваться злоумышленники? Звучит как полный бред и паранойя, но видимо такое возможно

А вдруг в продуктах Cisco есть root-овые учётки с захардкоженными паролями, которыми могут воспользоваться злоумышленники? Звучит как полный бред и паранойя, но видимо такое возможно. 🙂 Как минимум в одном кейсе Cisco сегодня сами признались.

"Уязвимость в Cisco Emergency Responder может позволить неаутентифицированному удаленному злоумышленнику войти в уязвимое устройство с использованием учетной записи root, которая имеет статические дефолтные креды, которые нельзя изменить или удалить." 🤷‍♂️

Cisco Emergency Responder, насколько я понимаю, это такая штуковина, которая звонки на 911 через ip-телефонию должна обрабатывать правильным образом в соответствии с требованиями американского регулятора. Пишут, что учётка видимо должна была использоваться только в процессе разработки, но, как видим, благополучно ушло в прод as is. Также пишут, что проблема только в CER 12.5(1)SU4, а с остальными версиями всё ок. Верим. 🙂