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

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

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

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus. Товарищи взяли CISA KEV и добавили туда данные EPSS (Score и Percentile), CVSS из NVD, а также Treat Intelligence фид от GreyNoise. Вроде ничего хитрого, но получилось занимательно.

1. Самое очевидное это то, что можно дополнительно приоритизировать уязвимости из CISA KEV для исправления.
2. С другой стороны здесь наглядно видны проблемы источников.
2.1. Если уязвимость эксплуатируется вживую, то почему эту эксплуатацию GreyNoise не видит? С одной стороны это может быть связано с ограничением фида GreyNoise - не по всем уязвимостям могут эксплуатацию отслеживать. С другой стороны это может быть связано с тем, что CISA берет признак эксплуатации от вендора, по факту это может быть "вероятная эксплутация в единичной таргетированной атаке в полнолуние и пятницу 13-е", а подробностей нет и не будет.
2.2. Вот Exploit Prediction Scoring System (EPSS) показывает "probability [0-1] of exploitation in the wild in the next 30 days (following score publication)". Весьма весело взять уязвимости "CVE-2022" с детектами от GreyNoise и увидеть, что EPSS для них вероятность появления эксплоита оценивала довольно низко. Выделил на скриншоте 20%. Иногда оценка даже в 1-2%, как например в случае с одной из уязвимостей Exchange ProxyNotShell. В общем, EPSS это далеко не серебряная пуля.
2.3. Также интересно посортировать по CVSS. Сразу вылезают проблемы с уязвимостями, которых нет в NVD. Проблемы сортировки в таблице (но это ладно). А самое интересное уязвимости с CVSS 7, т.е. меньше High. В данном случае укладываются в Medium. То есть горячий привет тем, кто жестко фильтрует по CVSS от High и выше.

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

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

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации

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

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации. В pdf бюллетене приводится подробное описание атаки. Ознакомился. Мне, конечно, было наиболее интересно собственно про Log4Shell и начальную эксплуатацию.

1. В какой организации произошел инцидент? Непонятно. Это одна из FCEB organizations. Это может быть всем известная NASA, а может быть какая-нибудь Commission of Fine Arts. Но по большей части организации в списке выглядят критично.

2. Когда нашли? В апреле 2022. Предположительное время компрометации - февраль 2022 года.

3. Как нашли? Через ретроспективный контроль трафика с помощью CISA-вской EINSTEIN IDS. Увидели ip-адрес ранее засветившийся в атаках использующих Log4Shell.

4. Как известно Log4Shell (CVE-2021-44228 заведена 10.12.2021) касается кучи продуктов, а что именно поломали? VMware Horizon. Патч вышел 16.12.2021. Детект у Tenable для этой уязвимости (без аутентификации) вышел 07.01.2022. CISA требовали зафиксить все Log4Shell уязвимости до 24.12.2021.

5. Исходя из таймлайна, в сроки CISA (7 дней по факту) уложиться было мало реально. Причем это нужно было сделать ещё до появления нормальных детектов. Но то, что не уложились даже за 1-2 месяца вплоть до успешной атаки злоумышленников это конечно неслабое нарушение. И раз такое в принципе было возможно, CISA видимо не особо контролирует VM процесс в подопечных FCEB организациях, а сроки устранения, которые они спускают через свой Known Exploited Vulnerabilities Catalog видимо по факту не выдерживаются.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

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

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решениеПро SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение.

В первой части определили, что SSVC это по сути опросник. Задаем значения некоторых параметров связанных с уязвимостью, получаем в результате решение по уязвимости (Track, Track*, Attend, Act).

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

Итак, параметры следующие:

1. (State of) Exploitation - (Состояние) Эксплуатации
2. Automatable - Автоматизируемость
3. Technical Impact - Техническое Воздействие
4. Mission Prevalence and Public Well-Being Impact - Целевая Распространенность (понимаю, что так себе перевод, но это хитро вводится, будем разбираться позже) и Воздействие на Общественное Благополучие

