Тут добавил комментарии на русском из черновиков и тайминг. Все в дело 😊 https://youtu.be/jgKK9ovlNFU

Active Vul­ner­a­bil­i­ties

01:31 🔴 “CISA warns of hack­ers exploit­ing PwnKit Lin­ux vul­ner­a­bil­i­ty (CVE-2021–4034)” by Bleep­ing­Com­put­er
// Не только американцам это нужно быстро патчить.
03:14 🔴 “Atlass­ian Con­flu­ence OGNL Injec­tion Remote Code Exe­cu­tion (RCE) Vul­ner­a­bil­i­ty (CVE-2022–26134)” by Qualys
// В статье Qualys приводят описание OGNL Injec­tion, RCE Pay­load, Exploit POC, Exploit Analy­sis и Source Code Analy­sis. Это подробная техническая статья. Если вам интересно как такие уязвимости эксплуатируются и детектируются, посмотрите этот пост.

Data sources

05:27 🟠 “New Vul­ner­a­bil­i­ty Data­base Cat­a­logs Cloud Secu­ri­ty Issues” by Dark­Read­ing & Wiz
// Непонятно насколько действительно нужна отдельная база данных. Кажется это все можно было бы оформить как CVEs. Тем более, что у многих уязвимостях в этой базе уже есть CVE IDs. Но инициатива хорошая. Лишний раз доказывает, что у MITRE и NVD есть проблемы.

Ana­lyt­ics

07:23 🟢 “MITRE shares this year’s list of most dan­ger­ous soft­ware bugs (CWE Top 25)” by Bleep­ing­Com­put­er
// Похоже на правду, хотя 'OS Com­mand Injec­tion' кажется должно быть выше. Ну и надо понимать, что CWE идентификаторы присваюваются уязвимости вручную и поэтому тут могут быть ошибки классификации. Но все равно любопытно.
09:06 🟠 “Cyber­at­tacks via Unpatched Sys­tems Cost Orgs More Than Phish­ing” by Dark­Read­ing & Tetra Defense
// Хорошее замечание в статье: "Data on suc­cess­ful com­pro­mis­es can help com­pa­nies deter­mine the most crit­i­cal attack vec­tors to address, but it should be not­ed that the con­clu­sions depend great­ly on the spe­cif­ic inci­dent-response firm". Но то, что MFA и патчинг это важно — не поспоришь.
11:07 🔴 “Zero-Days Aren’t Going Away Any­time Soon & What Lead­ers Need to Know” by Dark­Read­ing & Arc­tic Wolf
// Ну, в целом не попоришь. Моё мнение — пока критичные известные уязвимости на исправляются оперативно, думать о Zero-Days преждевременно. А так, это конечно в первую очередь задача SOC.

VM ven­dors write about Vul­ner­a­bil­i­ty Man­age­ment

13:57 🟡 “Why We’re Get­ting Vul­ner­a­bil­i­ty Man­age­ment Wrong” by Dark­Read­ing & Rezil­ion
// Это давнишний спор: стоит ли исправлять уязвимости в софте, который в настоящий момент не запущен? Ну и обычно на это отвечают да. Потому что никто не может гарантировать, что софт вдруг не начнет запускаться. Но если будет возможность выделить среди критичных уязвимостей уязвимости, в софте, который уже запущен или регулярно запускается, то это хороший испточник данных для дополнительной приоритизации. Почему бы и нет. Хорошо, что Rezil­ion это подсвечивают.
16:41 🔴 “Risk-based Reme­di­a­tion Pow­ered by Patch Man­age­ment in Qualys VMDR 2.0” by Qualys
// На самом деле давно было интересно что же нового в Qualys Vul­ner­a­bil­i­ty Man­age­ment, Detec­tion and Response. В целом, это похоже на Ten­able vul­ner­a­bil­i­ty pri­or­i­ty rat­ing (VPR). Наверное и формируется примерно так же. Но про техническое подробности TruRisk надо будет искать где-то в другом месте. Я согласен с тем, что фокус VM должен быть именно на Reme­di­a­tion и хорошо, что Qualys продвигают эту тему. Достаточен ли объем новых фич, чтобы называть это VMDR 2.0? Пока это не кажется так. Кажется, что если бы Reme­di­a­tion был полностью автоматизирован для 100% хостов (что требует принципиально другого подхода к тестированию работоспособности после патча), то тогда это было бы 2.0. Но маркетологам Qualys виднее.
20:37 🟢 “Mod­ern IT Secu­ri­ty Teams’ Inevitable Need for Advanced Vul­ner­a­bil­i­ty Man­age­ment” by Threat­post & Sec­pod
// Дается список проблем и для преодаления этих проблем нужен Advanced Vul­ner­a­bil­i­ty Man­age­ment от Sec­pod. В целом, список справедливый и то, что они обращают внимание на vul­ner­a­bil­i­ties beyond CVEs кажется мне очень правильным.
22:25 de-West­ern­iza­tion of IT
см.выше https://avleonov.ru/2022/07/03/3‑rabotaju-nad-obzorom-vulnerability-management-novo/

#Vul­ner­a­bil­i­ty­Man­age­ment #Infor­ma­tion­Se­cu­ri­ty