Информационная безопасность. Часть 2. Оценки уязвимости.

____________________________________________________________________________________

Глава 2. ОЦЕНКИ УЯЗВИМОСТИ.

ЧТО ТАКОЕ ОЦЕНКА УЯЗВИМОСТИ.
СТАНДАРТЫ ОЦЕНКИ УЯЗВИМОСТИ.
БАЗЫ ДАННЫХ УЯЗВИМОСТЕЙ.
СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS.
СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ VPR.
СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ OVAL.
CVE.
CWE.

____________________________________________________________________________________

§ 2.1. ЧТО ТАКОЕ ОЦЕНКА УЯЗВИМОСТИ.

2.1.1) ОЦЕНКА УЯЗВИМОСТИ (VULNERABILITY ASSESSMENTS) — это процесс, который направлен на выявление и классификацию рисков, связанных с уязвимостями в системе безопасности.

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

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

Оценки уязвимости могут проводиться независимо или совместно с другими оценками безопасности в зависимости от ситуации в организации.

Оценки уязвимости вместе с тестированием на проникновение входят в один общий раздел — оценки безопасности (security assessments), которые выявляют и подтверждают наличие уязвимостей, чтобы мы могли работать над их исправлением, смягчением последствий или удалением. Все оценки безопасности служат для цели повышения кибербезопасности.

2.1.2) РАЗНИЦА МЕЖДУ ОЦЕНКАМИ УЯЗВИМОСТИ И ТЕСТИРОВАНИЕМ НА ПРОНИКНОВЕНИЕ.

Оценки уязвимости ищут уязвимости в сетях без имитации кибератак. Все компании должны проводить оценки уязвимости время от времени. Для оценки уязвимостей можно использовать широкий спектр стандартов безопасности, например, соответствие требованиям GDPR или стандарты безопасности веб-приложений OWASP.

Во время оценки уязвимости обычно запускается сканирование уязвимостей, а затем выполняется проверка уязвимостей критического, высокого и среднего уровня риска. Это означает, что оценщик предоставит доказательства того, что уязвимость существует и не является ложноположительной. Оценщик не будет пытаться выполнить повышение привилегий, боковое перемещение, постэксплуатацию и т. д., если он, например, подтвердит уязвимость удалённого выполнения кода.

Оценки уязвимости проходят по контрольному списку.

Соответствуем ли мы этому стандарту?
У нас есть такая конфигурация?

Тестирования на проникновение оценивают безопасность различных активов и влияние проблем, присутствующих в среде. Тесты на проникновение могут включать ручные и автоматизированные методы оценки состояния безопасности компаний. Они также часто дают лучшее представление о том, насколько защищены активы компании с точки зрения тестирования. Пентест это имитация кибератаки, позволяющая определить, можно ли проникнуть в сеть и каким образом. Тестирования на проникновение следует проводить только после успешного проведения оценок уязвимостей и внесения исправлений. Компания может проводить оценки уязвимостей и тестирования в один и тот же год.

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

2.1.3) КЛЮЧЕВЫЕ ТЕРМИНЫ:

Уязвимость — это слабое место или ошибка в среде целевой организации, включая приложения, сети и инфраструктуру, которые открывают возможность для угроз со стороны внешних участников.
Угроза — это процесс, который усиливает вероятность неблагоприятного события, например, когда злоумышленник использует уязвимость. Некоторые уязвимости вызывают больше угроз из-за вероятности эксплуатации уязвимости. Например, чем выше простота эксплуатации, тем больше вероятность того, что проблема будет использована злоумышленниками.
Эксплойт — это любой код или ресурсы, которые могут быть использованы для использования уязвимостей цели. Многие эксплойты доступны на таких платформах, как Exploit-db или Rapid7. Можно также часто увидеть код эксплойта на таких сайтах, как GitHub и GitLab.
Риск — это возможность того, что ресурсы или данные могут быть повреждены или уничтожены злоумышленниками.

