Провести первичный EDA анализ данных, набросать простую модель (например fast.ai), оценить грубо качество модели (на основе метрик), определиться с основными источниками информации по CVE/Exploits

[wisoffe]

Основные моменты/примечания:

• Провести анализ в ноутбуке
• Первая модель скорей всето на табличном лернере fast.ai
• Метрики скорей всего Precision/Recall/F1/Accuracy (возможно ROC)

По итогу, определиться с:

• [x] Источник данных по CVE (исторических и непрерывно пополняемых)
• [x] Источник данных по Exploits (исторических и непрерывно пополняемых)
• [x] Чуть более глубоко понять трудоемкость задачи в части получения удовлетворяющего требованиям качества предсказаний
• [x] Определиться с вопросоми дообновления данных по CVE (т.е. после первичной публикации), что с ними делать, необходимо ли в рамках бейзлайна заморачиваться на сбор исторических данных в том виде, в котором они были изначально опубликованы, либо выбранный первоначальный набор фичей практически стабилен с момента публикации и т.д.
• [x] Определиться с использованием/не использованием информации из "Каталога известных эксплуатируемых уязвимостей" Known Exploited Vulnerabilities Catalog
• [x] Определить кол-во последних лет, которые включаем в первичную выборку (предположительно информация более 5 летней давности может не соответсвовать текущим тенденциям/паттернам по выходу эксплоитов)
• [x] Определить минимальными требованиями к ML бейзлайну (по сути MVP)

[wisoffe]

Краткие итоги (в разрезе доступности фичей по версиям CVSS):

• массовое применение CVSS V3 началось с 2016 года, 100% покрытие CVSS V3 имеем с марта 2016 года
• с марта 2016 года по 2021 год (включительно) мы имеем 100% покрытие и V2 и V3
• c июля 2022 мы наблюдаем существенное снижение наличия CVSS V2 (это может означать: что V2 вообще перестали вычислять для многих CVE, либо же что вычисление V2 происходит с существенным запозданием в сравнении с V3; т.к. нам необходимо руководствоваться информацией на момент публикации, оба случая для нас равнозначны и означают, что более руководствоваться CVSS V2 нам нецелесообразно)
• принятые решения:
  • использовать фичи CVSS V2 нецелесообразно (т.к. мы получим модель, обученную на данных, которые в настоящий момент будут недоступны для большинства CVE)
  • необходимо использовать данный с марта 2016 года (т.к. именно с этого момента мы имеем полное покрытие фичами CVSS V3)

[wisoffe]

Краткие итоги (в разрезе анализа уязвимостей с 2016 года):

• в 64% случаев, эксплоиты вышли раньше, чем были опубликованы сами уязвимости (не ожидали подобного результата, но по факту, в этом есть логика), причем разница может составлять несколько лет; в рамках бейзлайна, принято решение - трактовать подобные случаи как положительные (т.е. эксплоит вышел) и включить их в обучающую выборку;
• по диапазонам, для которых мы планирем предсказывать выход эксплоитов (изначально предполагали использовать 2 диапазона: спустя 1 мес. и спустя 3 мес. после публикации CVE), исходя из результатов выше, в рамках бейзлайна, приняты решения:
  • использование 2-х диапазонов не является целесообразным (особенно в рамках реализации MVP), концентрируемся на единственном выбранном диапазоне;
  • решение - для бейзлайны выбрать между 2 мес. и 3 мес. на основе результатов построения первичной модели и полученных ею метрик (если метрики сопоставимы выберем 2 мес, если метрики 3 мес. будут значимо отличаться в положительную сторону, то 3 мес.)
  • 1 мес. - минусы - в выборке значимая часть данных будет из ситуации пп 1 выше;
  • 2 мес. - приемлемый срок, нет значимых +/-;
  • 3 мес. - плюсы - ~70% перцентиль из всех событий когда эксплоит вышел после публикации CVE, минус - больший срок, после которого мы сможем сделать вывод, что модель предсказала верные/неверные результаты, но с учетом того, что отсчет начнется ретроспективно, это не очень значимый недостаток;

[wisoffe]

Краткие итоги (по факту построения первичной модели от fast.ai):

• наблюдается удивительно слабая корреляция между CVSS exploitabilityScore/impactScore/baseScore и реальным фактом выхода эксплоитов, более того, между соответсвующими параметрами V2 и V3, так же наблюдаются очень существенные различия -> как следсвие, необходимо обязательно расширять целевой набор фичей, первичным видится: эмбеддинги description (полученные например бертом), информация по наименованию продукта и вендора;

• т.к. значимой разницы между предсказаниями в течение 2 мес. и 3 мес. не наблюдается, выбираем целевой диапазон для бейзлайна - 2 мес.

• самые первичные метрики (по сути только на основе векторов CVSS V3, абсолютно без тюнинга): | epoch | train_loss | valid_loss | accuracy | f1_score | precision_score | recall_score | roc_auc_score | time | | 2 | 0.271347 | 0.186833 | 0.950684 | 0.661818 | 0.791304 | 0.568750 | 0.872929 | 00:07 |

