А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек? 😏
Поигрался немножко с новой версией @kandinsky21_bot от Сбера. Местами неплохо генерит. 🙂
Проект руководства по Vulnerability Management от ФСТЭК. Уже в паблике. 26 страниц. (upd. после окончания сбора отзывов первоначальная ссылка перестала работать)
Что вас ждет внутри:
1. Общая схема VM-процесса и его связи с другими ИБ процессами организации
2. Перечень участников процесса и выполняемых ими операций
3. Подробное описание 5 этапов процесса, их схемы, описания операций:
3.1. Мониторинг уязвимостей и оценка их применимости
3.2. Оценка уязвимостей
3.3. Определение методов и приоритетов устранения
3.4. Устранение уязвимостей
3.5. Контроль устранения уязвимостей
Вещь абсолютно монументальная. Без шуток. Ничего более детализированного на тему VM-а я ещё не видел.
А вот будет ли это работать на практике? Зависит от нас и от наших правок:
"ФСТЭК России предлагает специалистам в области защиты информации заинтересованных государственных органов власти, организаций, субъектов критической информационной инфраструктуры рассмотреть проект методического документа и направить предложения по доработке указанного документа в соответствии с прилагаемой формой на адрес электронной почты otd22@fstec.ru.
Предложения и замечания по проекту методического документа принимаются до 17 апреля 2023 г."
Давайте все ознакомимся и дадим полезную обратную связь. Нам потом с этим жить и свои VM-процессы в соответствии с этими рекомендациями выстраивать.
upd. Мои посты-комментарии:
1. Читая проект руководства по Vulnerability Management от ФСТЭК. Процесс не для человеков.
2. О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями.
Обзор рынка Vulnerability Management систем от Anti-Malware: велика ли разница между "обычным сканером" и "VM-решением"? Обзор вышел 27 января. Я естественно побежал его читать, так как и сам занимаюсь похожей темой.
Основное, что бросилось в глаза: а почему такой скромный набор решений?
Российские
Positive Technologies MaxPatrol VM
Фродекс VulnsIO VM
Зарубежные
Qualys VMDR
Tenable SC
Rapid7 Insight VM
Holm Security
Конечно, все эти решения могут быть в таком обзоре. Но почему только они? Почему среди российских нет АЛТЭКС-СОФТ RedCheck или НПО "Эшелон" Сканер-ВС. А среди зарубежных нет Greenbone GVM, SecPod SanerNow, Outpost24. Дело тут похоже в следующем. В 2020 на Anti-Malware вышел аналогичный обзор "Сканеры уязвимостей — обзор мирового и российского рынков". Значительная часть решений, которых нет в отчете по VM, есть в отчете по сканерам уязвимостей:
Российские
Positive Technologies MaxPatrol 8
Positive Technologies XSpider
АЛТЭКС-СОФТ RedCheck
АЛТЭКС-СОФТ/ФСТЭК ScanOVAL
НПО "Эшелон" Сканер-ВС
Профиль Защиты "Ревизор сети"
Зарубежные
Qualys Vulnerability Management
Tenable Nessus Professional
Tenable IO
Rapid7 Nexpose Vulnerability Scanner
F-Secure Radar
GFI LanGuard
Tripwire IP360
Skybox Vulnerability Control
Можно предположить, что раз продукты уже отнесли к сканерам, то в отчет по VM-решениям их решили не брать. Это последовательная позиция. Почему бы нет, хозяин-барин.
Но насколько такое разделение вообще оправдано?
В обзоре читаем:
"Резкий рост количества выявляемых брешей, необходимость их приоритизации и контроля за их устранением привели к появлению нового класса продуктов — VM (Vulnerability Management). Подобные комплексы не только имеют в своём составе сканер уязвимостей, но также позволяют расставлять приоритеты при устранении изъянов в зависимости от выбранных параметров и контролировать этот процесс в дальнейшем."
Ок, допустим есть такой параметр связанный с уязвимостью - CVSS (векторы и скоры). Любое решение для детектирования уязвимостей их показывает (ведь подтянуть их из NVD/БДУ тривиально) и чуть менее чем любое позволяет по ним фильтровать прямо в интерфейсе. При таком подходе любой сканер это VM-решение. Разве нет? 😉
Я, конечно, понимаю о чем тут речь. Об общем дашбордике со статистикой по уязвимостям и активам. Ну да, когда продукт может не только сканы отображать, но и как-то общую картину из них собирает это прикольно. Особенно если с динамикой. Но по сравнению с огромной проблемой именно детектирования уязвимостей это все сущая мелочь. Ну допустим нет дашбордика, выгрузите результаты и нарисуйте какие хотите дашборды в любой платформе для аналитики (ELK, Grafana, Splunk, Tableau). Или просто в специализированное решение экспортните (Faraday, Kenna), там автоматом всё разберется. Просто скриптиками попарсите наконец. Тем более это практически неизбежно в ситуации, когда ни одно решение не может покрыть детектами всю инфраструктуру целиком, придется как-то соотносить уязвимости из разных источников.
Обращать столько внимание на второстепенные функции типа дашбордов и интерфейса для приоритизации это все равно что при обсуждении автомобилей обращать внимания только на дворники. Делить все автомобили на те, у которых есть бескаркасные стеклоочистители и те, у которых их нет. Ну да, дворники это прикольно и важно. Дворники какие-то должны быть. И лучше чтобы они были хорошие, надежные. Но дворники же не должны быть определяющим фактором при оценке и выборе автомобиля! Если машина не ездит толком, то какая разница какие у неё там дворники. 🙃
В общем, моё имхо, что от чисто маркетингового разделения "обычный сканер уязвимостей" и "VM-решение" стоит уходить и рассматривать всё в рамках единого класса, например "Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)". А при сравнении прежде всего обращать внимание на базовую функциональность - детектирование уязвимостей. А дополнительной функциональности уделять время соразмерно её важности.
Vulnerability Management решения и Zero Day уязвимости (1/3)
В моем англоязычном телеграмм-чате @avleonovchat задали вопрос: "Как найти 0day уязвимости с помощью Qualys?" Видимо этот вопрос можно расширить. Не только с помощью Qualys, а вообще с помощью любого VM-решения. И возможно ли это сделать вообще? Там завязалась довольно интересная дискуссия.
Вопрос не такой однозначный. Чтобы ответить на него, следует определиться что такое Zero Day уязвимость. Если мы посмотрим википедию, то исторически "0" это количество дней, которое есть у вендора на фикс уязвимости.
"Eventually the term was applied to the vulnerabilities that allowed this hacking, and to the number of days that the vendor has had to fix them."
Иллюстрация сгенерирована Stable Diffusion 2.1: "calendar on the wall cyber security vulnerability zero day"
Vulnerability Management решения и Zero Day уязвимости (2/3)
Если несознательный исследователь опубликует полный ресерч по уязвимости, вообще не информируя вендора, т.е. сразу сделает full disclosure, это будет классический Zero Day. Тут вопросов нет. Но есть тонкости:
➡️ Является такая уязвимость Zero Day до момента публичного раскрытия?
➡️ Если сознательный исследователь информирует вендора, является ли уязвимость Zero Day от момента обнаружения её исследователем до момента передачи данных о ней вендору и во время разработки патча вендором?
➡️ Если уязвимость была Zero Day, то после выхода патча вендором, корректно ли продолжать называть такую уязвимость Zero Day?
Есть разные мнения и определения:
1. Trendmicro: "A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched".
2. Kaspersky: "A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it."
3. Portswigger: "A zero-day (0day) vulnerability refers to a security vulnerability for which no mitigation or patch is available at the time it is disclosed or made public".
4. ScienceDirect: "Zero-day vulnerability is defined as a security flaw that has not yet been disclosed to the vendor or developers".
Как видим, согласно некоторым определениям раскрытие информации (disclosure) требуется для отнесения уязвимости к Zero Day, а согласно другим вроде как и нет.
В глоссарии NIST нет понятия "zero day vulnerability".
В глоссарии ФСТЭК Уязвимость нулевого дня (Zero-day vulnerability) это "уязвимость, которая становится известной до момента выпуска разработчиком программного обеспечения информационной системы мер защиты информации по ее устранению, исправлений ошибок или соответствующих обновлений". Тут тоже не вполне понятно "становится известной" широкому кругу лиц или вообще, даже одному исследователю?
Лично мне НЕ нравится идея называть уязвимость Zero Day только в момент её опубликования. Почему? Если мы определяем таким образов, то в случае тайного зловредного использования уязвимости (например #Eternalblue до утечки из NSA) мы не можем сказать что это было использование Zero Day уязвимости. Публикации же (пока) не было! Хотя очевидно это было именно использование Zero Day уязвимости.
Ок, можем подкрутить и говорить, что нужно либо опубликование, либо использование. И какое использование? Вот есть исследователь, нашедший уязвимость. В ходе ресерча он эту уязвимость явно как-то использовал / тестировал на чем-то. Получается нужно не простое использование, а зловредное. А как определить зловредность? Это тоже добавляет неразберихи.
Поэтому мне кажется, что проще и непротиворечивее считать за Zero Day вообще любую уязвимость до момента появления фикса от вендора (патч или workaround). После публикации фикса называть уязвимость Zero Day оправдано только если мы говорим о каких-то прошедших событиях, когда фикса ещё не было.
Vulnerability Management решения и Zero Day уязвимости (3/3)
Если мы условимся трактовать Zero Day уязвимости так широко, то можем рассмотреть такие их виды:
1. Публичные уязвимостей, для которых в момент публикации не было патча от вендора ПО (например, #ProxyNotShell). Такие уязвимости Vulnerability Management решения могут иногда детектировать. НО VM вендор должен приложить к этому дополнительные усилия. Большая часть правил детекта уязвимостей работают за счет проверки установки патчей или проверки версий ПО/пакетов. Раз обновления устраняющего уязвимость пока нет, значит требуется детектировать как-то иначе. Например попытаться проэксплуатировать уязвимость. Разработка таких правил это ручная работа, требующая больших усилий.
2. Непубличные уязвимости, о которых кто-то знает и возможно использует, но о которых не знает вендор ПО (например, #EternalBlue до утечки из NSA). Такие уязвимости вероятно могут находиться в некоторых непубличных базах уязвимостей. Обнаружить такие уязвимости при помощи VM решения невозможно. С обнаружением эксплуатации таких уязвимостей в какой-то степени могут помочь EDR решения и практики SOC.
3. Непубличные уязвимости, о которых вообще никто не знает. VM решение также не сможет продетектировать такие уязвимости. Это уже из области исследования ПО и SAST/DAST/IAST решений.
Так могут ли VM решения детектировать Zero Day уязвимости? Да, могут детектировать определенные Zero Day уязвимости в некоторых исключительных случаях. Это будет обычное сканирование на уязвимости и затем фильтрация по признаку "у уязвимости нет патча". Но обнаруженные таким образу уязвимости будут лишь малой частью от всех Zero Day уязвимостей (в том смысле как мы их определили выше). VM решения заточены на работу с известными уязвимости для которых вендором уже выпущены патчи. Именно такие уязвимости (а не Zero Day!) обычно и являются основной причиной взлома компаний. Zero Day уязвимости применяются все же довольно редко и в основном в таргетированных атаках.
Тут добавил комментарии на русском из черновиков и тайминг. Все в дело 😊 https://youtu.be/jgKK9ovlNFU
Active Vulnerabilities
01:31 🔴 “CISA warns of hackers exploiting PwnKit Linux vulnerability (CVE-2021-4034)” by BleepingComputer
// Не только американцам это нужно быстро патчить.
03:14 🔴 “Atlassian Confluence OGNL Injection Remote Code Execution (RCE) Vulnerability (CVE-2022-26134)” by Qualys
// В статье Qualys приводят описание OGNL Injection, RCE Payload, Exploit POC, Exploit Analysis и Source Code Analysis. Это подробная техническая статья. Если вам интересно как такие уязвимости эксплуатируются и детектируются, посмотрите этот пост.
Data sources
05:27 🟠 “New Vulnerability Database Catalogs Cloud Security Issues” by DarkReading & Wiz
// Непонятно насколько действительно нужна отдельная база данных. Кажется это все можно было бы оформить как CVEs. Тем более, что у многих уязвимостях в этой базе уже есть CVE IDs. Но инициатива хорошая. Лишний раз доказывает, что у MITRE и NVD есть проблемы.
Analytics
07:23 🟢 “MITRE shares this year’s list of most dangerous software bugs (CWE Top 25)” by BleepingComputer
// Похоже на правду, хотя 'OS Command Injection' кажется должно быть выше. Ну и надо понимать, что CWE идентификаторы присваюваются уязвимости вручную и поэтому тут могут быть ошибки классификации. Но все равно любопытно.
09:06 🟠 “Cyberattacks via Unpatched Systems Cost Orgs More Than Phishing” by DarkReading & Tetra Defense
// Хорошее замечание в статье: "Data on successful compromises can help companies determine the most critical attack vectors to address, but it should be noted that the conclusions depend greatly on the specific incident-response firm". Но то, что MFA и патчинг это важно - не поспоришь.
11:07 🔴 “Zero-Days Aren’t Going Away Anytime Soon & What Leaders Need to Know” by DarkReading & Arctic Wolf
// Ну, в целом не попоришь. Моё мнение - пока критичные известные уязвимости на исправляются оперативно, думать о Zero-Days преждевременно. А так, это конечно в первую очередь задача SOC.
VM vendors write about Vulnerability Management
13:57 🟡 “Why We’re Getting Vulnerability Management Wrong” by DarkReading & Rezilion
// Это давнишний спор: стоит ли исправлять уязвимости в софте, который в настоящий момент не запущен? Ну и обычно на это отвечают да. Потому что никто не может гарантировать, что софт вдруг не начнет запускаться. Но если будет возможность выделить среди критичных уязвимостей уязвимости, в софте, который уже запущен или регулярно запускается, то это хороший испточник данных для дополнительной приоритизации. Почему бы и нет. Хорошо, что Rezilion это подсвечивают.
16:41 🔴 “Risk-based Remediation Powered by Patch Management in Qualys VMDR 2.0” by Qualys
// На самом деле давно было интересно что же нового в Qualys Vulnerability Management, Detection and Response. В целом, это похоже на Tenable vulnerability priority rating (VPR). Наверное и формируется примерно так же. Но про техническое подробности TruRisk надо будет искать где-то в другом месте. Я согласен с тем, что фокус VM должен быть именно на Remediation и хорошо, что Qualys продвигают эту тему. Достаточен ли объем новых фич, чтобы называть это VMDR 2.0? Пока это не кажется так. Кажется, что если бы Remediation был полностью автоматизирован для 100% хостов (что требует принципиально другого подхода к тестированию работоспособности после патча), то тогда это было бы 2.0. Но маркетологам Qualys виднее.
20:37 🟢 “Modern IT Security Teams’ Inevitable Need for Advanced Vulnerability Management” by Threatpost & Secpod
// Дается список проблем и для преодаления этих проблем нужен Advanced Vulnerability Management от Secpod. В целом, список справедливый и то, что они обращают внимание на vulnerabilities beyond CVEs кажется мне очень правильным.
22:25 de-Westernization of IT
см.выше https://avleonov.ru/2022/07/03/3-rabotaju-nad-obzorom-vulnerability-management-novo/