Архив рубрики: Темы

По поводу новости про малварь на Apple iPhone устройствах в России

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

По поводу новости про малварь на Apple iPhone устройствах в России

По поводу новости про малварь на Apple iPhone устройствах в России. Почитал исходный пресс-релиз.

1. Речь о заражениях ранее неизвестной малварью, использующей уязвимости iPhone. Т.е. видимо это не NSO Group Pegasus, которая обычно в подобных новостях светится.
2. Утверждается, что уязвимости были намеренно "предусмотрены производителем", т.е. Apple.
3. Утверждается, что заражено несколько тысяч устройств.
3. Утверждается, что это операция АНБ.

Охотно верю, что так и было. Имхо, Apple это зло и их устройствами пользоваться нельзя. Тем более, что в этих устройствах нет никакой особой необходимости, чего, например, не скажешь о продуктах Microsoft или Google. Одна мнимая статусность и глупые привычки, сформированные маркетинговой истерией. Надеюсь, что одним пресс-релизом не ограничится и последуют конкретные запретительные меры. Как по мне, то у госслужащих и у работников связанных с КИИ никаких продуктов Apple быть в принципе не должно.

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 1. Общая структура.

Буду потихоньку делать сопоставление. Если смотреть только на релиз, ничего особенно в глаза не бросается, но изменений довольно много.

1. Скорректировали название. Было "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)", стало "Руководство по организации процесса управления уязвимостями в органе (организации)". Новое название кажется более удачным. Тут и акцент именно на процесс, и вроде указывать уязвимости чего тоже смысла нет.
2. Общая структура документа не изменилась. Но добавили приложение с описанием BPMN элементов на схемах - полезная вещь.
3. Текстовая часть расширилась. Проект был на 29 страниц, релиз на 33 (включая одну страницу-приложение).

Разбираю ответы на мои вопросы с эфира 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! 🙂

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

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 идентификаторов. А если бы целиком правила детектирования уязвимостей открыли, вот это было бы реально круто! 😊