2.1.4) МЕТОДОЛОГИЯ ОЦЕНОК УЯЗВИМОСТИ.

2.1.5) УПРАВЛЕНИЕ АКТИВАМИ ДАННЫХ КОМПАНИИ. Когда компания планирует свою стратегию кибербезопасности, ей следует начать с составления списка своих активов данных. То есть компания сначала должна узнать, что хочет защитить. После проведения инвентаризации активов данных, компания может приступить к процессу управления активами данных. Это ключевая концепция защитной безопасности.

Инвентаризация активов — это критически важный компонент управления уязвимостями. Компания должна понимать, какие активы находятся в её сети, чтобы обеспечить надлежащую защиту и установить соответствующие меры защиты. Инвентаризация активов должна включать информационные технологии, операционные технологии, физические, программные, мобильные и разрабатываемые активы. Организации могут использовать инструменты управления активами для отслеживания активов. Активы должны иметь классификации данных для обеспечения надлежащей безопасности и контроля доступа.

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

Инвентаризация приложений и систем. Организация должна создать тщательный и полный список активов данных для их надлежащего управления в целях обеспечения оборонительной безопасности. Активы данных включают:

Все данные хранятся локально. Жёсткие диски и твердотельные накопители хранятся в конечных точках (ПК и мобильные устройства), жесткие диски и твердотельные накопители хранятся на серверах, внешние накопители хранятся в локальной сети, оптические носители (DVD, Blu-ray диски, CD), флэш-носители (USB-накопители, SD-карты). Устаревшие технологии могут включать дискеты, ZIP-накопители и ленточные накопители.
Все хранилища данных, которыми располагает облачный провайдер компании. Самыми популярными облачными провайдерами являются Amazon Web Services, Google Cloud Platform и Microsoft Azure. Облачный провайдер предоставляет компании инструменты, которые можно использовать для инвентаризации всех данных, хранящихся у этого конкретного облачного провайдера. Иногда корпоративные сети являются мультиоблачными, то есть у них есть более одного облачного провайдера.
Все данные хранятся в различных приложениях SaaS (Software-as-a-Service). Эти данные также находятся в облаке, но не все они могут быть доступны в рамках учётной записи корпоративного облачного провайдера. Это часто потребительские сервисы или бизнес-версии этих сервисов. Это такие онлайн-сервисы, как Google Drive, Dropbox, Microsoft Teams, Apple iCloud, Adobe Creative Suite, Microsoft Office 365, Google Docs и т.д.
Все приложения, которые необходимы компании для осуществления своей обычной деятельности и ведения бизнеса. Включая приложения, которые развертываются локально, и приложения, которые развертываются через облако или иным образом представляют собой программное обеспечение как услугу.
Все локальные сетевые компьютерные устройства компании. К ним относятся маршрутизаторы, брандмауэры, сетевые концентраторы, коммутаторы, системы обнаружения и предотвращения вторжений (IDS/IPS), системы предотвращения потери данных (DLP) и т.д.

Все вышеперечисленные активы данных очень важны. Все эти активы очень важны. Злоумышленник или любой другой риск для этих активов может нанести значительный ущерб информационной безопасности компании и ее способности работать изо дня в день. Компания должны выделять время на оценку всего и быть осторожной, чтобы не пропустить ни одного актива данных, иначе они не смогут его защитить.

Компании часто добавляют или удаляют компьютеры, хранилища данных, мощности облачных серверов или другие ресурсы данных. Всякий раз, когда активы данных добавляются или удаляются, это должно быть тщательно отмечено в инвентаризации ресурсов данных.

§ 2.2. СТАНДАРТЫ ОЦЕНКИ УЯЗВИМОСТИ.

2.2.1) PAYMENT CARD INDUSTRY DATA SECURITY STANDARD (PCI DSS) — это стандарт в области информационной безопасности, который устанавливает требования для организаций, работающих с кредитными картами.

