Сonduct initial ml-experiments

[wisoffe]

Brief conclusions and notes (EN)

Results and conclusions:

1. The following models/frameworks were tested (the selection of hyperparameters at this stage was not carried out, the goal is the initial assessment):
   • fast.ai - tabular_learner
   • fast.ai - tabular_learner only continous + assigner
   • fast.ai - text_classifier_learner
   • fast.ai - text_classifier_learner + tabular_learner -xgboost -catboost
   • transformers (distillbert) - description only (weighted/not weighted loss)
   • (2nd place) transformers (distillbert) - with added in description feautures (weighted/not weighted loss)
   • (1st place) - auto.gluon.ai
2. Favorites are transformers and autogluon; autogluon shows slightly higher quality; but taking into account the fact that the minimum size and simple distillbert model was chosen for transformers, parameters, features, etc. were not selected, it makes sense to consider transformers for the baseline first of all; further conduct more detailed experiments and try to beat the quality of autogluon.
3. The analysis showed a very poor correlation of the target variable (i.e. exploit released / not released) with CVSS scores (baseScore, exploitabilityScore, impactScore), i.e. focusing in patching only on scores or kicks, or simple rules for scores (for example, close CVE baseScore > 8 (high) first of all), is inefficient. As a result, the usefulness and practical applicability of the predictions of our model will increase significantly -> a benchmark for the priority closure of vulnerabilities for which predictions will be given about the release of the exploit in the next 3 months.
4. Target metrics:
   • Basic:
     • Decided to prioritize ROC AUC as the main metric as the most stable indicator. According to the description, the AP AUC metric would be suitable for us, but it showed significant instability of the results when the distribution of positive / negative classes changes (for example, if you simply increase / decrease the number of real negative or positive examples, then AP AUC changes very significantly, and ROC AUC remains unchanged, or changes slightly), in fact, nothing has changed, the model is the same, the examples are the same, only the distribution of classes has changed, i.e. the metric should show stability in this case.
   • Additional (may require additional analysis):
     • it makes sense to consider the precision metric for a given recall threshold (seeing 70% or 75%), but perhaps it will be as unstable as AP AUC
     • ROC AUC in the recall interval > 70 would probably be a better indicator than the full ROC AUC (because a high Recall is very important for us)
     • TODO: it makes sense in the future to research the MCC (Matthews correlation coefficient) metric, it is recommended for class imbalance - https://towardsdatascience.com/the-best-classification-metric-youve-never-heard-of-the-matthews- correlation-coefficient-3bf50a2f3e9a
5. The following set of target artifacts / predictions of the model is seen (based on real practicality):
   • binary prediction 1/0 - will the exploit be released in the next 3 months or not; it is necessary to carry out this prediction for the threshold corresponding to the indicator recall = 70% or 75% (this is important, because in our case, the emphasis is on preventive measures to close vulnerabilities with a margin)
   • confidence rate of the model (confidence), scaled to the range from 0.0 to 10.0 (it is necessary that it should not be confused with probability); it's ok if the model is overconfidence (gently aim for this, within reason)
   • perhaps, an additional artifact will be a close to the real probability distribution , i.e. initial scores calibrated to probabilities given by the model; Initially, I intended to use the probability prediction as the main artifact, but for the quality achievable in reality, it turns out that in order to achieve a recall of 70%? it will be necessary to take into account vulnerabilities with a probability of more than 10-20%, which psychologically looks like a very low indicator (as a result, the real threat of many vulnerabilities will be underestimated); result - most likely it will be necessary to add additional. artifact, but without emphasis.
6. Decided to use a range of 90 days from the date of publication of the CVE, instead of 60, as was the case before.

Important Notes:

1. Experiments have shown that the model can only make good predictions based on the CVE text description, which is published the very first, even before the calculation/publication of CVSS vectors (maybe it would make sense in the future to perform several stages of prediction, the first stage - only on the basis of the description, then revised as additional data becomes available)
2. There is a strange difference in quality between the Random Validation Set and the Validation Set for the last 10 months (which is more true for our case), with the second case being a few points better
3. High recall (with acceptable precision) is more important for us. it is better to close a little more vulnerabilities, skipping the minimum number of those for which exploits will be released
4. The results of the recheck, by what criterion do we count 90 days; if from the date of publication, is this date of publication not the date of publication of the naked candidate (i.e., simply the reservation of the CVE number); be sure to check this for the current dataset (which is used in this laptop), the data is obtained from NVD, and check in the future with the data that I am going to receive from vulners.com; if I really count from the candidate's publication, then this is a big mistake, requiring a revision of the entire current study:
   • I figured out that for the current laptop everything is considered correct for me, on nvd / mitre there is a clear division into Date Record Created (Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE) and NVD Published Date; I use exactly Published Date;
   • with vulners.com, you need to be careful, because CVE candidates are published there (the distinguished field is reporter:"candidate"), and for that candidate there is a "published" field, which for the candidate corresponds to Date Record Create; subsequently, when the CVE is actually published, the value of this same field is changed to the corresponding NVD Published Date;
   • it will be necessary to double-check this information in the future, to make sure that there is no delay in changing this field, in addition, it is very important not to enter data on candidates into the database until the CVE is published, or to change the value of the published field accordingly when the CVE is on actually published.

Challenges for the future:

1. TODO: It is necessary to analyze the feasibility / necessity of adding to the positive class:
   • Vulnerabilities from the catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog (2023.02.09 contains 875 entries)
   • proof-of-concept (PoC) for CVE; on vulners.com met this category in some selections (TODO: find where it was) ; other than this TODO: explore https://github.com/trickest/cve
   • json from vulners.com has enchantments.exploitation.wildExploited:true field (TODO: find out what it means and consider adding it)

[wisoffe]

Краткие выводы и примечания (RU)

Итоги и выводы:

1. Были проестированы следующие модели/фреймворки (подбор гиперпараметров на данном этампе не проводился, цель - первичная оценка):
   • fast.ai - tabular_learner
   • fast.ai - tabular_learner only continous + assigner
   • fast.ai - text_classifier_learner
   • fast.ai - text_classifier_learner + tabular_learner
   • xgboost
   • catboost
   • transformers (distillbert) - description only (weighted/not weighted loss)
   • (2 место) transformers (distillbert) - with added in description feautures (weighted/not weighted loss)
   • (1 место) - auto.gluon.ai
2. Фаворитами являются transformers и autogluon; autogluon показывает чуть более высокое качество; но с учетом того, что для transformers была выбрана минимальная по размеру и простая модель distillbert, не подбирались параметры, фичи и т.д., имеет смысл в первую очередь для бейзлайна рассмотреть transformers; далее провести более детальные эксперименты и постараться побить качество autogluon.
3. Анализ показал очень плохую корреляцию целевой переменной (т.е. выйден/не выйдет эксплоит) со скорами CVSS (baseScore, exploitabilityScore, impactScore), т.е. ориентироваться в патчинге только на скоры или кикие либо простые правила по скорам (например в первую очередь закрывать CVE baseScore > 8 (high)), является неэффективным. Как следствие, существенно возростает польза и практическая применимость предсказаний нашей модели -> ориентир на первоочередное закрытие уязвимостей, для которых будут даны предсказания о выходе эксплойта в ближайшие 3 месяца.
4. Целевые метрики:
   • Основные:
     • Решено в качестве основной метрики в первую очередь оринтироваться на ROC AUC, как наиболее стабильный показатель. По описанию, нам подходила бы метрика AP AUC, но она показала существенную нестабильность результатов при изменении распределения положительных/отрицательных классов (например, если для просто увеличить/уменишить количество реальних отрицательных или положительны примеров, то AP AUC изменяется очень существенно, а ROC AUC остается неизменным, либо меняется незначительно), по факту у нас ничего не изменилось, модель та же, примеры те же, изменилось только распределение классов, т.е. метрика должна показывать стабильность в данном случае.
   • Дополнительные (возможно, требуется дополнительный анализ):
     • имеет смысл рассмотреть метрику precision для заданного порога recall (видится 70% или 75%), но возможно она будет так же нестабильна, как AP AUC
     • ROC AUC на промежутке recall > 70 возможно было бы лучшим показателем, чем поный ROC AUC (т.к. для нас высокий Recall очень важен)
     • TODO: имеет смысл в будущем исследовать метрику MCC (Matthews correlation coefficient), ее рекомендуют для дисбаланса классов - https://towardsdatascience.com/the-best-classification-metric-youve-never-heard-of-the-matthews-correlation-coefficient-3bf50a2f3e9a