• целевое отсечение нам нужно сместить в сторону увеличения recall (т.е. в нашем случае лучше чуть "перебдеть", чем "недобдеть", но precision так же должен оставаться на приемлимом уровне)

[wisoffe]

Источник данных по CVE (исторических и непрерывно пополняемых): В качестве источника информации по уязвимостям выбран ресурс https://nvd.nist.gov/ как наиболее официальный (прямое сотрудничество с cve.mitre.org). Конкретно используем JSON Feeds https://nvd.nist.gov/vuln/data-feeds#JSON_FEED

Источник данных по Exploits (исторических и непрерывно пополняемых): В качестве источника по эксплоитам выбран ресурс vulners.com, который агрегирует информацию по вышедшим эксплоитам (и уязвимостям), в единую NoSQL базу (Elastic), по итогу предоставляет информацию из этой базы на основе платных подписок. У них есть свой API и т.д. Кроме платной подписки, есть возможность воспользоваться триал подпиской (по которой удобно выкачать первоначальную базу), а так же бесплатный доступ к API (достаточно регистрации), в рамках которого наложены существенные ограничения по количеству ежедневных запросов, НО для нашего случая, а именно, периодической дозагрузки данных только по новым эксплоитам, мы укладываемся в лимиты бесплатной подписки. Если бы не укладовались, можно было бы рассмотерть вариант поручения исследовательской подписки, для этого нужно обратиться к авторам ресурса (коллеги русскоговорящие).

Чуть более глубоко понять трудоемкость задачи в части получения удовлетворяющего требованиям качества предсказаний: Выполнено, подробности в комментариях выше (в особенности в "Краткие итоги (по факту построения первичной модели от fast.ai)")

Определиться с вопросоми дообновления данных по CVE (т.е. после первичной публикации), что с ними делать, необходимо ли в рамках бейзлайна заморачиваться на сбор исторических данных в том виде, в котором они были изначально опубликованы, либо выбранный первоначальный набор фичей практически стабилен с момента публикации и т.д.: В рамках бейзлайна используем набор данных, которые в абсолютном большинстве случаев неизменны. Для CVE, у которых на момент публикации отсутствует информация по векторам CVSS V3, не берем их в расчет (т.е. не загоняем в модель), до появления данной информации.

Определиться с использованием/не использованием информации из "Каталога известных эксплуатируемых уязвимостей" Known Exploited Vulnerabilities Catalog: В рамках бейзлайна не используем данную информацию. Основные причины:

• на момент публикации CVE информация о включение в базу в большинстве случаев отсутсвует;
• база за все время насчитывает чуть более 800 CVE (на середину 2022 года), это существенно меньше реального количества эксплоитов, информацию о которых мы получаем из других источников.

Определить кол-во последних лет, которые включаем в первичную выборку (предположительно информация более 5 летней давности может не соответсвовать текущим тенденциям/паттернам по выходу эксплоитов): С марта 2016 года (подробности в комментарии выше "Краткие итоги (в разрезе доступности фичей по версиям CVSS)")

[wisoffe]

Определить минимальными требованиями к ML бейзлайну (по сути MVP)

• фичи:
  • (точно) фичи из CVSS v3 (если на момент публикации CVE - информация отсутсвует, то не берем CVE в работу пока информация не будет добавлена)
  • (точно) эмбеддинги, полученные из description (предположительно из BERT подобной модели, хотя здесь очень вероятно будет достаточно мешка слов, но BERT нужен в больше для опыта; возможно провести в будущем сравнение, но если будет целесообразно по времени)
  • очень желательно иметь фичи по вендору и наименованию продукта (здесь сразу видится 2 варинта: NER-like решение на основе description (на самом деле возможно задача уже решена, имеет смысл погуглить), парсинг полей cpe (но не факт что мы имеем cpe на момент публикации, нужно исследовать) - итого по текущему вопросу отдельная задача в backlog), но в целом, можно вынести за рамки первичного MVP бейзлайна;
• критерий положительного исхода - выход эксплоита не позднее 60 дней с момента публикации CVE
• периодичность дозагрузки данных по CVE/эксплоитам - ежедневно
• класс модели - деревянная модель на основе xgboost или lightgbm (если fast.ai позволяет работать с ними, а возможно так и есть, то допустимо через fast.ai для ускорения процесса)
• хранение версионирование данных - в отдельной задаче бэклога определить требования к хранению данных (какие данные нам необходимо хранить, для каких целей они нам нужны или потенциально будут нужны), по итогу определить инструментарий для хранения (SQL/NoSQL БД, файлы и DVC)
• наилучшим вариантом будет являться хостинг модели на Huggingface Spaces, но необходимо исследование ограничений/возможностей; по итогу ответь на вопросы, возможно ли в таком режиме будет настроить мониторинг метрик, реализовать дообучения и т.п.
• выносим за рамки MVP бейзлайна (это последующие MVP)
  • автоматическое дообучение
  • мониторинг метрик