Требования PCI DSS включают внутреннее и внешнее сканирование активов данных. Например, любые данные кредитных карт, которые обрабатываются или передаются, должны выполняться в среде данных держателей карт (CDE). Среда CDE должна быть отделена от обычных активов соответствующим образом. Среды CDE отделены от обычной среды организации, чтобы защитить данные держателей карт от компрометации во время атаки и ограничить внутренний доступ к данным.

Хотя PCI DSS не является государственным нормативным актом, но организации, которые хранят, обрабатывают или передают данные держателей карт, всё равно должны внедрять руководящие принципы PCI DSS. К ним относятся банки или интернет-магазины, которые работают со своими собственными платежными решениями (например, Amazon).

2.2.2) HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT (HIPAA) — это закон для защиты данных пациентов. HIPAA не обязательно требует сканирования или оценки уязвимостей, однако для сохранения аккредитации HIPAA требуется оценка риска и идентификация уязвимостей.

2.2.3) FEDERAL INFORMATION SECURITY MANAGEMENT ACT (FISMA) — это набор стандартов и руководств, используемых для защиты государственных операций и информации. Закон требует от организации предоставления документации и доказательств программы управления уязвимостями для поддержания надлежащей доступности, конфиденциальности и целостности систем информационных технологий.

это набор стандартов и руководств, используемых для защиты государственных операций и информации. Закон требует, чтобы организация предоставляла документацию и доказательства наличия программы управления уязвимостями для поддержания надлежащей доступности, конфиденциальности и целостности информационных систем. ISO 27001

2.2.4) ISO 27001 — это стандарт, используемый во всем мире для управления информационной безопасностью. Этот стандарт требует от организаций проводить ежеквартальные внешние и внутренние сканирования.

Стандарт ISO 27001 касается информационной безопасности. Соответствие этому стандарту зависит от поддержания эффективной системы управления информационной безопасностью. Чтобы обеспечить соответствие, организации могут проводить тесты на проникновение тщательно разработанным способом.

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

§ 2.3. БАЗЫ ДАННЫХ УЯЗВИМОСТЕЙ.

2.3.1) NVD (NIST) — база данных для исследования уязвимостей, где перечислены все общедоступные категории уязвимостей. Каждой уязвимости присваивается идентификационный номер:

CVE-ГОД-НОМЕР_ID

Например, уязвимость, которую использовала вредоносная программа WannaCry, имеет номер CVE-2017-0144.

2.3.2) EXPLOIT-DB — база данных для исследования эксплойтов ПО и приложений, хранящиеся под названием, автором и версией ПО или приложения.

Можно использовать Exploit-DB для поиска фрагментов кода (Proof of Concepts), который используется для эксплуатации конкретной уязвимости. Exploit-DB для пентестеров более полезный во время оценки целевой системы.

Допустим, у нас есть служба Apache версии "Apache Tomcat 9.0". Зная версию приложения, нужно вбить её в поисковом фильтре для поиска эксплойтов. Результат нам выдаст доступные эксплойты:

2.3.3) RAPID7 — база данных для исследования уязвимостей и эксплойтов.

Эта база данных содержит инструкции по эксплуатации приложений с помощью инструмента Metasploit. Например, в этой статье выложена инструкция о том, как использовать эксплойт для «Wordpress Plugin SP Project and Document».

2.3.4) COMMON VULNERABILITY EXPOSURE DATABASE (MITRE).

2.3.5) GITHUB — веб-сервис, предназначенный для разработчиков ПО. На нём размещают и обмениваются исходным кодом приложений для совместной работы. Однако GitHub используют и как базу данных уязвимостей и эксплойтов.

GitHub использует систему тегов и ключевых слов, по которым можно искать уязвимости и эксплойты.

GitHub очень полезен для поиска редких или новых эксплойтов.

2.3.6) VULNERABILITY LAB.