5. Видится следующий набор целевых артефактов/предсказаний модели (исходя из реальной практичности):
   • бинарное предсказание 1/0 - выйдет эксплоит в ближайшие 3 месяца или нет; необходимо проводить данное предсказание для threshold, соответсвующей показателю recall = 70% или 75% (это важно, т.к. в нашем случае акцент на превентивные меры по закрытию уязвимостей с запасом)
   • скор уверенности модели (confidence), масштабированный до диапазона от 0.0 до 10.0 (необходимо, что бы его не путали с вероятностью); это нормально, если модель будет overconfidence (нежно стремиться к этому, в разумных пределах)
   • возможно, дополнительным артефактом будет близкое к реальному распределение вероятностей, т.е. откалиброванные до вероятностей изначальные скоры, выдаваемые моделью; первоначально, я предполагал использовать в качестве основного артефакта именно предсказание вореятностей, но для достижимого в реальности качества, оказывается, что для достижения recall 70%? необходимо будет брать в работу уязвимости с вероятностью более 10-20%, что психологически выглядит как очень низкий показатель (как следствие реальная угроза многих уязвимостей, будет принижаться); итог - скорей всего нужно будет добавть доп. артефактом, но без акцентирования внимания.
6. Решено использовать диапазон 90 дней с момента публикации CVE, вместо 60, как было ранее.

Важные примечания:

1. Эксперименты показали, что модель может выдавать хорошие предсказания только по текстовому описанию CVE, которое публикуется самым первым, еще до расчета/публикации векторов CVSS (возможно имеело бы смысл в будущем производить несколько этапов прогнозирования, первый этап - только на основе описания, далее пересмотр по мере получения доп. данных)
2. Наблюдается странная разница в качестве на рандомной валидационной выборке и валидационной выборке за последние 10 месяцев (что является более верным для нашего случая), причем во втором случае качество предсказаний выше на несколько пунктов
3. Для нас более важен высокий recall (при приемлемом precision), т.к. лучше закрыть чуть больше уязвимостей, пропустив минимальное количество тех, для которых выпустят эксплойты
4. Результаты перепроверки, по какому критерию мы отсчитываем 90 дней; если от даты публикации, то не является ли эта дата публикации, датой публикации голого кандидата (т.е. просто резервирования номера CVE); обязательно это проверить для текущего датасета (котрый применяется в этом ноутбуке), данные получены из NVD, и сверить в будущем с данными, которые я собираюсь получать с vulners.com; если я действительно считаю с публикации кандидата, то это большая ошибка, требующая пересмотра всего текущего исследования:
   • разобрался, для текущего ноутбука у меня считается все верно, на nvd/mitre есть четкое разделение на Date Record Created (Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE) и NVD Published Date; я использую именно Published Date;
   • с vulners.com, необходимо быть осторожней, т.к. там публикуются кандидаты CVE (отличительное поле - reporter:"candidate"), и для этого кандидата присутсвует поле "published", которое для кандидата соответсвует Date Record Create; в последствии, когда CVE на самом деле публикуется, значение этого же самого поля меняется на соответсвующее NVD Published Date;
   • необходимо будет в будущем перепроверить эту информацию, убедиться, что нет задержки в изменении данного поля, кроме того, очень важно, не заносить данные по кандидатам себе в базу до момента публикации CVE, либо же менять соответсвующим образом значение поля published, когда CVE на самом деле публикуется.

Задачи на будущее:

1. TODO: Необходимо проанализировать целесообразность/необходимость добавления в положительный класс:
   1. уязвимостей из каталога https://www.cisa.gov/known-exploited-vulnerabilities-catalog (на 2023.02.09 содержит 875 entries)
   2. proof-of-concept (PoC) для CVE; на vulners.com встречал данную категорию в каких то выборках (TODO: найти где это было) ; кроме этого TODO: изучить https://github.com/trickest/cve
   3. в json от vulners.com присутсвует поле enchantments.exploitation.wildExploited:true (TODO: выяснить что оно значит и рассмотреть добавление)