Как будем описывать активы в Vul­re­mi? Основная идея, что это должен быть настолько гибкий формат, чтобы в него можно было разложить результаты детектирования уязвимостей из любого решения: коммерческого, опенсурсного, агентного, безагентного. Вообще любого. Поэтому задачу досконально описывать конфигурацию актива сознательно отбрасываем. Берём только то, что понадобится нам в приоритизации уязвимостей (с учётом активов) и их исправлении.

{
    "asset_id": "important-host1",
    "owner": "marketing_department",
    "patching_engineer": "johnsmith1",
    "patching_rule": "once in a month",
    "asset_value": "key",
    "asset_type": "server",
    "perimeter": false,
    "last_scan": "2024-02-06T21:07:27+00:00",
    "vulnerabilities":
    [
        {
            "vulnerability_id": "CVE-2024-00001",
            "cvss_v3_env": "CR:L/IR:M/AR:M/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:L/MI:L/MA:L",
            "related_objects":
            [
                {
                    "object_type": "ubuntu_package",
                    "name": "anacron",
                    "version": "2.3-38ubuntu1"
                }
            ]
        }
    ]
}

Параметры для описания самого актива

🔹 asset_id — идентификатор актива. Логично было бы использовать для него host­name, но ситуации бывают разные, поэтому не конкретизирую. Возможно это будет id из CMDB-шки.
🔹 own­er — ответственный за актив, с которым можно договариваться о регулярных и экстренных обновлениях актива. Обычно какое-то бизнесовое подразделение.
🔹 patching_engineer — тот, кто непосредственно должен обновлять активы. С него нужно спрашивать, если договоренности по регулярным или экстренным обновлениям нарушаются.
🔹 patching_rule — правило регулярного обновления, которое было согласовано с овнером. Если оно нарушается, то спрашиваем с patching_engineer.
🔹 asset_value — ценность актива для злоумышленника. Если, получив доступ к активу, злоумышленник может непосредственно реализовать недопустимое событие, то значит актив целевой (tar­get). Если, получив доступ к активу, злоумышленник может развить атаку на целевой актив, то значит актив ключевой (key). Если и не ключевой, и не целевой, то обычный (ordi­nary).
🔹 asset_type — тип актива. Crit­i­cal Infra­struc­ture, Serv­er, Net­work Equip­ment, Desk­top, Oth­er. Ровно как в методике оценки уровня критичности уязвимости ФСТЭК, примеряемся к использованию. 😏
🔹 perime­ter — влияет ли состояние актива на безопасность периметра. Тоже как в методике ФСТЭК.
🔹 last_scan — когда этот актив сканировали на уязвимости в последний раз. Чтобы понимать насколько у нас информация по уязвимостям актуальная. Если нашли активы со старой датой — идём разбираться со сканами.

Параметры для описания уязвимостей на активе

🔸 vulnerability_id — идентификатор уязвимости. CVE. Если нет CVE, то BDU. Если и его нет, то любой уникальный идентификатор уязвимости. По этому идентификатору найдем описание этой уязвимости в объекте типа vul­ner­a­bil­i­ty, который я буду описывать позже.
🔸 cvss_v3_env — envi­ron­men­tal часть CVSS вектора на случай, если мы захотим поманипулировать через него критичностью уязвимости для данного актива.
🔸 related_objects — объекты актива, связанные с уязвимостью. Опциональная штука, которая может быть использована patch­ing_en­gi­neer-ом для того, чтобы понять на что ругается сканер. Если в связанных объектах линуксовый пакет, значит его нужно обновлять и всё будет ок. С другой стороны, там может быть описан не только пакет, но и, например, софт. В этом случае можно будет накрутить логику учёта российский он или нет, а следовательно решать требуется ли тестирование безопасности обновления или не требуется. Но подробнее эту штуку буду расписывать позже, уже после MVP.