2.3.7) SEARCHSPLOIT — это инструмент, который представляет собой автономную версию Exploit-DB, содержащую копии эксплойтов. Найти эксплойты можно в терминале с помощью команды searchsploit:

searchsploit названиеПриложения
или
searchsploit типУязвимости

§ 2.4. СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ CVSS.

2.4.1) CVSS (COMMON VULNERABILITY SCORING SYSTEM) — общепринятая система оценки уязвимостей, которая даёт оценку уязвимости на основе трёх показателей:

Base (базовые показатели).
Temporal (временные показатели).
Environmental (показатели конкретной среды).

При расчете серьезности уязвимости, Base-показателям дают оценку в диапазоне от 0 до 10, изменяемую путем применения показателей Temporal и Environmental.

В настоящее время действуют системы оценки CVSS v2 и CVSS v3. Информацию о различиях между двумя системами оценки можно почитать здесь.

CVSS часто используется вместе с системой оценки рисков Microsoft DREAD, которая должна помочь специалистам по ИТ-безопасности оценить серьезность угроз безопасности и уязвимостей. Microsoft DREAD используется для проведения анализа рисков с использованием 10-балльной шкалы для оценки серьезности угроз безопасности и уязвимостей. С ее помощью можно рассчитать риск угрозы или уязвимости на основе пяти основных факторов:

Потенциальный ущерб
Воспроизводимость
Возможность использования (эксплуатируемость)
Пострадавшие пользователи
Возможность обнаружения

2.4.2) ПОКАЗАТЕЛИ ДЛЯ ОЦЕНКИ УЯЗВИМОСТИ:

I) Base (базовые показатели) — представляет собой характеристики уязвимости и состоят из двух элементов:

exploitability (показатели эксплуатируемости) — это способ оценки технических средств, необходимых для эксплуатации проблемы, с использованием следующих показателей: вектор атаки, сложность атаки, требуемые привилегии, взаимодействие с пользователем.
impact (показатели воздействия) — отображают последствия успешной эксплуатации проблемы и на что влияют последствия в среде. Показатели воздействия основаны на принципах триады CIA: конфиденциальность, целостность и доступность (более подробно смотреть здесь § 3.4).

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

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

Например, высоким значением серьезности рисков для доступности будет,
злоумышленник сделает среду компании полностью недоступной для
бизнеса. Низким значением серьезности рисков будет, если злоумышленник
не сможет полностью запретить доступ к бизнес-ресурсам, и пользователи
всё ещё могли бы получить доступ к некоторым ресурсам компании.

II) Temporal (временные показатели) — содержат подробную информацию о наличии эксплойтов или исправлений для решения конкретной проблемы. Временные показатели состоят из следующих элементов:

Зрелость кода эксплойта — этот показатель показывает вероятность использования проблемы, основываясь на простоте использования методов эксплуатации. С этим показателем связаны такие значения: не определено, высокий (постоянно работающий эксплойт, который легко найти с помощью автоматизированных средств), функциональный (наличие общедоступного кода эксплойта), доказательство концепции (код эксплойта доступен, но для успешного использования проблемы злоумышленником потребуются изменения) и недоказанный.
Уровень исправления — этот показатель используется для определения приоритетности уязвимости. С этим показателем связаны такие значения: не определено, недоступно (отсутствие исправления для уязвимости), обходной путь (есть неофициальное решение, выпущенное до официального исправления поставщиком), временное исправление (официальный поставщик предоставил временное решение, но еще не выпустил исправление для проблемы) и официальное исправление (поставщик выпустил официальное исправление для проблемы для общественности).
Достоверность отчета — показывает достоверность уязвимости и точность технических сведений о проблеме. С этим показателем связаны такие значения: не определено, подтверждено (существуют различные источники с подробной информацией, подтверждающей уязвимость), обоснованно (источники опубликовали информацию об уязвимости, однако нет полной уверенности в том, что кто-то сможет достигнуть такого же результата из-за отсутствия подробностей воспроизведения эксплойта для решения проблемы) и неизвестно.

