Ещё один пример того, что 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 и всем, что нужно. ФСТЭК молодцы. 👍
@avleonovrus #CISA #NIST #MITRE #BDU #FSTEC #Firefox #thoseamericans
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 и всем, что нужно. ФСТЭК молодцы. 👍
@avleonovrus #CISA #NIST #MITRE #BDU #FSTEC #Firefox #thoseamericans
Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.
@avleonovrus #ZeroDay #0day #boredom #EternalBlue #FSTEC #Kaspersky #NIST #NSA #PortSwigger #ProxyNotShell #Qualys #ScienceDirect #terms #Trendmicro
@avleonovrus #ZeroDay #0day #boredom #EternalBlue #FSTEC #Kaspersky #NIST #NSA #PortSwigger #ProxyNotShell #Qualys #ScienceDirect #terms #Trendmicro
Telegram
Vulnerability Management and more
Hello everyone! In my English-language telegram chat @avleonovchat, the question was asked: "How to find zero day vulnerabilities with Qualys?" Apparently this question can be expanded. Not just with Qualys, but with any VM solution in general. And is it…
Про историю Vulnerability Management-а. Иногда люди говорят публично что-то странное, но делают это настолько уверенно, что сам начинаешь в себе сомневаться. Вдруг они лучше знают? Ну или может ты их не так понял? Вот, например, посмотрел ролик "Traditional Vulnerability Management is Dead!" с Stefan Thelberg, CEO Holm Security. Это те ребята, которые считают, что без встроенного Антифишинга VM уже не VM.
В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:
1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.
То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.
Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏
Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.
@avleonovrus #Nessus #OpenVAS #HolmSecurity #Antifishing #Tenable #Qualys #Rapid7 #Nexpose #PositiveTechnologies #XSpider #MaxPatrol #NIST
В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:
1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.
То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.
Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏
Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.
@avleonovrus #Nessus #OpenVAS #HolmSecurity #Antifishing #Tenable #Qualys #Rapid7 #Nexpose #PositiveTechnologies #XSpider #MaxPatrol #NIST
Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0? Мне это тоже интересно.
Имхо, CVSS это не священная корова и держаться за него не стоит:
1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.
Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:
1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.
@avleonovrus #CVSS #CVSS4 #FIRST #NVD #NIST #ФСТЭК #БДУ #FSTEC #BDU #ОСОКА
Имхо, CVSS это не священная корова и держаться за него не стоит:
1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.
Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:
1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.
@avleonovrus #CVSS #CVSS4 #FIRST #NVD #NIST #ФСТЭК #БДУ #FSTEC #BDU #ОСОКА
Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:
▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные
1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.
2. Эксплуатационные предлагаю сделать такие:
Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept (P), Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).
Exploitation Activities: Not Defined (X), Reported (R), Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉
Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.
Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.
3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.
Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты
Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%
Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»
Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.
Как вам?
@avleonovrus #CVSS #CVSS4 #CVSS3 #FIRST #NVD #NIST #ФСТЭК #БДУ #FSTEC #BDU #ОСОКА
▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные
1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.
2. Эксплуатационные предлагаю сделать такие:
Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept (P), Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).
Exploitation Activities: Not Defined (X), Reported (R), Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉
Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.
Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.
3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.
Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты
Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%
Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»
Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.
Как вам?
@avleonovrus #CVSS #CVSS4 #CVSS3 #FIRST #NVD #NIST #ФСТЭК #БДУ #FSTEC #BDU #ОСОКА
Изменения в источнике данных NVD для Vulristics. В NVD стали гораздо менее толерантно подходить к использованию своего API. После 5 последовательных запросов начинает отдаваться такое:
Согласно документации:
Публичный rate limit (без ключа API) составляет 5 запросов в скользящем 30-секундном окне; rate limit с ключом API составляет 50 запросов в скользящем 30-секундном окне.
Поэтому, если вы используете NVD API, ставьте sleep-ы. 🤷♂️
✅ Для Vulristics сделал поддержку аутентификации по ключу NVD и sleep-ы в 0.6 секунд при использовании ключа и 6 секунды без использования ключа.
Для получения ключа NVD API нужно указать организацию, тип организации и email в форме. Через несколько секунд на email придёт одноразовая ссылка, по которой отдаётся ключ.
@avleonovrus #Vulristics #NVD #NIST #API
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>
Это аффектило, в том числе и мой скрипт в Vulristics, который запрашивает данные из NVD. 😐Согласно документации:
Публичный rate limit (без ключа API) составляет 5 запросов в скользящем 30-секундном окне; rate limit с ключом API составляет 50 запросов в скользящем 30-секундном окне.
Поэтому, если вы используете NVD API, ставьте sleep-ы. 🤷♂️
✅ Для Vulristics сделал поддержку аутентификации по ключу NVD и sleep-ы в 0.6 секунд при использовании ключа и 6 секунды без использования ключа.
Для получения ключа NVD API нужно указать организацию, тип организации и email в форме. Через несколько секунд на email придёт одноразовая ссылка, по которой отдаётся ключ.
@avleonovrus #Vulristics #NVD #NIST #API
Выпустил ролик на 12 минут по итогам октября для своих англоязычных ресурсов. Интенсивный и интересный месяц был. Я вышел на новую работу, активно дорабатывал Vulristics, запустил Linux Patch Wednesday (пока не получил значительного отклика, но вижу здесь перспективы), традиционно проанализировал Microsoft Patch Tuesday, разобрался с кучей других уязвимостей и даже тему с обучением VM-у дальше продвинул. И ноябрь тоже бурно начался. Посмотрим, что в итоге выйдет. 🙂
---
Hello everyone! October was an interesting and busy month for me. I started a new job, worked on my open source Vulristics project, and analyzed vulnerabilities using it. Especially Linux vulnerabilities as part of my new Linux Patch Wednesday project. And, of course, analyzed Microsoft Patch Tuesday as well. In addition, at the end of October I was a guest lecturer at MIPT/PhysTech university.
00:29 Back to Positive Technologies
00:59 Vulristics NVD Data Source
02:20 Vulristics Custom Data Source
03:22 Linux Patch Wednesday Project
04:16 Linux Patch Wednesday October 2023
05:49 Microsoft Patch Tuesday October 2023
09:12 Other Vulnerabilities October 2023
10:14 Miercom released a report "Vulnerability Management Competitive Assessment"
10:54 Vulners presented AI Score v2
11:31 My PhysTech Lecture
🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost
@avleonovrus #LinuxPatchWednesday #VulnerabilityManagement #PatchTuesday #API #AriaOperations #Assetnote #Chromium #Citrix #CitrixBleed #curl #CustomDataSource #Education #Exchange #glibc #Golang #HTTP2 #JetBrains #libvpx #Linux #MessageQueuing #Microsoft #NetScaler #NIST #NVD #OVAL #PhysTech #PositiveTechnologies #sessionhijacking #Skype #Squid #TeamCity #vCenter #VMprocess #VMware #Vulristics #Win32k #WordPad
---
Hello everyone! October was an interesting and busy month for me. I started a new job, worked on my open source Vulristics project, and analyzed vulnerabilities using it. Especially Linux vulnerabilities as part of my new Linux Patch Wednesday project. And, of course, analyzed Microsoft Patch Tuesday as well. In addition, at the end of October I was a guest lecturer at MIPT/PhysTech university.
00:29 Back to Positive Technologies
00:59 Vulristics NVD Data Source
02:20 Vulristics Custom Data Source
03:22 Linux Patch Wednesday Project
04:16 Linux Patch Wednesday October 2023
05:49 Microsoft Patch Tuesday October 2023
09:12 Other Vulnerabilities October 2023
10:14 Miercom released a report "Vulnerability Management Competitive Assessment"
10:54 Vulners presented AI Score v2
11:31 My PhysTech Lecture
🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost
@avleonovrus #LinuxPatchWednesday #VulnerabilityManagement #PatchTuesday #API #AriaOperations #Assetnote #Chromium #Citrix #CitrixBleed #curl #CustomDataSource #Education #Exchange #glibc #Golang #HTTP2 #JetBrains #libvpx #Linux #MessageQueuing #Microsoft #NetScaler #NIST #NVD #OVAL #PhysTech #PositiveTechnologies #sessionhijacking #Skype #Squid #TeamCity #vCenter #VMprocess #VMware #Vulristics #Win32k #WordPad
YouTube
October 2023: Positive Technologies, Vulristics, Linux Patch Wednesday, MS Patch Tuesday, PhysTech
Hello everyone! October was an interesting and busy month for me. I started a new job, worked on my open source Vulristics project, and analyzed vulnerabilities using it. Especially Linux vulnerabilities as part of my new Linux Patch Wednesday project. And…
Время идёт, а я, признаться, всё также продолжаю впадать в ступор, когда вижу термин "Exposure" в около-VM-ном контексте - пора с этим что-то делать! 🤔 От наших регуляторов определённой позиции не видно. В связи с этим я решил, что в своих блогопостах буду пока просто калькировать это безобразие.
🔹 Exposure - Экспозиция
🔹 Exposures - Экспозиции
🔹 Cyber Exposure - Киберэкспозиция
🔹 Exposure Management - Управление Экспозициями (во множественном числе по аналогии с Vulnerability Management - Управление Уязвимостями)
🔹 exposed - экспозированный
🔹 to expose - экспозировать
Пока не будет какого-то адекватного официального определения, буду понимать под (кибер)экспозицией "подверженность внешнему (кибер)воздействию".
Это более-менее бьётся с глоссарием NIST:
"Extent to which an organization and/or stakeholder is subject to a risk."
"Степень, в которой организация и/или стейкхолдер подвержены риску." 🤷♂️
Пример экспозиции: Windows-хост уязвимый к MS17-010 доступен из Интернет по SMB порту, поэтому любой удалённый злоумышленник может его тривиально поломать.
Если же мы отключим этот хост от сети, то уязвимость на нём всё равно будет, но экспозиции при этом уже не будет. В этом вижу разницу. 🧙♂️
При всём этом я считаю, следующее:
🔻 Всяческого порицания достоин тот буржуй, который придумал тащить в ИБ такое туманное и многозначное слово как "exposure". 🔮 Имхо, единственная причина почему его так часто сейчас используют, потому что "Exposure Management" это круто-модно-молодежно, а "Vulnerability Management" это что-то привычное и неинтересное. Тухлый креатив маркетолухов, которые не могут сделать стоящую вещь, поэтому играются со словами. 😤 Но у них там на западе своя атмосфера и вряд ли мы можем как-то повлиять на это. У виска покрутить разве что. 🤪
🔻 Переводить "Exposure Management" как "Управление Рисками" в общем случае считаю неправильным, т.к. непонятно что тогда такое "Risk Management". 😏 Это уже какой-то анекдот про кота и кита. Нет уж, давайте "риск" это будет "risk", а для "exposure" будем использовать что-то другое.
🔻 Раз уж термин продолжает использоваться, то давайте переводить подобное в подобное, а не пытаться додумывать, что конкретно имел ввиду автор текста в каждом случае. Дело это неблагодарное.
🔻 В оригинальных (непереводных) текстах лучше обходиться без всяких там экспозиций, а писать в конкретных терминах. Ну или наоборот вводить это дело в активный обиход и обмазываться по полной. 😅🌝
Дальше как раз посмотрим свеженький документ, в котором сплошной ехал exposure через exposure.
@avleonovrus #Exposure #ExposureManagement #CyberExposure #новояз #NIST #SMB
🔹 Exposure - Экспозиция
🔹 Exposures - Экспозиции
🔹 Cyber Exposure - Киберэкспозиция
🔹 Exposure Management - Управление Экспозициями (во множественном числе по аналогии с Vulnerability Management - Управление Уязвимостями)
🔹 exposed - экспозированный
🔹 to expose - экспозировать
Пока не будет какого-то адекватного официального определения, буду понимать под (кибер)экспозицией "подверженность внешнему (кибер)воздействию".
Это более-менее бьётся с глоссарием NIST:
"Extent to which an organization and/or stakeholder is subject to a risk."
"Степень, в которой организация и/или стейкхолдер подвержены риску." 🤷♂️
Пример экспозиции: Windows-хост уязвимый к MS17-010 доступен из Интернет по SMB порту, поэтому любой удалённый злоумышленник может его тривиально поломать.
Если же мы отключим этот хост от сети, то уязвимость на нём всё равно будет, но экспозиции при этом уже не будет. В этом вижу разницу. 🧙♂️
При всём этом я считаю, следующее:
🔻 Всяческого порицания достоин тот буржуй, который придумал тащить в ИБ такое туманное и многозначное слово как "exposure". 🔮 Имхо, единственная причина почему его так часто сейчас используют, потому что "Exposure Management" это круто-модно-молодежно, а "Vulnerability Management" это что-то привычное и неинтересное. Тухлый креатив маркетолухов, которые не могут сделать стоящую вещь, поэтому играются со словами. 😤 Но у них там на западе своя атмосфера и вряд ли мы можем как-то повлиять на это. У виска покрутить разве что. 🤪
🔻 Переводить "Exposure Management" как "Управление Рисками" в общем случае считаю неправильным, т.к. непонятно что тогда такое "Risk Management". 😏 Это уже какой-то анекдот про кота и кита. Нет уж, давайте "риск" это будет "risk", а для "exposure" будем использовать что-то другое.
🔻 Раз уж термин продолжает использоваться, то давайте переводить подобное в подобное, а не пытаться додумывать, что конкретно имел ввиду автор текста в каждом случае. Дело это неблагодарное.
🔻 В оригинальных (непереводных) текстах лучше обходиться без всяких там экспозиций, а писать в конкретных терминах. Ну или наоборот вводить это дело в активный обиход и обмазываться по полной. 😅🌝
Дальше как раз посмотрим свеженький документ, в котором сплошной ехал exposure через exposure.
@avleonovrus #Exposure #ExposureManagement #CyberExposure #новояз #NIST #SMB
NIST передаст управление базой NVD отраслевому консорциуму. Заявление сделала Tanya Brewer, руководитель программы NIST NVD, на VulnCon. У меня туда доступа нет, читаю пересказы и реакции. Письменное заявление обещают опубликовать на сайте NVD до 29 марта.
Среди причин, приведших к кризиcу NVD, озвучили следующее:
🔻Годовой бюджет NIST сократили на 12%. До жалких $1,46 млрд. 😅 Интересно сколько из этого уходило на NVD.
🔻Заканчивается контракт с подрядчиком, который работал над NVD вместе с NIST. Предположительно это Huntington Ingalls Industries. Почему-то компания, которая строит военные корабли. 🤷♂️
🔻Внутренние дискуссии по отказу от одних стандартов (CPE) и внедрению других (Package URLs)
🔻И вообще "за этим стоит история, она длинная, запутанная и очень административная".
Но после передачи дел новому консорциуму всё попрёт:
"Мы не собираемся закрывать NVD; мы находимся в процессе решения текущей проблемы. А затем мы снова сделаем NVD надёжным и заставим его расти". 😏
@avleonovrus #NVD #NIST
Среди причин, приведших к кризиcу NVD, озвучили следующее:
🔻Годовой бюджет NIST сократили на 12%. До жалких $1,46 млрд. 😅 Интересно сколько из этого уходило на NVD.
🔻Заканчивается контракт с подрядчиком, который работал над NVD вместе с NIST. Предположительно это Huntington Ingalls Industries. Почему-то компания, которая строит военные корабли. 🤷♂️
🔻Внутренние дискуссии по отказу от одних стандартов (CPE) и внедрению других (Package URLs)
🔻И вообще "за этим стоит история, она длинная, запутанная и очень административная".
Но после передачи дел новому консорциуму всё попрёт:
"Мы не собираемся закрывать NVD; мы находимся в процессе решения текущей проблемы. А затем мы снова сделаем NVD надёжным и заставим его расти". 😏
@avleonovrus #NVD #NIST
С начала года количество новых CVE идентификаторов в NVD уже перевалило за 10000, а обработали они пока только 42% от общего количества. Более того, если смотреть данные за прошлый месяц, за этот месяц и за текущую неделю, то получается, что обрабатывают они только 3-5% новых CVE. 🤷♂️ В общем, не похоже, что кризис NVD собирается заканчиваться, несмотря на все заверения. Про новый консорциум тоже пока нет новостей.
@avleonovrus #NVD #NIST
@avleonovrus #NVD #NIST
Записи c VulnCon 2024 доступны на Youtube. Я об этой конфе уже писал ранее, она прошла в конце марта.
Там много интересного контента связанного с уязвимостями: их описание, приоритизация, ответственное разглашение, разнообразные связанные стандарты. 🤩 Кейсы про управление уязвимостями в организациях тоже есть. В России такого контента пока маловато. У нас если и говорят об уязвимостях, то скорее обсуждают конкретные ресерчи или атаки, а не то, как работать с уязвимостями более-менее массово и систематически. 😔
Описание докладов также доступно в программе конференции. Там удобно подыскивать интересное, а потом уже смотреть запись в Youtube канале.
Есть там и панельная дискуссия с Tanya Brewer из NIST. Но что-то откровений про кризис NVD, которые ей приписывали в статье по итогам VulnCon ("story behind it, it is long, convoluted and very administrivia" и т.п.) я не нашёл. Искал по автоматическим субтитрам. Ну, может это было сказано не на панельке, а где-то ещё. 🤷♂️
@avleonovrus #VULNCON24 #NVD #NIST
Там много интересного контента связанного с уязвимостями: их описание, приоритизация, ответственное разглашение, разнообразные связанные стандарты. 🤩 Кейсы про управление уязвимостями в организациях тоже есть. В России такого контента пока маловато. У нас если и говорят об уязвимостях, то скорее обсуждают конкретные ресерчи или атаки, а не то, как работать с уязвимостями более-менее массово и систематически. 😔
Описание докладов также доступно в программе конференции. Там удобно подыскивать интересное, а потом уже смотреть запись в Youtube канале.
Есть там и панельная дискуссия с Tanya Brewer из NIST. Но что-то откровений про кризис NVD, которые ей приписывали в статье по итогам VulnCon ("story behind it, it is long, convoluted and very administrivia" и т.п.) я не нашёл. Искал по автоматическим субтитрам. Ну, может это было сказано не на панельке, а где-то ещё. 🤷♂️
@avleonovrus #VULNCON24 #NVD #NIST
Уточнил у автора статьи откуда именно были цитаты Tanya Brewer из NIST. Она это говорила в сессии "NVD Symposium". Эта сессия есть в программе, но её запись в канал VulnCon 2024 НЕ выложили, несмотря на "TLP:CLEAR". Такие дела. 😏
@avleonovrus #VULNCON24 #NVD #NIST #thoseamericans
@avleonovrus #VULNCON24 #NVD #NIST #thoseamericans
25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся. В январе 1999 года Дэвид Э. Манн и Стивен М. Кристи опубликовали статью "К единому перечислению уязвимостей" ("Towards a Common Enumeration of Vulnerabilities"), в которой предлагалось создать лист Common Vulnerability Enumeration, CVE (заметьте, в оригинале никаких "экспозиций" 😉), целью которого было бы:
🔻 нумеровать и различать все известные уязвимости
🔻 назначать стандартное уникальное имя каждой уязвимости
🔻 существовать независимо от множественных точек зрения на то, что такое уязвимость
🔻 являться публично "открытым", распространяемым без ограничений
В октябре 1999 года корпорация MITRE представила первый CVE лист, в котором была 321 запись. За 25 лет их количество перевалило за 250 000 идентификаторов (без Rejected). Количество новых CVE каждый год ставит рекорды, в этом году ожидается больше 35 000. В основном такой бешеный прирост обеспечивают организации со статусом CNA, которых уже 221. Они, получив заветный статус, могут заводить CVE на любую дичь. Хоть весь свой багтреккер пихать, как Linux Kernel. 😏
Во многом из-за такого прироста (ну и из-за приколов американской бюрократии) процесс по анализу уязвимостей в NIST NVD в 2024 году дал масштабный сбой, фактически остановился. Несмотря на все меры (включая финансовые), он так толком и не восстановился. NVD месяц от месяца анализирует значительно меньше CVE, чем получает от CVEorg. Бэклог на анализ растёт, и составляет 19 174 CVE. 🫣
Не такая беда, что база замусорена и не анализируется в должной степени. Настоящая беда в том, что она при этом ещё и неполна. Серьёзные уязвимости, обнаруженные российскими или китайскими исследователями могут не приниматься из-за каких-то геополитических соображений и они фиксируются только в национальных базах уязвимостей. 🤷♂️
Вот такой итог 25 лет. Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону. В котором приходится всем миром копаться, потому что ничего лучше всё равно нет. 🙄 Круто, чё. С юбилеем!
@avleonovrus #CVE #CVEorg #MITRE #NVD #NIST
🔻 нумеровать и различать все известные уязвимости
🔻 назначать стандартное уникальное имя каждой уязвимости
🔻 существовать независимо от множественных точек зрения на то, что такое уязвимость
🔻 являться публично "открытым", распространяемым без ограничений
В октябре 1999 года корпорация MITRE представила первый CVE лист, в котором была 321 запись. За 25 лет их количество перевалило за 250 000 идентификаторов (без Rejected). Количество новых CVE каждый год ставит рекорды, в этом году ожидается больше 35 000. В основном такой бешеный прирост обеспечивают организации со статусом CNA, которых уже 221. Они, получив заветный статус, могут заводить CVE на любую дичь. Хоть весь свой багтреккер пихать, как Linux Kernel. 😏
Во многом из-за такого прироста (ну и из-за приколов американской бюрократии) процесс по анализу уязвимостей в NIST NVD в 2024 году дал масштабный сбой, фактически остановился. Несмотря на все меры (включая финансовые), он так толком и не восстановился. NVD месяц от месяца анализирует значительно меньше CVE, чем получает от CVEorg. Бэклог на анализ растёт, и составляет 19 174 CVE. 🫣
Не такая беда, что база замусорена и не анализируется в должной степени. Настоящая беда в том, что она при этом ещё и неполна. Серьёзные уязвимости, обнаруженные российскими или китайскими исследователями могут не приниматься из-за каких-то геополитических соображений и они фиксируются только в национальных базах уязвимостей. 🤷♂️
Вот такой итог 25 лет. Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону. В котором приходится всем миром копаться, потому что ничего лучше всё равно нет. 🙄 Круто, чё. С юбилеем!
@avleonovrus #CVE #CVEorg #MITRE #NVD #NIST