классификация и количественная оценка сложности эксплуатации уязвимостей программного обеспечения

Идея написания данного материала возникла в результате прочтения двух статей, посвященных проблеме классификации уязвимостей. В одной из них [1] известный вирусолог компании Symantec, Сара Гордон, раскрывает проблему, связанную с отсутствием единого подхода к идентификации вирусов и уязвимостей программного обеспечения (ПО). В переводе статья называется: «Схемы классификации вирусов и уязвимостей: стандарты и интеграция», датирована она мартом 2003 года. К сожалению, несмотря на название, статья не содержала искомых мной схем. Однако ряд вопросов, освещенных С.Гордон, не потерял актуальности, и видимо еще не скоро потеряет. По мнению С.Гордон, проблема дезинтеграции средств защиты ПО, является следствием использования различных подходов к описанию вирусов и уязвимостей.

Производители ПО антивирусной защиты не придерживаются единого стандарта в именовании вирусов. В результате один и тот же вирус может иметь несколько названий в разных антивирусных продуктах. Еще более серьезной проблемой С.Гордон считает разобщенность антивирусов, сканеров и каталогов уязвимостей. Как правило, антивирусное средство только обнаруживает и удаляет вирус, после чего сообщает об этом пользователю. Пользователь наивно полагает, что все ОК, но при этом уязвимость, которую эксплуатировал вирус, остается в системе. Эту уязвимость можно и далее успешно эксплуатировать, но уже другими средствами. Таким образом, вирус это всего лишь средство эксплуатации известной уязвимости.
С.Гордон обращает также внимание читателей на отличия в системах идентификации уязвимостей. В качестве, примера приведены такие широко известные базы данных или онлайн-каталоги уязвимостей:
http://www.microsoft.com/security
http://online.securityfocus.com/bid/bugtraqid/
http://www.cve.mitre.org
В этой статье также содержится упоминание о системах стандартизации таких отраслей, как химия и биология. Например, в химии соединение принято именовать со ссылкой на родительские компоненты, при этом структура очевидна для всех и по-другому это соединение уже никак не назовешь. Название соединения в химии унифицировано, им может воспользоваться любой производитель или потребитель, а вот по отношению к объектам исследования компьютерной вирусологии этого не скажешь.
С.Гордон предлагает следующие направления по решению описанной проблемы:
1. Создать централизованную систему идентификации вирусов и уязвимостей в рамках единого, обязательного стандарта. В системе должно также быть реализовано оперативное оповещение всех участников об обнаружении новых вирусов и уязвимостей, снабженных описанием в утвержденном формате.
2. Унифицировать формат записи для имен уязвимостей и вирусов и обеспечить его стыковку с форматами других стандартов.
3. Требовать от производителей ПО антивирусной защиты и идентификации уязвимостей поддержки не только собственных специфических форматов имен, но и имен, соответствующих единому для всех стандарту.
Справедливости ради необходимо отметить, что подобный замкнутый цикл использования средств защиты программных продуктов предложен наhttp://cve.mitre.org. Т.е. единый стандарт идентификации уязвимостей CVE, по замыслу авторов подхода, должен охватывать следующие составляющие информационной системы:
- сканер уязвимостей или систему их поиска и идентификации;
- ПО антивирусной защиты;
- защищаемое ПО, и критические обновления к нему;
- единая система идентификации, предоставляющая первым трем унифицированный интерфейс доступа к базе данных CVE.
И, возвращаясь к началу, т.е. поиску готовых схем классификации. В своей статье С.Гордон не определяет ярко выраженных признаков классификации уязвимостей, за исключением раздела, касающегося пяти так называемых «смешанных опасностей», определяемых как вредоносные программы с характеристиками вирусов, червей, троянов и кода, ориентированного на эксплуатацию конкретных уязвимостей. Не богаты на классификационные признаки и каталоги уязвимостей, как правило содержащие следующие сведения:
- общесистемная платформа;
- возможно, какой-либо критерий, описывающий тяжесть или последствия эксплуатации уязвимости;
- непосредственно идентификатор уязвимости и, пожалуй, все.
Сканеры уязвимостей, ориентированные на системы идентификации CVE и Bugtraq, дополняют отчет о результатах исследования системы/сети показателями ранжирования. Но ранжирование это базируется, как правило, на субъективных представлениях эксперта о степени тяжести последствий эксплуатации уязвимости. Таким образом, использовать эти ранги в качестве основы построения объективной классификации весьма затруднительно.
Но не все так плохо: на сегодняшний день наметилось некоторое положительное движение в направлении классификации. С.Гордон предлагает использовать для унифицированного представления уязвимости/вируса XML-схему. Около года назад в печати промелькнуло сообщение о консорциуме OASIS, инициировавшем работы по созданию базирующегося на XML языка описания уязвимостей приложений. Окончательную спецификацию OASIS обещал представить к 2004 году. К сожалению, на данный момент автору ничего не известно о результатах этого проекта. Видимо проблема еще не утратила актуальности, и предлагаемые методы ее решения не нашли отражение в общепринятых системах стандартизации ISO или RFC.
Вторая статья [2] называется «Выявление уязвимостей компьютерной сети». Прежде чем начать собственно выявлять, Алексей Лукацкий (автор статьи) предлагает проклассифицировать уязвимости. При этом обращает внимание читателя на причины, а не на симптомы «болезни» информационной технологии. В статье, предложено деление всех уязвимостей на три основных класса:
- уязвимости проектирования;
- уязвимости реализации;
- уязвимости эксплуатации.
Такая классификация, по моему, является логически законченной и обоснованной, т.к. накрывает все этапы жизненного цикла программного продукта.
Уязвимости первого класса определены А.Лукацким как наиболее опасные. Источником возникновения этих уязвимостей является процесс проектирования. Уязвимости проектирования обнаруживаются и устраняются с большим трудом. В этом случае, уязвимость свойственна проекту или алгоритму и, следовательно, даже совершенная его реализация не избавит, по мнению автора, от заложенной в нем уязвимости.
Смысл уязвимостей второго класса заключается в появлении ошибки на этапе реализации в программном или аппаратном обеспечении корректного с точки зрения безопасности проекта или алгоритма. Выявить такие уязвимости значительно проще, чем проектные.
Источником возникновения уязвимостей третьего класса являются ошибки конфигурирования аппаратного и программного обеспечения. Такие уязвимости наиболее распространены и легче всего обнаруживаются.
Далее автор классифицирует средства анализа защищенности или так называемые сканеры безопасности. Эта часть материала также является интересной, но мы не будем ее обсуждать, т.к. задача настоящей статьи состоит в рассмотрении возможного подхода к классификации уязвимостей.
Предлагаемый подход состоит в использовании для классификации уязвимостей методов формального описания происходящих в информационной системе процессов. В качестве инструментального средства формального описания источника возникновения, методов идентификации и эксплуатации уязвимостей предлагаю использовать унифицированный язык моделирования, известный как UML. Почему не XML-схемы? Да потому, что они предназначены для разметки документов, учитывают логическую структуру документа, но при этом не предоставляют средств описания логики взаимодействия объектов, о которых говорится в документе. UML как раз и предназначен для начального, высокоуровневого проектирования процессов и дальнейшей детализации проекта до точности, необходимой для конкретизации элементарной задачи. Элементарная задача или операция - это абстрактное понятие, например функция с аргументами, результатом определенного типа, используемая многократно и не требующая дальнейшей детализации. Это не определение, а пример, демонстрирующий тот факт, что для каждого конкретного случая определение элементарной операции может отличаться.
Процесс классификации начинается с высокоуровневого определения класса или группы объектов, который в дальнейшем можно описать более детально. Для нас основным родительским классом является уязвимость как таковая, безотносительно к источнику ее возникновения, методу идентификации или эксплуатации. Рассматривать мы будем только уязвимости, характерные для различных программных продуктов, т.к. описание уязвимостей аппаратного обеспечения все равно сводится к рассмотрению алгоритмов функционирования устройств, реализации этих алгоритмов и механизмов конфигурирования. Обратите внимание, что мы не отступаем от предложенной А.Лукацким классификации, т.е. рассматриваем проект/алгоритм, реализацию/код и эксплуатацию/настройку.
Для удобства применения/компактности данной классификации предлагаю использовать англоязычную терминологию, и заранее прошу прощения перед искушенными в языках специалистами за возможные неточности перевода. Итак, основной родительский класс обозначим какVuln_Root_Class. В терминологии UML характеристики класса называются атрибутами и операциями.
Операции - это функции класса, т.е. то, что реальный объект класса может сделать или что с ним можно сделать. На диаграмме классов (рис.1) операции представлены в нижней секции блока каждого класса. Для корневого класса и классов высокоуровневой классификации уязвимостейVuln_High_Level_Classificationмы не рассматриваем операции, т.к. на данном этапе декомпозиции еще нет четкого представления о том, что же собой представляют выделенные нами классы.