III) Environmental (показатели конкретной среды) — показывают значимость уязвимости для конкретной компании. Показатели конкретной среды состоят из следующих элементов:

принципы триады CIA: конфиденциальность, целостность и доступность (более подробно смотреть здесь § 3.4).
модифицированные базовые показатели — это показатели, которые могут быть изменены, если затронутая компания сочтёт более существенным риск в отношении конфиденциальности, целостности и доступности для своей организации. С этим показателем связаны такие значения не определено, высокий (один из элементов триады CIA будет иметь колоссальное влияние на всю компанию и её клиентов), средний (один из элементов триады CIA будет иметь значительное влияние на всю компанию и её клиентов) и низкий (один из элементов триады CIA будет иметь минимальное влияние на всю компанию и её клиентов).

2.4.3) КАЛЬКУЛЯТОРЫ УЯЗВИМОСТЕЙ CVSS:

Рассмотрим некоторые элементы калькулятора №1:

I) Attack Vector (вектор атаки) — показывает, как можно использовать уязвимость.

Network (N): злоумышленники могут воспользоваться уязвимостью только через сетевой уровень.
Adjacent (A): злоумышленники могут воспользоваться уязвимостью, только если они находятся в одной физической или логической сети, включая защищенный VPN.
Local (L): злоумышленники могут воспользоваться уязвимостью, только получив доступ к целевой системе либо локально (с клавиатуры, терминала и т.д.), либо удаленно (например, SSH), либо посредством взаимодействия с пользователем.
Physical (P): злоумышленники могут воспользоваться уязвимостью посредством физического взаимодействия/манипулирования.

II) Attack Complexity (сложность атаки) — описывает условия, которые не поддаются контролю злоумышленников и которые должны присутствовать для успешного использования уязвимости:

Low (L): для успешного использования уязвимости не требуется никаких специальных приготовлений. Злоумышленники могут без каких-либо проблем повторно использовать уязвимость.
High (H): для успешного использования уязвимости необходимо провести специальную подготовку и сбор информации.

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

None (N): для успешного использования уязвимости не требуется спецдоступа к настройкам или файлам. Уязвимость может быть использована несанкционированным способом.
Low (L): для успешного использования уязвимости злоумышленники должны иметь стандартные права пользователя. В этом случае, эксплуатация обычно затрагивает файлы и настройки, принадлежащие пользователю, или не конфиденциальные ресурсы.
High (H): для успешного использования уязвимости злоумышленники должны иметь права администратора. В этом случае, эксплуатация обычно затрагивает всю уязвимую систему.

IV) User Interaction (взаимодействие с пользователем) — показывает, могут ли злоумышленники успешно воспользоваться уязвимостью самостоятельно или требуется взаимодействие с пользователем.

None (N): злоумышленники могут успешно воспользоваться уязвимостью самостоятельно.
Required (R): пользователь должен предпринять определённые действия, прежде чем злоумышленники смогут успешно воспользоваться уязвимостью.

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

Unchanged (U): успешная эксплуатация уязвимости затрагивает уязвимый компонент или затрагивает ресурсы, управляемые тем же органом безопасности.
Changed (C): успешная эксплуатация уязвимости может повлиять на компоненты, отличные от затронутого компонента, или на ресурсы, находящиеся за пределами полномочий безопасности уязвимого компонента.

VI) Confidentiality (конфиденциальность) — показывает, насколько сильно пострадает конфиденциальность уязвимого компонента при успешной эксплуатации уязвимости. Конфиденциальность ограничивает доступ и раскрытие информации только авторизованным пользователям и предотвращает доступ к информации не авторизованных пользователей.

None (N): конфиденциальность уязвимого компонента не пострадает.
Low (L): при успешной эксплуатации уязвимости конфиденциальность уязвимого компонента будет несколько снижена. В этом случае, злоумышленники не могут контролировать получаемую информацию.
High (H): при успешной эксплуатации уязвимости, уязвимый компонент испытает полную (или серьезную) потерю конфиденциальности. В этом случае, злоумышленники имеют полный (или частичный) контроль над получаемой информацией.

