Архив за месяц: Май 2023

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

1 комментарий

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 3/3. Поддержка методик ФСТЭК.

Про последние три вопроса распишу вместе. Каверзность их в том, что по-хорошему на них можно ответить только "да, мы поддерживаем", либо "нет, мы не поддерживаем, потому что не хотим или не можем". В любом случае для клиента польза: либо готовая автоматизация процесса так, как это требует регулятор, либо публичная обратная связь для актуализации методик.

> 5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

> 3. Ваше VM-решение позволяет проводить приоритизацию уязвимостей с использованием "Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств" ФСТЭК?

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Positive Technologies MaxPatrol VM я смотрел текущую реализацию, для R-Vision VM, АЛТЭКС-СОФТ RedCheck и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Temporal и Environmental метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

> 4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

Поэтому варианта 2: либо VM-вендор возьмет задачу анализа обновлений на себя, либо это так и останется проблемой на стороне клиента.

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Про CVE_Prioritizer и Vulristics

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

Про CVE_Prioritizer и Vulristics

Про CVE_Prioritizer и Vulristics. Несколько раз за последние месяцы натыкался на посты про CVE_Prioritizer. Но сегодня появился повод прокомментировать.

"CVE_Prioritizer is a powerful tool that helps you prioritize vulnerability patching by combining CVSS, EPSS, and CISA's Known Exploited Vulnerabilities. It provides valuable insights into the likelihood of exploitation and the potential impact of vulnerabilities on your information system."

Прикольная утилита, но, имхо, мой Vulristics приоритизирует покруче. 🙂 Он учитывает не только CVSS, EPSS и CISA KEV, но и тип уязвимости, распространенность софта, информацию об эксплоитах (из многих паков на Vulners) и атаках из AttackersKB.

И CVE_Prioritizer, и Vulristics для каждой уязвимости в динамике выполняют запросы к внешним источникам. Только у CVE_Prioritizer таких источников только 2 и поэтому он отрабатывает быстрее. Кроме того, Vulristics каждый раз в динамике определяет наименование софта и тип уязвимости по описанию. Это медленная операция. А в случае использования Vulners в качестве источника, всё это ещё и стоит денег 💸 (хотя лично мне не стоит, т.к. у меня ресерчерская лицензия - спасибо ребятам из Vulners!❤️). Так что с помощью Vulristics достаточно удобно оценивать 100-200 уязвимостей за раз (как в MS Patch Tuesday), а оценивать больше не особо рационально. 🙁

Что с этим можно сделать? Если заранее формировать полный (и желательно бесплатный/общедоступный 😉) фид по всем уязвимостям, чтобы Vulristics строил отчёт по готовым данным, это было бы гораздо быстрее и эффективнее. В этом случае можно было бы приоритизировать уязвимости хоть для всей инфраструктуры разом. У меня есть в некоторых долгосрочных планах этим заняться. Кто хочет поучаствовать - всегда welcome! 🙂

Я в обосновании ответа чуток промахнулся, т.к

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

Я в обосновании ответа чуток промахнулся, т.к. взял общее количество CVEшек с https://www.cve.org/About/Metrics, а не со страницы статистики NVD. А там эти значения различаются! 🙂 Но результат всё равно правильный. 😉

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)"

5 комментариев

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)". Дождались, ура! 🙂 На первый взгляд не сильно отличается от исходного проекта, но нужно аккуратненько посравнивать.

Выпустил эпизод про майский Microsoft Patch Tuesday

1 комментарий

Выпустил эпизод про майский Microsoft Patch Tuesday. Первые впечатления оказались вполне верными. Добавил ещё 4 уязвимости, которые выглядят многообещающе, расширил описание и указал на пару странностей в EPSS.

———

Hello everyone! This episode will be about Microsoft Patch Tuesday for May 2023, including vulnerabilities that were added between April and May Patch Tuesdays. As usual, I use my open source Vulristics project to analyse and prioritize vulnerabilities. I took the comments about the vulnerabilities from the Qualys, Tenable, Rapid7, ZDI Patch Tuesday reviews. It's been a long time since we've had such tiny Patch Tuesday. 57 CVEs, including CVEs appeared during the month. And only 38 without them! 😄

Urgent
00:45 Memory Corruption – Microsoft Edge (CVE-2023-2033)

Critical
01:17 Security Feature Bypass – Secure Boot (CVE-2023-24932)
02:55 Memory Corruption – Microsoft Edge (CVE-2023-2136)

High
03:11 Remote Code Execution – Windows OLE (CVE-2023-29325)
04:20 Elevation of Privilege – Windows Win32k (CVE-2023-29336)
05:19 Remote Code Execution – Windows Network File System (CVE-2023-24941)
06:07 Remote Code Execution – Windows Pragmatic General Multicast (PGM) (CVE-2023-24943)
06:58 Remote Code Execution – Windows Lightweight Directory Access Protocol (LDAP) (CVE-2023-28283)
07:31 Remote Code Execution – Microsoft SharePoint (CVE-2023-24955)

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost
🗒 Vulristics report

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

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

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source.

Начиная с 2:15:19:

"Вся индустрия страдает от простой вещи - нет доступных оцифрованных знаний, чтобы ими все могли пользоваться. И как будто бы сейчаc мы очень хорошо чувствуем, что это всё неправильно. Кто-то скажет, это ведь конкурентное преимущество! И наверное для какой-то другой компании это было бы так: наше знание, наше конкурентное преимущество. Но, чёрт побери, если мы заявляемся, что мы лидер Cyber Security и хотим стать мировым гигантом нельзя заниматься такими подходами.

Для нас, наверное, сейчас самое время, чтобы мы дали в Open Community и средства, которые позволяют собирать экспертизу, и внесли свою экспертизу в Open Source. У нас большой проект сейчас в этом направлении движется. Мы хотим с помощью наших телодвижений в Open Source создать такой прецедент, когда крупнейшая компания в области безопасности вывела и набор средств, необходимых для работы со знаниями, и поделилась всеми своими знаниями. И мы не хотим конкурировать в этой плоскости. Хочется поделиться всем, чем мы владеем и призвать всех остальных делиться.

От этого забенефитит весь мир. Все почувствуют насколько иной уровень зрелости и знаний в области кибербезопасности станет доступен каждой первой компании и каждому первому вендору. В этом наш большой смысл и задача. И мы явно туда будем идти весь этот год. И что-то в этом направлении будет происходить."

Я не особо понимаю о каких именно знаниях здесь идет речь, но звучит интересно и многообещающе. 🙂 Я, конечно, сразу думаю в сторону баз уязвимостей и детектов. Очень хотелось бы, раз уж взят такой курс на открытость, чтобы знания о том какие уязвимости умеет детектировать MaxPatrol 8 / MaxPatrol VM были доступны в виде открытого фида. Хотя бы в виде одного только набора CVE идентификаторов. А если бы целиком правила детектирования уязвимостей открыли, вот это было бы реально круто! 😊

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

4 комментария

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 2/3. Эталонный сканер.

Вопрос был такой:  

> 2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Windows и отечественных Linux-ов?

Зачем я задал этот вопрос? Давайте начнем с того, что такое эталонный сканер уязвимостей.

Начнем просто с эталона. Возьмем, для примера, эталон единицы измерения массы. "Международный прототип (эталон) килограмма хранится в Международном бюро мер и весов (расположено в Севре близ Парижа) и представляет собой цилиндр диаметром и высотой 39,17 мм из платино-иридиевого сплава (90 % платины, 10 % иридия)." Вряд ли вы будете использовать этот цилиндр для того, чтобы отвесить себе килограмм помидоров. Скорее всего вы просто положите свои помидоры на электронные весы. А вот для того, чтобы проверить, что эти весы работают корректно, некоторый эталон очень даже пригодится.

Теперь по поводу сканеров уязвимостей. Не секрет, что если вы просканируете один и тот же хост различными сканерами уязвимостей, то вы получите различные же результаты. Иногда практически не пересекающиеся по CVE идентификаторам. Тут дело не в том, что различные VM-вендоры поддерживают различные наборы Third-party софтов, это ещё простительно. Но даже если мы ограничимся только детектированием уязвимостей ОС, по KB-шкам Windows или бюллетеням безопасности Linux, всё равно разница будет, потому что каждый VM-вендор реализует свои собственные алгоритмы детектирования. А уязвимость на хосте либо есть, либо нет. Это вещь объективная. И если результаты различаются, значит как минимум одно из средств детектирования работает неправильно.

Есть ли у нас такой сканер уязвимостей, результаты детектирования которого мы могли бы принять за эталон? Есть один претендент - ScanOVAL. Он общедоступный, бесплатный и самое главное выпущен ФСТЭК. С ним вполне удобно сравнивать результаты детектирования уязвимостей для Windows и российских Linux-ов.

Так готовы ли VM-вендоры признать ScanOVAL за эталон качества детектирования уязвимостей?

Каверзность вопроса в том, что если ответить "да", то все различия при сравнении со ScanOVAL будут автоматически являться ошибками. А если ответить "нет", то получается сканер уязвимостей регулятора некорректно уязвимости детектирует? Давайте-ка с этого момента поподробнее. 😏

Любой ответ представителя VM-вендора, сулит проблемы для него. А для клиентов наоборот - любой ответ выгоден, т.к. подсвечивает проблемы детектирования уязвимостей и улучшает либо возможности продукта VM-вендора, либо ScanOVAL. Ну или хотя бы дискуссию провоцирует о качестве детектирования, и то неплохо.

В итоге вопрос про ScanOVAL задали в 2:22:01 в таком виде:

"А у нас ещё такой провокационный немного вопрос в сторону присутствующих здесь вендоров. А что если просто взять ScanOVAL и с помощью умелых рук организовать весь процесс, чем это будет слабее Enterprise решений?" 🤦🏻‍♂️

Как видите, вопрос не про эталон, не про качество сканирования, а из серии можно ли выкопать котлован малой сапёрной лопаткой. Ну и ответы соответствующие. 🤷‍♂️

В общем, жаль, что обсуждение этой темы не получилось, но попробуем пропедалировать её в следующий раз. 😉

Часть 1