Часть из них могут принимать 2 значения, часть 3 значения. Значения "фиг его знает" умышленно нет. Когда выбрать значения сложновато "CISA определяет значение, которое является наиболее разумным предположением, основанным на предыдущих событиях" ("the most reasonable assumption based on prior events"). "Такой подход требует надежных исторических данных, и будущие события могут со временем изменить эти предположения." Что за события и исторические данные имеются ввиду сказать сложно. Подозреваю, что все же имеет место быть традиционный "пол, палец, потолок". Если есть идеи, напишите в комментах.

Всего 36 комбинаций параметров и все они представлены на 10-й странице SSVC Guide от CISA.
Каждый из этих параметров заслуживает детального рассмотрения и медитации, что я и планирую далее по этой теме делать.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям

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

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям.

Идея там в следующем: а давайте на основе некоторого опросника (да, очередного) будем определять что нам делать с конкретной уязвимостью. Какие это могут быть решения:

1. Отслеживать (Track). В настоящее время каких-то особых действий по уязвимости не требуется. Организация продолжает отслеживать новую информацию по уязвимости и проводить её переоценку. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

2. Внимательно отслеживать (Track*). Уязвимость содержит определенные характеристики, которые могут потребовать более тщательного мониторинга изменений. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

3. Уделять внимание (Attend). Уязвимость требует внимания со стороны нижнего уровня менеджмента (organization's internal, supervisory-level individuals). Необходимые действия могут включать запрос помощи или информации об уязвимости, приводить к публикации внутренних и/или внешних нотификаций об уязвимости. CISA рекомендуют устранять такие уязвимости быстрее стандартных сроков обновления.

4. Действовать (Act). Уязвимость требует внимания со стороны нижнего уровня менеджмента и ТОПов (organization's internal, supervisory-level and leadership-level individuals). Необходимые действия включают запрос помощи или информации об уязвимости, а также публикацию внутренних и/или внешних нотификаций об уязвимости. Как правило, внутренние группы встречаются и договариваются как будут реагировать на эту уязвимость, а затем выполняют согласованные действия. CISA рекомендуют устранять такие уязвимости как можно скорее.

Относительно американских уровней менеджмента я не особо в курсе, а гуглится там противоречивое, но в целом оно как-то так.

Как я понимаю о чем это вообще

Кажется во многих организациях, если не во всех, есть чатики безопасников, куда кидаются уязвимости для обсуждения. И там уже сообща решается вопрос стоит ли подрываться и оперативно фиксить уязвимость, или оно в регулярном процессе само зафиксится. Очевидно какие-то уязвимости не особо критичные и вряд ли будут эксплуатироваться в реальных атаках (множество вариаций Meltdown и Spectre например). По каким-то с ходу непонятно, но выглядит подозрительно и надо бы за ними приглядывать (недавняя SQLite RCE CVE-2022-35737). Какие-то очевидно нужно оперативно брать в работу, т.к. явно опасно и в целом понятно как устранять (какая-нибудь очередная RCE в Exchange или AD). А для некоторых уязвимостей нужно на ТОПов выходить, запускать их отдельными треками и патчить пожарном режиме (Log4Shell, MS17-010).

В принципе процесс это знакомый и естественный. Но так сразу и не скажешь по какому принципу в таком чатике принимаются решения по конкретной уязвимости, "экспертная оценка" во всей красе. И цель SSVC, насколько я могу судить, этот процесс несколько формализовать.

В следующей части начнем разбираться на основании чего решение принимается. И т.к. недавняя ФСТЭКовская "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" тоже +- про это, хотя и реализация совсем другая, напрашивается некоторое сравнение / размышление как мы до жизни такой дошли. Stay tuned.

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон

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

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон.

"Целью SSVC является помощь в определении приоритетности устранения уязвимости на основе воздействия, которое ее эксплуатация может оказать на конкретную организацию (организации)."

Ознакомимся 🙂

Сделал видяшку с обзором Joint cybersecurity advisory (CSA) AA22-279A

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

Сделал видяшку с обзором Joint cybersecurity advisory (CSA) AA22-279A. Интересно будет ли фидбек от авторов документа. 😁