VII) Integrity (целостность) — показывает, насколько сильно нарушается целостность уязвимого компонента при успешной эксплуатации уязвимости. Целостность означает надежность и достоверность информации.

None (N): целостность уязвимого компонента не пострадает.
Low (L): злоумышленники могут ограниченно изменять данные уязвимого компонента после успешной эксплуатации уязвимости. Злоумышленники не контролируют последствия модификации, и уязвимый компонент в этом случае серьезно не пострадает.
High (H): злоумышленники могут изменить все данные или критически важные данные уязвимого компонента после успешной эксплуатации уязвимости. Злоумышленники могут контролировать последствия модификации, и уязвимый компонент полностью потеряет целостность.

VIII) Availability (доступность) — показывает, насколько сильно зависит доступность уязвимого компонента от успешной эксплуатации уязвимости. Под доступностью понимается доступность информационных ресурсов с точки зрения пропускной способности сети, дискового пространства, процессорных циклов и т.д.

None (N): доступность уязвимого компонента не пострадает.
Low (L): уязвимый компонент испытает некоторую потерю доступности после успешного эксплуатации уязвимости. Злоумышленник не имеет полного контроля над доступностью уязвимого компонента и не может отказать пользователям в обслуживании, а производительность просто снижается.
High (H): уязвимый компонент испытает полную (или серьезную) потерю доступности после успешной эксплуатации уязвимости. Злоумышленник имеет полный (или значительный) контроль над доступностью уязвимого компонента и может отказать пользователям в предоставлении услуги. Производительность существенно снижается.

2.4.4) УРОВНИ ОПАСНОСТИ УЯЗВИМОСТИ — уязвимости присваивается одна из пяти уровней опасности:

➤ None (нет опасности) — 0 баллов.

➤ Low (низкий уровень) — 0.1–3.9 баллов.

➤ Medium (средний уровень) — 4.0–6.9 баллов.

➤ High (высокий уровень) — 7.0–8.9 баллов.

➤ Critical (критический уровень) — 9.0–10.0 баллов.

Системы оценки CVSS v2/CVSS v3 и как использовать калькуляторы уязвимостей разобраны в данном Руководстве.

2.4.5) ХОРОШИЕ ПРИМЕРЫ СОСТАВЛЕНИЯ ОТЧЕТОВ:

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

§ 2.5. СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ VPR.

2.5.1) VPR (VULNERABILITY PRIORITY RATING) — рейтинг приоритета уязвимости, которая даёт оценку для уязвимости с упором на её риск для самой организации. VPR гораздо более современная структура управления уязвимостями. Разработана компанией Tenable.

В отличие от CVSS, оценка от VPR учитывает актуальность уязвимости. Например, риск конкретной уязвимости не будет рассматриваться, если эта уязвимость не относится к системе, на которой работает организация. VPR динамичен в своих оценках, где риск уязвимости может меняться почти ежедневно по мере её устаревания.

2.5.2) КАЛЬКУЛЯТОРЫ УЯЗВИМОСТЕЙ VPR:

Уязвимости присваивается одна из четырёх уровней опасности:

➤ Low (низкий уровень) — 0.0–3.9 баллов.

➤ Medium (средний уровень) — 4.0–6.9 баллов.

➤ High (высокий уровень) — 7.0–8.9 баллов.

➤ Critical (критический уровень) — 9.0–10.0 баллов.

Оценка одной и той же уязвимости будет отличаться в VPR и CVSS.

§ 2.6. СИСТЕМА ОЦЕНКИ УЯЗВИМОСТЕЙ OVAL.

2.6.1) OVAL (OPEN VULNERABILITY ASSESSMENT LANGUAGE) — международный стандарт информационной безопасности, который используется для оценки и детализации текущего состояния и проблем компьютерных систем.

