Чтобы устранить уязвимости в данных, начните с архитектуры

В этом интервью для Help Net Security Арт Мэнион, заместитель директора компании Tharros, анализирует причины, по которым данные об уязвимостях в различных репозиториях остаются противоречивыми и ненадёжными.

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

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

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

Мы попытались определить этот минимальный набор (MVVE) и обнаружили, что, вероятно, его не существует. Есть общие элементы, такие как указание уязвимого (программного) продукта и условий, при которых эксплуатация будет успешной и приведёт к нарушению одного или нескольких свойств безопасности. За их пределами количество и тип утверждений, необходимых для дедупликации и устранения неоднозначности уязвимости, различаются.

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

Несомненно, существующие форматы записей оставляют возможности для улучшения. Мы начали не с вопроса «Что у нас есть?», а с вопроса «Что нам нужно?». Это привело нас к следующему: «Какие задачи и решения в управлении уязвимостями поддерживаются этими записями?». Одна из самых важных первоначальных задач — идентификация затронутых программных продуктов. Недавние исследования показали, что «Несоответствия в наименованиях были выявлены в 50,18% названий вендоров, используемых в CPE в официальной базе данных NVD». Если мы не можем точно идентифицировать затронутые продукты, всё остальное не имеет значения. (CPE не уникальна в этом отношении, другие системы идентификации ПО страдают от схожих проблем).

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

Как только мы спроектируем систему для фиксации необходимого уровня детализации, нам нужно сосредоточиться на возможности доверять этой информации. Ещё один принцип, который мы будем обсуждать: «Каждое утверждение в записи должно быть способно отвечать за себя». Поэтому, когда мы фиксируем утверждения, они должны быть простыми, точными, наблюдаемыми, полезными и включать данные о происхождении. Новая запись об уязвимости — это набор утверждений, растущий (и изменяющийся) со временем, привязанный к идентификатору уязвимости и пригодный для машинной обработки. Эти утверждения описывают уязвимость, обеспечивая идентификацию, дедупликацию и управление уязвимостями, и они должны быть независимо проверяемыми и опровержимыми.

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

Рассмотрим CVSS. Репозитории уязвимостей обычно предоставляют базовые баллы и векторы CVSS, призванные отразить приблизительную техническую критичность. На первый взгляд, в этом нет ничего плохого. Репозитории не могут легко снабдить потребителей локальной, контекстно-зависимой информацией, необходимой для оценки риска. Потребители должны сами предоставить этот контекст, который, вероятно, важнее приблизительной технической критичности. Однако внимание, уделяемое относительно недорогим базовым баллам CVSS («осторожно, 9,8!»), отвлекает от работы по определению контекста и более целостной оценки риска. Подсчёт записей об уязвимостях с баллами CVSS или измерение распределения базовых баллов CVSS возможны, но приносят ли они пользу?

Разные языковые игры, определения и чрезмерно абстрактные метрики также ведут к искажению. Как два разных, но одинаково квалифицированных аналитика, изучая одну и ту же информацию об уязвимости, могут присвоить разные идентификаторы CWE или векторы сложности атаки CVSS? Многие из распространённых сегодня утверждений не проходят проверку на атомарность и наблюдаемость. Разногласия возникают естественным образом, и метрики, основанные на этих утверждениях, будут искажены.

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

Загрузить: Обзор угроз и средств защиты идентификации SANS 2026