Атрибуты класса - это его неотъемлемые свойства. Мы выбираем три основных критерия оценки уязвимости и определяем их как атрибуты родительского класса. Для того, чтобы провести объективную оценку уязвимости, необходимо как минимум установить ее источник Source_Criterion, провести идентификацию (обнаружить и удостовериться, что это та самая искомая) уязвимости с использованием какого-то метода(ов) Identification_Method_Criterion,и разобраться, каким-образом эту уязвимость можно проэксплуатироватьExploit_Method_ Criterion.Если вы обратили внимание, атрибуты находятся в средней секции блока и имеют нечто после двоеточия. Это нечто – тип атрибута. Аналогом типа атрибута является тип переменной. Только в нашем случае типом является дочерний класс – это называется в терминологии объектно-ориентированного проектирования инкапсуляцией свойств.
Затем необходимо проводить дальнейшую декомпозицию (пока только атрибутов корневого класса). Декомпозиция состоит в определении имен, атрибутов и операций дочерних классов. Первый дочерний класс выделен нами признаку источника уязвимостиVuln_Class_BySource.Подпись под наименованием класса свидетельствует о его вхождении в пакет классов высокоуровневого описания. Атрибуты класса выбираем согласно классификации А.Лукацкого.Vuln_Class_ProjectStructure_Source– класс уязвимости, источником которой является структура проекта или алгоритм.Vuln_Class_Implementation_Source – класс уязвимости, источником которой является реализация проекта, т.е. исходный код и исполняемый модуль проекта.Vuln_Class_Customization_Source - класс уязвимости, источником которой является кастомизация/настройка/конфигурирование исполняемых модулей проекта в процессе эксплуатации. Для всех трех атрибутов этого класса выбран тип Variant – это свидетельствует о незавершенности процедуры описания класса и предполагает возможность участия в классификации всех заинтересованных сторон.
Аналогичным образом описан классVuln_Class_ByIDMethod, предполагающий выделение подклассов уязвимостей в зависимости от способа их обнаружения. Атрибутами в данном случае являются необходимость и механизм выявления и идентификации уязвимости в процессе проведения анализа проекта, процессов его реализации и эксплуатации в течение всего жизненного цикла. Дальнейшая декомпозиция атрибутов класса также предполагает участие всех заинтересованных сторон.
Несколько иначе обстоит дело с атрибутами классаVuln_Class_ByExploitMethod – класс уязвимости, выделенный по признаку способа ее эксплуатации. Необходимость декомпозиции атрибутов этого класса обусловлена стремлением представить на всестороннее обсуждение возможный подход к количественной оценке сложности эксплуатации уязвимостей. Идея подхода состоит в подсчете количества сообщений, передаваемых программными модулями, участвующими в эксплуатации уязвимости.
Для корректности сравнения уязвимостей предлагается ввести характеристику способа их эксплуатации. В общем случае возможны только два способа эксплуатации уязвимостей, представленные соответствующими классами.Vuln_Class_Local– класс уязвимости, эксплуатация которой требует обмена определенным числом сообщений между интерфейсами модулями программных компонент одного узла.Vuln_Class_Network– класс уязвимости, эксплуатация которой требует обмена определенным числом сообщений между протокольными модулями различных узлов.
Декомпозиция третьего уровня, проведенная для классов пакетаVuln_ByExploitMethod,включает не только атрибуты, но и операции. Атрибутами обоих классов уязвимостей являются характеристики, определяющие набор уязвимых протокольных или интерфейсных модулей, с которыми необходимо взаимодействовать при эксплуатации уязвимости. Наименование атрибутов классов:Used_Protocols иUsed_Interface.Эти атрибуты пока относим к типуVariant, т.к. формальное описание уязвимых протокольных и интерфейсных модулей силами только одного автора не представляется возможным и опять таки требует участия всех заинтересованных сторон.
Для каждого класса уязвимостей, выделенных по признаку метода эксплуатации, определены три типовые операции:
1. Идентификация протокола/интерфейса –Network_Protocol_Identification()иSoftware_Interface_Identification().Идентификация не определена как составляющая процесса эксплуатации, потому что эта процедура является неотъемлемой частью процесса функционирования программных компонент в штатном режиме. Предполагается, что все возможные процессы в системе могут идентифицировать требуемый им интерфейс или протокол и определить, соответственно, правила обмена сообщениями с этим интерфейсом/протоколом. Средства защиты и обнаружения атак должны препятствовать обмену сообщениями с уязвимым протокольным/интерфейсным модулем, но не должны препятствовать его идентификации, если иное не предусмотрено политикой защиты. Таким образом, в целях обеспечения объективной количественной оценки сложности эксплуатации той или иной уязвимости будем предполагать, что злоумышленник владеет всей необходимой информацией об уязвимости и имеет необходимые средства ее эксплуатации, т.е. заранее позаботился о том, чтобы обнаружить, идентифицировать уязвимость и подобрать либо разработать соответствующий эксплоит.
2. Операции классаSend_PDUиSend_IDUуказывают на наличие в уязвимом интерфейсном/протокольном модуле функции отправки сообщений. Сообщение определяем как единицу данных протокола/интерфейса –Protocol Data UnitиInterface Data Unit, соответственно. Например, модуль протокола HTTP (его уязвимая реализация) имеет возможность отправить злоумышленнику сообщение, содержащее локальные настройки сервера. Либо интерфейсный модуль системного реестра при конфигурации списка контроля доступа определенной ветви по умолчанию (уязвимость эксплуатации) имеет возможность передать сообщение, содержащее список и значение параметров ветки процессу, функционирующему в контексте не уполномоченного пользователя.
3. Операции классаReceve_PDUиReceve_IDUуказывают на наличие в протокольном/интерфейсном модуле функции приема входящих единиц протокольного и интерфейсного обмена и автоматической реакции на эти сообщений.
В конечном итоге можно определить два количественных показателя сложности эксплуатации той или иной уязвимости, характеризующие структурную схему эксплуатации и ее трудоемкость.
Структурная сложность эксплуатации уязвимости будет выражена количеством интерфейсных и(или) протокольных модулей:Vuln_Protocols_Amount:DWordиVuln_Interfaces_Amount:DWord, которые необходимо задействовать в процессе эксплуатации.
Трудоемкость эксплуатации выражается количеством входящих и исходящих единиц данных протокола/интерфейса, которыми необходимо обменяться с уязвимой системой для успешной эксплуатации уязвимости:
Vuln_Send_PDU[ Vuln_Protocol[1.. Vuln_Protocols_Amount] ]:Dword
Vuln_Receve_PDU[ Vuln_Protocol[1.. Vuln_Protocols_Amount] ]:Dword
Vuln_Send_IDU[ Vuln_Protocol[1.. Vuln_Protocols_Amount] ]:Dword
Vuln_Receve_IDU[ Vuln_Protocol[1.. Vuln_Protocols_Amount] ]:Dword
Трудоемкость необходимо вычислять для интерфейса/протокола отдельно, т.к. механизмы защиты могут быть реализованы отдельно для каждого. Это требование для данного метода количественной оценки записано в виде структуры массива.
Предложенные подходы к классификации и количественной характеристике уязвимостей программного обеспечения не претендуют на абсолютную объективность и требует участия всех заинтересованных сторон в обсуждении и всесторонней оценке.
Предполагается написать продолжение данной статьи с примерами классификации реальных уязвимостей.

литература

1. Sarah Gordon, Virus and Vulnerability Classification Schemes: Standards and Integration,
http://www.sarc.com/avcenter/reference/virus.and.vulnerability.pdf
2. Алексей Лукацкий, Выявление уязвимостей компьютерной сети,
http://www.infosec.ru/press/pub/p79.htm

По материалам компании-производителя.