OVAL предоставляет язык для кодирования сведений о системе и различные репозитории контента, поддерживаемых в сообществе безопасности.

OVAL поддерживается офисом кибербезопасности и коммуникаций Министерства внутренней безопасности США. Кроме того, OVAL также используется протоколом SCAP Национального института стандартов и технологий США (NIST), который объединяет идеи сообщества для автоматизации управления уязвимостями, измерения и обеспечения соответствия систем политике.

ПРОЦЕСС OVAL

Идентификация конфигураций системы для тестирования
Оценки текущего состояния системы
Раскрытие информации в отчете. Информация может быть описана в различных типах состояний, включая: уязвимый, несоответствующий, установленный ресурс и исправленный.

2.6.2) ЭТАПЫ В ПРОЦЕССЕ ОЦЕНКИ В OVAL:

Идентификация конфигураций системы для тестирования.
Оценки текущего состояния системы.
Раскрытие информации в отчете. Информация может быть описана в различных типах состояний, включая: уязвимый, несоответствующий, установленный ресурс (installed asset) и исправленный.

2.6.3) ОПРЕДЕЛЕНИЯ OVAL. Определения OVAL записываются в формате XML для обнаружения любых уязвимостей ПО, неправильных конфигураций, программ и дополнительной системной информации, исключая необходимость эксплуатации системы. Имея возможность выявлять проблемы без их непосредственной эксплуатации, организация может определить, какие системы в сети необходимо исправить.

Определений OVAL состоят из четырёх основных классов:

Определения уязвимостей OVAL: выявляет уязвимости системы.
Определения соответствия требованиям OVAL: определяет, соответствуют ли текущие конфигурации системы требованиям системной политики.
Определения инвентаризации OVAL: оценивает систему на наличие определенного программного обеспечения.
Определения исправлений OVAL: определяет, есть ли в системе соответствующее исправление.

Кроме того, OVAL ID Format имеет следующий уникальный формат:

oval:ДоменноеИмяОрганизации:типID:значениеID

oval:org.mitre.oval:obj:1116

Тип ID может быть разделен на различные категории, включая: определение (def), объект (obj), состояние (ste), и переменная (var).

Такие сканеры, как Nessus, могут использовать OVAL для настройки шаблонов сканирования на соответствие требованиям безопасности.

§ 2.7. CVE.

2.7.1) CVE (COMMON VULNERABILITIES AND EXPOSURES) — это общедоступный каталог проблем безопасности, где каждой проблеме безопасности присвоен уникальный идентификационный номер CVE.

CVE-ГОД-НОМЕР_ID

CVE содержит критически важную информацию об уязвимости или о её влиянии, включая описание и ссылки на проблему. Информация в CVE позволяет специалистам понять, насколько пагубной может быть проблема для среды компании.

CVE спонсируется Министерством внутренней безопасности США.

В следующей таблице объясняется, как идентификатор CVE может быть назначен уязвимости. Любые уязвимости, которым назначается CVE, должны быть исправимы независимо друг от друга, затрагивать только одну кодовую базу и быть признаны и задокументированы соответствующим поставщиком.

2.7.2) ЭТАПЫ НАЗНАЧЕНИЯ CVE:

ЭТАП 1. Определить, требуется ли назначение CVE и актуально ли это. Определить, является ли обнаруженная проблема уязвимостью. «Уязвимость в контексте программы CVE обозначается кодом, который может быть использован, что приводит к негативному влиянию на конфиденциальность, целостность ИЛИ доступность, и для смягчения или устранения которого требуется изменение кода, изменение спецификации или устаревание спецификации». Кроме того, исследование должно подтвердить, что в базе данных CVE еще нет идентификатора CVE.

ЭТАП 2. Связаться с поставщиком затронутого продукта. Исследователь должен убедиться, что он предпринял добросовестные усилия, чтобы связаться с поставщиком напрямую. Для получения дополнительной информации исследователи могут обратиться к документу CVE по практике раскрытия информации.

