• О проекте
  • Услуги
  • Заказать услугу
  • Новости
  • Блог
  • Глоссарий
  • Акции
  • Контакты
  • Блог

    Подготовка вектора. Основы расчета ч.5 «Руководство по общему стандарту оценки уязвимостей» CVSS v2

    Оглавление

    1. Базовый, временной и инфраструктурный вектор

    Каждый показатель в векторе состоит из аббревиатуры названия, за которой следует “:”, затем аббревиатура значения. Вектор содержит все показатели в определенном порядке, разделенными знаком “/”.  Если временной или инфраструктурный вектор не рассчитывается, то указывается ND “notdefinded”. Базовый, временной и инфраструктурный вектор приведены в таблице №.13.

    Таблица №13

    Возможные значения векторов

    Группа показателей

    Вектор

    Базовый

    AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]

    Временной

    E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]

    Инфраструктурный

    CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/

    IR:[L,M,H,ND]/AR:[L,M,H,ND]

    2. Расчет

    2.1 Основы

    Принцип 1

    При расчете рейтинга CVSS не следует принимать в расчет взаимодействия с другими уязвимостями. Каждая уязвимость рассчитывается отдельно.

    Принцип 2

    Рассчитывая рейтинг риска, учитывайте прямой урон лишь целевому хосту. Например, при расчете показателя для XSS: урон системе пользователя может быть значительно сильнее, чем целевому хосту. При расчете считаем, что нет вреда конфиденциальности и доступности, есть лишь частичный урон целостности.

    Принцип 3

    Множество приложений, такие как веб-сервера, могут быть запущены с разными правами, и рассчитывая урон вы делаете предположение о том, какие права были использованы. Так вот, расчет уровня риска должен производиться исходя из наиболее часто используемых привилегий. Такое правило может конфликтовать с наилучшими практиками, особенно в части клиентских приложений, которые почти всегда работают на уровне root. Если не очевидно, какие права надо учитывать при расчете, возьмите стандартную конфигурацию.

    Правило 4

    При расчете уровня риска уязвимости, которая имеет несколько возможностей для эксплуатации (по разным векторам атаки) аналитик должен выбирать метод эксплуатации, который дает в итоге максимальный результат.

    2.2 Базовые показатели

    2.2.1 Вектор доступа

    Правило 5

    Если уязвимость может быть проэксплуатирована и локально и удаленно, то должен быть выбран вариант «Сеть». Если уязвимость может быть проэксплуатирована и локально и из сопряженной сети, то должен быть выбран вариант «Сопряженная сеть». Если уязвимость может быть проэксплуатирована из сопряженной сети и удаленно, то должен быть выбран вариант «Сеть».

    Правило 6

    Много клиентских приложений и утилит имеют локальные уязвимости, которые можно проэкспуатировать удаленно с помощью пользователя, или используя скрипты автоматического выполнения. Поэтому указываем значение «Сеть».

    2.2.2 Аутентификация

    Если уязвимость существует в самой схеме аутентификации (PAM, Kerberos) или в службе с возможностью анонимного входа (расшаренныйFTP) этот показатель должен принимать значение «Отсутствует», потому что злоумышленник может использовать уязвимость без подстановки корректных парольных данных. Наличие стандартного аккаунта может сделать этот показатель равным «Одноразовая» или «Многоразовая», но если данные это стандартного аккаунта есть в публичном доступе, то доступность техники эксплуатирования принимает значение «Высокая».

    2.2.3 Урон конфиденциальности, целостности, доступности

    Правило 8

    Уязвимости, которые дают права суперпользователя, должны учитываться со значением «Полный» показателей урона конфиденциальности, целостности, доступности. Уязвимости, которые дают права рядового пользователя, должны учитываться со значением «Частичный» показателей урона конфиденциальности, целостности, доступности. Например, нарушение целостности, которое позволяет вносить изменения в файл паролей ОС должно учитываться со значением «Полный» показателей урона конфиденциальности, целостности, доступности.

    Правило 9

    Уязвимости с частичным или полным уроном целостности также могут вызвать урон доступности. Обычно, тот, кто в состоянии редактировать записи, может их и удалять, т.е. делать недоступными.