Какие данные об активах собрать, прежде чем ранжировать уязвимости
Команде ИБ нужно связать обнаруженную уязвимость с системой, за которую отвечает конкретный исполнитель. Пока неизвестно, для чего эта система используется, кто её обслуживает и при каких условиях до неё может добраться атакующий, решение о приоритете опирается на неполные данные.
Актив — учитываемый объект инфраструктуры: например, сервер или виртуальная машина с установленным ПО. Номер CVE обозначает известную уязвимость. Он помогает понять, о какой проблеме идёт речь, но сам по себе не описывает затронутый актив в вашей организации.
Перед ранжированием соберите в карточке актива технические сведения, назначение, ответственного, условия доступа и ограничения обслуживания. Ниже разберём, какие вопросы должна закрывать такая карточка и как обращаться с полями, которые пока не удалось заполнить.
Каких сведений не хватает в списке CVE
Список CVE нужно сопоставить с ПО на конкретных активах. Для каждого обнаружения следует выяснить три вещи: присутствует ли уязвимость в вашей среде, достижимы ли условия её эксплуатации и к каким последствиям она может привести именно здесь.
Эти вопросы требуют разных сведений. Наличие проверяют по данным об установленном ПО и обнаруженной уязвимости. Для оценки достижимости нужны условия сетевого доступа, требования аутентификации и действующие меры защиты. Последствия зависят от назначения системы, обрабатываемых данных и связей с другими активами.
Поэтому запись «уязвимость обнаружена» ещё не даёт полного основания для очереди исправлений. Приоритет и способ выполнения работы также требуют сведений об ответственных и допустимых условиях обслуживания. Если исполнитель неизвестен, задачу некому адресовать; если не учтены ограничения на перезагрузку, выбранное время исправления может оказаться неприемлемым для работы системы.
Технические поля и бизнес-характеристики актива
Минимальная карточка должна позволять перейти от обнаружения к обоснованной задаче. Таблицу можно использовать как перечень вопросов к существующему учёту активов. Названия полей адаптируйте под свою систему, сохранив смысл сведений и связь с решением.
| Поле карточки | Что выяснить | Что нельзя обоснованно решить без этих данных |
|---|---|---|
| Актив и установленное ПО | Какой объект затронут, какое ПО и версия на нём установлены, к чему относится обнаруженный CVE | На каком объекте требуется проверить или устранить уязвимость |
| Назначение и значимость | Какую работу выполняет актив и насколько она важна для организации | Какие последствия для работы организации нужно учитывать при выборе приоритета |
| Данные и связи | Какие данные обрабатывает система, кто или какие сервисы с ней взаимодействуют и с какими правами | Какие последствия эксплуатации возможны с учётом данных и связанных систем |
| Ответственный за администрирование | Кто обслуживает актив; как разделены обязанности, если участвуют несколько сторон | Кому передать задачу и у кого уточнить условия её выполнения |
| Доступ и условия эксплуатации | Откуда доступен уязвимый компонент, требуется ли аутентификация, какие меры защиты действуют | Может ли атакующий достичь условий, необходимых для эксплуатации |
| Ограничения обслуживания | Какие ограничения на обновление и перезагрузку связаны с работой системы, договорами или полномочиями обслуживающей стороны | Как организовать исправление с учётом допустимых условий обслуживания |
Техническое описание и назначение актива дополняют друг друга. Сведения о версии ПО помогают связать обнаружение с объектом. Значимость системы и характер данных нужны для оценки последствий. Нельзя заменить вторую часть карточки перечнем установленных программ, даже если он подробный.
Условия доступа стоит фиксировать вместе с действующими ограничениями. Одной отметки о сетевой доступности недостаточно, чтобы судить о достижимости конкретной уязвимости: значение имеют и требования аутентификации, и защитные меры. При этом наличие защиты само по себе не доказывает, что эксплуатация невозможна. Нужно понимать, какое условие она ограничивает.
Ограничения обслуживания отвечают на отдельный вопрос: как выполнить выбранное действие. Если перезагрузка допустима только в согласованное окно, это следует учитывать при подготовке работ. Такая запись сама по себе не снижает значимость системы и не подтверждает низкий риск.
Как актуализировать данные и выявлять пропуски
Учёт ПО и активов нужно поддерживать постоянно. Без обновлений сведения становятся менее точными и полными, а решения об исправлении продолжают опираться на прежнее состояние инфраструктуры. Перед назначением приоритета проверьте, относятся ли данные карточки к текущему состоянию актива.
Для каждого существенного поля полезно различать подтверждённое значение, неизвестное значение и сведения, которые требуют повторной проверки. Отметка «доступ ограничен» и отсутствие данных о доступе не равнозначны. Во втором случае оснований считать условия эксплуатации недостижимыми пока нет.
Чтобы это различие было видно исполнителю, рядом со спорным полем укажите, что именно известно, откуда получены сведения и что предстоит уточнить. Подтверждение администратора о назначении системы и результат технической проверки могут отвечать на разные вопросы. Сохраняйте в карточке, какой вопрос подтверждает каждое из них.
Полноту инвентаризации нельзя предполагать только потому, что карточки заполнены. Если часть инфраструктуры или свойств актива остаётся неизвестной, обозначьте этот пробел явно. Отсутствие сведений о значимости, доступности или ответственном не служит основанием автоматически отнести актив к низкому риску.
Для первичного разбора возьмите активы, по которым уже предстоит решение, и проверьте карточки по вопросам из таблицы. Незаполненные поля свяжите с конкретным уточнением: кто подтверждает назначение, кто проверяет условия доступа, кто определяет ограничения обслуживания. Технические проверки проводите только в согласованном контуре и в пределах выданных полномочий.
Как передать исполнителю обоснованную задачу
В задаче на исправление должно быть понятно, какой актив затронут, почему его рассматривают в выбранной очереди и какие условия нужно соблюсти при выполнении работы. Рекомендуется приложить сведения из карточки, на которых основано решение:
- объект, установленное ПО и обнаруженную уязвимость;
- назначение системы и значимые последствия возможной эксплуатации;
- проверенные условия доступа, требования аутентификации и действующие меры защиты;
- ответственного за администрирование и границы его полномочий;
- ограничения на обновление, перезагрузку и время обслуживания;
- нерешённые вопросы, которые могут изменить приоритет или способ исправления.
Отделите подтверждённые основания от предварительных предположений. Если значимость системы ещё уточняют, укажите это в задаче. Если условия доступа не проверены, не описывайте компонент как недостижимый. Исполнитель должен видеть, какие сведения позволяют действовать и какие требуют подтверждения до окончательного решения.
Номер CVE не задаёт универсальный срок исправления. Его выбирают с учётом обстоятельств конкретного актива и действующих в организации правил. Карточка должна дать для этого исходные данные, включая ограничения обслуживания; неподтверждённые сведения отметьте отдельно.
Выводы
Для обоснованной приоритизации нужно соединить сведения об уязвимости с техническим и рабочим контекстом актива. Проверка наличия и достижимости уязвимости показывает, к какой системе относится проблема и при каких условиях возможна эксплуатация. Назначение, данные и связи системы помогают оценить последствия, а ответственный и ограничения обслуживания позволяют подготовить исполнимую задачу.
Проверьте карточки активов, которым предстоит назначить приоритет: можно ли по ним установить затронутый объект, объяснить последствия, указать исполнителя и определить условия работ? Если ответ зависит от неизвестного поля, зафиксируйте нужное уточнение. Пригодность карточки для решения определяется актуальностью этих сведений и тем, насколько явно обозначены оставшиеся пробелы.