ЭТАП 3. Определить, следует ли направлять запрос на получение CNA от поставщика или третьей стороны. Если компания является частью участвующих CNA, она может назначить идентификатор CVE для одного из своих продуктов. Если проблема касается участвующего CNA, исследователи могут связаться с соответствующей организацией CNA здесь. Если поставщик не является участвующим CNA, исследователь должен попытаться связаться со сторонним координатором поставщика.

ЭТАП 4. Запросить идентификатора CVE через веб-форму CVE. У команды CVE есть форма, которую можно заполнить онлайн здесь, если указанные выше этапы не работают для запросов CVE.

ЭТАП 5. Подтвердить формы CVE. После отправки веб-формы CVE, указанной на 4-м этапе, пользователь получит электронное письмо с подтверждением. Команда CVE свяжется с запрашивающим лицом, если потребуется дополнительная информация.

ЭТАП 6. Получить идентификатор CVE. После одобрения команда CVE уведомит запрашивающего об идентификаторе CVE, если уязвимость затронутого продукта подтверждена. На данном этапе идентификатор CVE еще не будет является общедоступным.

ЭТАП 7. Публичное раскрытие идентификатора CVE. Идентификаторы CVE могут быть объявлены общественности, как только соответствующие поставщики и стороны узнают о проблеме, чтобы предотвратить дублирование идентификаторов CVE. Этот этап гарантирует, что все связанные стороны знают о проблеме до ее публичного раскрытия.

ЭТАП 8. Объявление результатов CVE. Команда CVE просит исследователей, которые делятся несколькими CVE, убедиться, что каждый CVE указывает на разные уязвимости. Дополнительную информацию можно найти здесь.

ЭТАП 9. Предоставление информации команде CVE. Команда CVE просит исследователя помочь предоставить дополнительную информацию для использования в официальном списке CVE на веб-сайте. База данных NVD также хранит эту информацию у себя.

ОТВЕТСТВЕННОЕ РАСКРЫТИЕ ИНФОРМАЦИИ. Ответственное раскрытие информации имеет важное значение в сообществе безопасности, поскольку оно позволяет компании/исследователю работать напрямую с поставщиком, предоставляя сначала поставщику сведения о проблеме, чтобы гарантировать доступность исправления до того, как об уязвимости будет объявлено всему миру.

Если проблема не будет ответственно раскрыта поставщику, то киберпреступники могут использовать проблемы в преступных целях, также называемых zero day или 0-day.

2.7.3) ПРИМЕРЫ CVE:

CVE-2020-5902 — это уязвимость RCE без аутентификации в пользовательском интерфейсе управления трафиком BIG-IP (TMUI). Проблема может быть использована, когда TMUI доступен через порт управления BIG-IP, и приводит к полному захвату системы, поскольку злоумышленник может выполнять код, редактировать файлы, включать или отключать службы на удаленном хосте.

CVE-2021-34527 (PrintNightmare) — это уязвимость RCE в службе диспетчера очереди печати Windows (Windows Print Spooler). Служба диспетчера очереди печати Windows может быть использована не по назначению из-за неправильной обработки службой операций с файлами привилегий. Проблема требует аутентификации пользователя, но позволяет полностью захватить систему с помощью удаленного или локального выполнения кода. Проблема чрезвычайно опасна, поскольку она позволяет злоумышленнику полностью контролировать домен, поскольку она использует серверы (включая контроллеры домена) и рабочие станции.

§ 2.8. CWE.

2.8.1) CWE (COMMON WEAKNESSES ENUMERATION) — общий список типов уязвимостей программного и аппаратного обеспечения. Он служит общим языком, ориентиром для инструментов безопасности и основой для выявления, смягчения и предотвращения слабых мест. В случае цепочки уязвимостей нужно выбрать CWE, связанный с исходной уязвимостью.