• 23.06.2010 : Опубликована статья Работа с файлами сетевых дампов
• 1.06.2010 : Опубликован перевод CPE Specification 2.2
• 13.05.2010 : Опубликована статья Сбор информации об активах с помощью опросников
• 10.04.2010 : Опубликован указ президента об утверждении перечня сведений конфиденциального характера
• 1.04.2010 : Опубликовано Постановление Правительства РФ об обеспечении безопасности персональных данных.

• Фильтрация трафика BPF фильтром.
  21 Мая 2012 01:05:19
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:51:41
  
• Политика аудита защищенности
  21 Мая 2012 00:49:35
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:38:44
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:38:13
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:30:43
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:15:29
  
• Фильтрация трафика BPF фильтром.
  21 Мая 2012 00:13:23
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  21 Мая 2012 00:04:49
  
• ГОСТ Р ИСО/МЭК 17799 - 2005
  20 Мая 2012 23:43:16
  

Обобщенное перечисление платформ – спецификация

Common Platform Enumeration (CPE) - Specification

Авторы: Andrew Buttner, The MITRE Corporation и Neal Ziring, National Security Agency

Версия 2.2 — 11 марта 2009

Перевод: Грубов Юрий

Оригинал: http://cpe.mitre.org/files/cpe-specification_2.2.pdf

1. Введение

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

Все составляющие уязвимостей и настроек имеют важные различия которые влияют на их использование: они применимы только для ограниченного подмножества ИТ систем, платформ или приложений. Это настолько очевидно, что администраторы ИТ и администраторы безопасности иногда забывают насколько критичными они могут быть. Когда новая уязвимость становится известной, первый вопрос большинства сотрудников следующий: «Какая система уязвима?». В литературном описании уязвимостей приемлемы неформальные или разговорные названия платформ ИТ. Опыт системных администраторов и аналитиков ИБ позволяет понимать и использовать спонтанные и не продуманные имена.

В настоящее время активным направлением в безопасности является автоматизация. Автоматизированные системы не могут работать с не формальными или спонтанными именами. Для увеличения эффективности автоматизации, сообщество нуждается в более формальной, постоянной и унифицированной схеме, которая позволит средствам автоматизации (также как и живым аналитикам и разработчикам) точно идентифицировать ИТ платформу для которой применима уязвимость или элемент руководства.

Популярная и распространенная схема именования существует для уязвимостей; схема именования Common Vulnerabilities and Exposures (CVE) широко используется и описывает уязвимости ИТ платформ. До некоторой степени аналогичная схема также существует для описания настроек ИТ платформ: Common Configuration Enumeration (CCE).

Настоящая спецификация описывает структуру схемы имен для ИТ платформ (аппаратное обеспечение, операционные системы и приложения) и называется Common Platform Enumeration (CPE). Она основана на базовом синтаксисе Uniform Resource Identifiers (URI) [2]. Спецификация CPE включает синтаксис CPE Name и соглашение для их конструирования из информации о продукте, CPE Dictionary и ассоциированную с ним XML схему, который закрепляет список всех известных CPE Name, а также содержит описательную и проверочную информацию, CPE Language для создания сложных описателей платформ, алгоритм сравнения matching. Для получения актуального CPE Dictionary и полного списка сокращений и названий, пожалуйста посетите web-сайт CPE:

http://cpe.mitre.org

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

2. Способы использования

Далее приводятся возможные способы использования CPE, которые помогают понять цель его разработки.

2.1 Обобщенные имена

Одно программное средство помечает отчеты/результаты как применимые для отдельного типа платформ(ы). Второе программное средство импортируют отчеты/результаты и принимают специфические действия основываясь на типе платформ(ы). Второе средство должны быть способно понять, что «сказало» первое относительно типа платформы для того чтобы знать какое действие применять. Иными словами, второе средство должно использовать те же термины для описания платформ, что и первое.

Приведенный пример ориентирован на «средства». Но этот случай также может иметь место в web-сервисах (SOA), репозиториях и прочих зависимых от данных применениях.

2.2 Сравнение

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

2.3 Отчеты

При использовании в отчетах о системах или группах систем CPE Name позволяет коррелировать результаты нескольких источников. Например, отчет может быть создан о системе в заданной сети. Если для этой системы определено CPE Name, то отчет может использоваться для исследования других сетей на предмет возможной уязвимости характерной для этого типа платформ.

3. Термины

В этой спецификации используются следующие термины:

CPE Name (CPE имя ): уникальное сочетание component выделенное для специфического типа платформ.

Platform (Платформа): ИТ система которая состоит из аппаратного, программного обеспечения, операционной системы и других возможных частей.

Platform Part (Часть платформы): Отдельная часть информации об типе платформы. Многие platform part идентифицированы: аппаратное обеспечении, программное обеспечение, операционные системы, приложения.

Component (Компонента): отдельная часть информации об платформе. Например, имя производителя или номер версии.

CPE Dictionary (CPE словарь): сборник официальных CPE Name, включающий всю необходимую сопутствующую информацию (заголовок, ссылки, автоматические проверки и т.д.)

CPE Language (CPE язык): метод объединения нескольких CPE Name для описания сложного типа платформ.

Matching (Сравнение): процесс определяющий описывают ли данные CPE Name или CPE Language заданную платформу, которая определена как набор из CPE Name.

4. Требования

Для идентификации платформ ИТ, которая проводится с целью управления уязвимостями, конфигурациями, исправлениями и обновлениями, управления активами и других задач безопасности, необходимо рассмотреть большое количество отдельных platform part.

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

Операционная система – контролирует и управляет аппаратным обеспечением ИТ и поддерживает приложения. Тип операционной системы, версия, редакция (edition), состояние обновления почти всегда важны для описания уязвимостей и руководств.

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

• CPE Name ДОЛЖНО быть способно точно и не двусмысленно определить каждый тип платформы приведенный выше.

Руководства по безопасности и описания уязвимостей относятся к широкому перечню категорий продуктов и систем. Например, некоторые уязвимости влияют на всю линейку продуктов, тогда как другие только на отдельную выпуск (reliase) или версию продукта. Некоторые руководства применяются для всех семейств продуктов или типов систем, но другие могут применяться только к отдельным версиям приложений запускаемых на отдельной версии ОС.

• CPE ДОЛЖНО быть способно точно и не двусмысленно определить информацию о платформе во всем диапазоне значений.

Использование более общих CPE Name требует меньших по объему списков имен, но одновременно это не очень «дальнозорко», поскольку новые версии платформ могут быть выпущены с такими изменениями, что исходные руководства ассоциированные с этими общими CPE Name будут не применимыми. Такое назначение CPE Name может быть очень опасным и должно использоваться с осторожностью.

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

• CPE спецификация ДОЛЖНА акцентировать внимание на перечислении типов платформ

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

• CPE имя ДОЛЖНО быть способно определять интернационализацию, которая поддерживается заданной платформой

Вместе с выразительными именами, в настоящей спецификации должна быть определена поддержка автоматического сопоставления системы с CPE Name. CPE Dictionary может включать ссылку связанную с каждым CPE Name для проверки с помощью Open Vulnerability and Assessment Language (OVAL [3]); эта проверка может использоваться относительно заданной системы ИТ для определения относится ли ее платформа к заданному CPE Name.

• CPE спецификация ДОЛЖНА определять некоторые способы для идентификации платформ

Основное требование для структур имен заключается в том чтобы набор платформ идентифицируемый длинным именем был подмножеством набора платформ идентифицируемых более коротким начальным фрагментом этого имени, таким образом обеспечивается проведение matching. Это называется «свойство префикса». Например, redhat:enterprise_linux:4 должно быть подмножеством redhat:enterprise_linux.

• Каждое CPE Name должно удовлетворять свойству префикса.

Дополнительно в противоположность тому чтобы было множество различных имен значащих одно и то же, CPE Name должны определяться так, чтобы одной платформе соответствовало только одно имя. Это достигается с помощью спецификации и официального CPE Dictionaery. Там где спецификация не определяет точную структуру (например, информация за рамками компонент производитель/продукт/версия) необходимо пользоваться CPE Dictionary, чтобы убедиться что имя еще не используется.

• CPE спецификация должна способствовать созданию уникальных названий для данной платформы.

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

• CPE имена НЕ ДОЛЖНЫ использоваться для определения особенностей настроек системы

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

5. CPE Name

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

Например, рассмотрим два руководства настройки безопасности для Windows XP, написанные разными издателями. Один издатель может связать руководство с группой из всех CPE для всех известных версий XP для которых он актуален, предполагая обновление связей с CPE при выходе новой поддерживаемой версии XP. Другой издатель может выбрать связь руководства с «Windows XP», пренебрегая фактом того что руководство не применимо для некоторых существующих или будущих версий Windows XP. Оба подхода согласуются с CPE спецификацией, но отличаются тем, что может подумать пользователь о взаимоотношении руководства и отдельного типа платформы. Пользователь должен получить эту информацию из руководства автора.

Этот раздел спецификации помогает установить как создать CPE Name для данной ограниченной области. Когда возникает вопрос об использовании того или иного определения, необходимо изучить CPEDictionary на предмет всех существующих имен чья структура может быть использована. Если он не помог, тогда должно помочь CPE сообщество. Например, участие сообщества обосновано, если имеется вопрос что использовать как «Product Component”. В общем все, что реально имеет значение это то, что CPE Name должны быть уникальны.

5.1 Общая структура

CPE Name представляются как percent-encoded URI [2], каждое имя начинается с префикса (URI scheme name) «cpe:». Важно, что схема «cpe:» не зарегистрирована как официальная в IANA (Регистрация может быть произведена в будущем, но в настоящее время она не представляется как что-то ценное. Не ясно какие преимущества она дает).

Каждая платформа может быть разделана на большое количество platform part. CPE Name определяет отдельную часть и используется для идентификации любой платформы которая совпадает с описанием этой части. platform part это:

• Части аппаратного обеспечения – эти части идентифицируют аппаратные стороны платформ ИТ и означают вещи вроде шасси, модуля, карты или других физических компонент платформы. Они могут включать виртуализированные или разделяемые (shared) элементы.
• Части операционных систем – эти части идентифицируют стороны операционной системы ИТ платформы, описывая операционную систему запущенную на платформе. Важно что многопроцессорные устройства и распределенные системы могут включать в себя многие операционные системы.
• Части приложения – эти части идентифицируют приложения, сервисы и пакеты установленные на ИТ платформе. Если система включает много приложений, то ей должно применяться много CPE Name.

platform part обозначаются как одиночный буквенный код в начале имени. Следующий пункт определяет синтаксис отдельных компонент полностью.

Важно что разница между ОС и приложениями в настоящее время не ясная полностью. Аргументом может быть то, что ОС это всего лишь другое приложение. Также, разница между редакциями ОС чаще всего заключается в пакетах (приложениях) которые поставляются вместе с ними. В этом случае, есть ли необходимость выделять отдельные CPE Name для различных редакций ОС? Или лучше иметь одно имя ОС и коллекцию имен приложений? Эта область, которая, как мы надеемся, станет лучше определенный, поскольку используя спецификацию сообщество лучше изучит проблему. Сейчас, CPE Name будут доступны для каждой редакции, так как это более естественно для сообщества и соответствует предыдущим соглашениям именования. Индивидуальные пакеты также могут идентифицироваться отдельными именами приложений.

5.2 Синтаксис компонент

Синтаксис CPE Name жестко определен для быстрого создания и сопровождения уникальных имен. Единственное требование CPE заключается в том чтобы существовал только один путь описать специфичную платформу, по этому должны использоваться строгий синтаксис и аббревиатуры. В этом пункте сделана попытка объяснить логику, которой необходимо следовать при создании нового CPE Name. Четкое следование этой логике позволит обеспечить новому CPE Name соответствие существующим соглашениям именования. К сожалению, в виду большого количества возможных CPE Name, полный их список не может быть включен в эту спецификацию. Пожалуйста посетите web-сайт CPE для обновления репозитория официальных CPE Name.

CPE Name не чувствительны к регистру. Компоненты «WebLogic» и «weblogic» эквивалентны. Для уменьшения возможных проблем, имена должны быть написаны строчными символами.

Каждое CPE Name состоит из одного или нескольких компонент, разделенных двоеточием. Первый компонент идентифицирует platform part, второй – производителя или поставщика (vendor), третий – имя продукта (product), четвертый – версию продукта (version), пятый – используется для информации об обновлениях (update and service pack), шестой – идентифицирует редакцию (edition) и седьмой компонент используется для указания информации о локализации (internationalization). Рисунок 1 показывает основной синтаксис CPE Name.

cpe:/ {part} : {vendor} : {product} : {version} : {update} : {edition} : {language}

Рисунок 1. Структура CPE имени

Допускаются пустые компоненты, они указывают на component, для которой актуальны любые значения. Например, CPE Name приведенное ниже указывает на все профессиональные редакции (Professional edition) операционной системы Microsoft Windows XP, не зависимо от их версии и уровня обновлений:

cpe:/o:microsoft:windows_xp:::pro

Важно, что этот пример не идентифицирует платформу с Windows XP и без обновлений, а идентифицирует Windows XP не зависимо от того установлены или нет обновления. Это более подробно обсуждается в пункте «Компонента обновления».

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

Также часто необходимо использовать CPE Name для идентификации специфических выпусков данной платформы. Если пытаться создать CPE Name для этого, и специфическая component не применима для данной платформы, то должен использоваться символ «-». Важно, что использование «-» отличается от его пустого значения, даже в случае когда оба способа идентифицируют один набор платформ. Например, приложение может не иметь различных редакций (edition). CPE Name для таких приложений может использовать «-» в компоненте редакции (edition component).

cpe:/a:acme:product:1.0:update2:-:en-us

Тип платформы который идентифицируется этим CPE Name изначально может быть идентичным приведенному ниже:

cpe:/a:acme:product:1.0:update2::en-us

Учитывая, что пустой component используется для идентификации платформы в не зависимости от этого component. По этому, в этом случае, он может идентифицировать любую редакцию «Acme Product 1.0 Update 2 English». Проблема, в том что в будущем, производитель может выпустить редакцию продукта. Например:

cpe:/a:acme:product:1.0:update2:pro:en-us

Рассматривая 2 предыдущих примера, CPE имя использующее «-» не совпадает с новым релизом, в то время как имя использующее пустой component совпадает.

Значение «-» также может использоваться для описания начальных выпусков если платформа использует этот компонент, но значения для его описания еще не существует. Примером этого может быть начальный выпуск приложения до выпуска любых обновлений. Самый первый выпуск может быть известен как «Acme Product 1.0». Несколько месяцев спустя производитель выпускает обновление и после его применения, платформа становится известной как «Acme Product 1.0 Update 1». В этом случае должны использоваться два CPE Name:

cpe:/a:acme:product:1.0:-

cpe:/a:acme:product:1.0:update1

Опять важно что CPE Name cpe:/a:acme:product:1.0: с пустым компонентом обновления (update component) совпадает с обоими.

Важно помнить, что когда CPE Name создается для специфического типа платформы (такого как специфический выпуск (release) программы) тогда «-» должен использоваться все время (когда подходящего термина нет) вместо пустого компонента. Пустой компонент используется только когда перечисляется более общая платформа (то есть любые версии программы).

Компонента платформы (part component)

Первый компонент CPE Name это одиночный буквенный символ который объявляет отдельный тип идентифицируемой платформы. В CPE 2.0 определены следующие коды:

h = аппаратное обеспечение

o = операционные системы

a = приложения

В случае необходимости в будущих версиях этой спецификации могут быть добавлены дополнительные буквенные коды. Например, «d» для драйверов, «l» для библиотек, «r» для окружения (runtime environment) или «v» для виртуализации.

Компонента производителя (Vendor component)

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

Важно, что сокращения не должны использоваться в компоненте производителя и вместо него должно использоваться, если оно есть, DNS имя.

Многие большие организации регистрируют несколько имен (такие как «hewlett-packard.com» и «hp.com») но в большинстве случаев, в своих презентациях и документации компания использует только одно из них. Это имя и должно использоваться как CPE Name. Если после приведенных указаний, все еще существует неоднозначность, то CPE должно получить соответствующее разъяснение от производителя или компании. Использование полного корпоративного имени порождает более длинные имена, так же как и создает потенциальные проблемы при кодировании.

Если два различных производителя совместно используют одни и те же имена высокого уровня DNS, но с различными суффиксами, тогда должно использоваться полное DNS имя. Например, если в CPE Dictionary уже существует cpe:/a:acme и ссылается на http://www.acme.com/, тогда если появляется новое имя для производителя http://www.acme.org, то должно использоваться CPE Name cpe:/a:acme.org.

В некоторых случаях, особенно актуально для программ с открытыми исходниками, производитель может не иметь определенного DNS имени. В этой ситуации, имя используемое в компоненте производителя должно быть сформировано из широко известного имени производителя, при этом пробелы заменяются на нижнюю черту. Например, производитель «Best Software» может не иметь доменного имени, тогда CPE Name для приложения ABC123 этой компании должно быть:

cpe:/a:best_software:abc123

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

cpe:/a:jon_smith:tool_name:1.2.3

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

Компонента продукта (Product component)

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

Составные имена и обозначения продукта должны быть приведены полностью, с заменой пробелов знаком подчеркивания. Следующий пример показывает это для программы «Zone Labs ZoneAlarm Internet Security Suite» версии 7.0.

cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0

Составные названия продуктов могут быть сокращены если это не делает CPE Name двусмысленным и когда производитель выделяет отдельное «не официальное» сокращение в обозначении продукта. Это помогает обеспечить приемлемую длинну имени. Например, «Internet Explorer» может быть сокращено как «ie», а «Java Runtime Environment» как «jre». Список сокращенных имен сообщества содержится на CPE web-сайте.

Также как и для компоненты производителя (vendor component), если название продукта меняется, ранее зарегистрированные CPE Name не изменяются. Но новые версии продукта, должны использовать в своих CPE Name новые названия.

Компонента версии (Version component)

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

Следующий пример показывает Adobe Reader версии 8.1.

cpe:/a:adobe:reader:8.1

Важно, что сейчас не существует подхода отделении старшей и младшей части версии в разные компоненты. Если CPE Name необходимо для всех приложений Adobe Reader которые имеют старшую версию 8, то должно быть создано отдельное имя:

cpe:/a:adobe:reader:8

Компонента обновления (Update component)

Пятая компонента CPE имени это информация об обновлении (update, service pack). Иногда это соответствует выпуску (release) или младшей части версии. Техническая разница между версией и обновлением отличается в зависимости от конкретного производителя и продукта. Существующее CPE Name должно использовать для определения того, что лучше для нового имени.

Следующий пример показывает Red Hat Enterprise Linux 4.0 обновление 4.

cpe:/o:redhat:enterprise_linux:4:update4

Часто продукты изначально выпускаются без номера обновления. Например не существует обновления «0» для Enterprise Linux и не существует Service Pack 0 для Microsoft Windows 2000. Если необходимо использовать этот начальный выпуск, тогда для этого в компоненте обновления должно использоваться соответствующее обозначение производителя. Например, Red Hat использует термин «ga» для General Availability, и CPE Name для начального выпуска Enterprise Linux 4 будет следующим:

cpe:/o:redhat:enterprise_linux:4:ga

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

Компонента редакции (Edition component)

Шестая компонента CPE имени это редакция (edition) платформы. Там где это возможно должно использоваться сокращение. Пожалуйста, смотрите раздел «Аббревиатуры» для уточнения списка правильных сокращений.

Следующий пример показывает все версии Microsoft Windows 2000 Service Pack 4 Professional Edition.

cpe:/o:microsoft:windows_2000::sp4:pro

Компонента редакции также используется для определения архитектуры целевого программного и аппаратного обеспечения, которые необходимо назвать. Мы понимаем это как различные редакции платформ. Например, в части аппаратного обеспечения, приложения могут разрабатываться для i386 и x86 архитектур, и каждая редакция требует отдельного имени. Для программного обеспечения приложение может быть разработано для запуска на Windows, Linux или Macintosh OS X.

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

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

Компонента интернационализации (Language component)

Седьмая компонента CPE Name это национальный язык связанный с специфической платформой. Это компонент должен быть представлен действительным обозначением, определенным в IETF RFC 464 «Tags for Identifying Languages» [6]. Важно что хотя любое действительно обозначение приемлемо, CPE Name должны в основном использовать коды обозначающие национальные языки и регионы.

Следующий пример показывает CPE Name связанное с платформой которая включает традиционную Китайскую версию Mozilla Firefox 2.0.0 для операционной системы Mac OSX. Важно, что имя касается всех обновлений этой версии, поскольку соответствующий компонент пустой.

cpe:/a:mozilla:firefox:2.0.0.6::osx:zh-tw

Для полной BNF грамматики определенной и доступной для CPE Name, пожалуйста смотрите приложения A.

5.3 Аббревиатуры

Некоторые слова и фразы в обозначении ИТ продуктов применяются часто. Включение этих частых слов в CPE Name было бы расточительным, и конфликтовало с целью обеспечить компактность и легкость использования имени. Для сокращения некоторых длинных имен допускается использовать аббревиатур. Важно, что каждая фраза должна быть связана только с одним сокращением.

Таблица приведенная ниже перечисляет аббревиатуры для общих терминов и сложных конструкций которые должны применяться в компонентах CPE Name. Для обновления списка аббревиатур, пожалуйста посетите web-сайт CPE по адресу http://cpe.mitre.org.

5.4 Percent Encoding

CPE Name представляются в URI в формате post-encoded. Другими словами, стандартный URI механизм percent-encoding должен использоваться для представления номеров зарезервированных символов. Октет в кодировке percent-encoded представляется как триплет, состоящий из символа процента «%» с последующим шестнадцатеричным кодом символа. Пожалуйста обратите внимание, что если «%» используется вне этого триплета, то он сам должен быть представлен в форме percent-encoded.

Далее следует список символов которые должны быть представленны в формате percent-encoded, если они используются в той или иной компоненте:

Механизм percent-encoding частый источник различия среди идентичных URI. Некоторые URI создают percent-encoded октеты для символов, которые не нуждаются в этом. В результате получается URI который эквивалентен аналогу без кодировки. Такие URI могут быть нормализованы путем декодирования percent-encoded октетов которые соответствуют не зарегистрированным символам (не зарегистрированные символы = ALPHA / DIGIT / "-" / "." / "_" / "~" ).

Когда производится сравнение, каждый компонент должен быть декодирован перед сравнением. Важно что компоненты CPE Name должны анализироваться и разделяться до того как percent-encoded октеты могут быть декодированы, иначе может быть нарушено разделение компонентов.

5.5 Примеры

Следующий пример представляет типичное CPE Name, которое соответствует операционной системе Microsoft Windows 2000, вне зависимости от редакции и обновлений.

cpe:/o:microsoft:windows_2000

Следующий пример CPE Name идентифицирует операционную систему Microsoft Windows XP Professions edition, с обновлением Service Pack 2.

cpe:/o:microsoft:windows_XP::sp2:pro

Следующий пример CPE Name ссылается на Red Hat Enterprise Linux 3 Advanced Server

cpe:/o:redhat:enterprise_linux:3::as

Следующий пример CPE Name указывает на приложение Apache Foundation HTTP server версии 2.0.52.

cpe:/a:apache:httpd:2.0.52

Следующий пример CPE Name ссылается на отдельный web-обозреватель, вне зависимости от типа аппаратного обеспечения или ОС на которой он запущен.

cpe:/a:microsoft:ie:6.0

Следующий пример CPE Name ссылается на маршрутизатор Cisco 3825 ISR.

cpe:/h:cisco:router:3825

Следующий пример CPE Name идентифицирует определенный ноутбук. Производителем является Dell Computer, линейка продуктов "Inspirion" и версия (или модель) номер 8500. Важно что платформа может включать различную периферию, каждой назначается ее собственное CPE Name если это необходимо.

cpe:/h:dell:inspirion:8500

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

cpe:/h:emc:vmware_esc:2.5

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

6. CPE Language

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

CPE Language может использовать как расширение синтаксиса CPE Name рассмотренного выше. Синтаксис для CPE Name простой и понятный, что позволяет легко его адаптировать и быстро согласовывать с сообществом. С другой стороны CPE Language вобрал в себя всю сложность, которая оказалась за пределами определения имен. Это выразилось в большей гибкости идентификации платформ. Изменения в спецификации касающиеся только языка, позволяют обеспечить стабильность для пользователей.

CPE Language основан на логических операциях, что позволяет пользователям квалифицировать применяемые платформы (1), а средствам тестирования определять какой платформе соответствует целевая система (2).

6.1 Структура

Основной строительный блок CPE Language основан на логических операциях. Это операции логического И или логического ИЛИ с одним или более CPE Name. Отдельные логические отношения также могут быть отрицательными. Несколько логических отношений позволяют пользователю точно определять платформу, как любое логические сочетание отдельных CPE Name.

6.2 XML представление

Этот пункт определяет конкретное представление CPE Language в XML используя и XML синтаксис и XML namespace (пространство имен XML). Элементы CPE Language принадлежат пространству имен "http://cpe.mitre.org/language/2.0". Рекомендуемый префикс пространства имен "cpe".

Следующий пример иллюстрирует идею того как XML представление CPE Language может использоваться для идентификации сложной платформы.

<?xml version="1.0" encoding="UTF-8"?>

<cpe:platform-specification
xmlns:cpe="http://cpe.mitre.org/language/2.0">

<cpe:platform id="123">
	<cpe:title>Microsoft Windows XP with Adobe Reader</cpe:title>
	<cpe:logical-test operator="AND" negate="FALSE">
		<cpe:fact-ref name="cpe:/o:microsoft:windows_xp" />
		<cpe:fact-ref name="cpe:/a:adobe:reader" />
	</cpe:logical-test>
</cpe:platform>
<cpe:platform id="456">
	<cpe:title>Sun Solaris 5.8 or 5.9 or 5.10</cpe:title>
	<cpe:logical-test operator="OR" negate="FALSE">
		<cpe:fact-ref name="cpe:/o:sun:solaris:5.8" />
		<cpe:fact-ref name="cpe:/o:sun:solaris:5.9" />
		<cpe:fact-ref name="cpe:/o:sun:solaris:5.10" />
	</cpe:logical-test>
</cpe:platform>

<cpe:platform id="789">
	<cpe:title>Microsoft Windows XP with Office 2003 or 2007</cpe:title>
	<cpe:logical-test operator="AND" negate="FALSE">
		<cpe:fact-ref name="cpe:/o:microsoft:windows_xp" />
		<cpe:logical-test operator="OR" negate="FALSE">
			<cpe:fact-ref name="cpe:/a:microsoft:office:2003" />
			<cpe:fact-ref name="cpe:/a:microsoft:office:2007" />
		</cpe:logical-test>
	</cpe:logical-test>
</cpe:platform>

</cpe:platform-specification>

Рисунок 2 - пример XML представления

В этом пункте описываются отдельные элементы которые могут применяться в XML представлении CPE Language. Их полное описание приведено в приложении B.

<platform-specification>

Этот элемент является корневым для XML документа CPE Language и выступает как контейнер для дочерних определений платформ.

Контент: элемент
Основание: 1
Родительский элемент: нет
Атрибуты: нет
Дочерний элемент: <platform>

<platform>

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

Контент: элемент
Основание: 1-n
Родительский элемент: <platform-specification>
Атрибуты: id
Дочерний элемент: <title>, <remark>,<logical-test>

<title>

Не обязательный элемент, может применяться как дочерний элемент платформы, для определения его читаемого заголовка. Для поддержки национальных языков, этот элемент может содержать атрибут 'xml:lang'. Для каждого национального языка может быть добавлен один заголовок.

Контент: строка
Основание: 0-n
Родительский элемент: <platform>
Атрибуты: xml:lang
Дочерний элемент: нет

<remark>

Не обязательный элемент, может добавляться как дочерний к платформе. Он предоставляет некоторое дополнительно описание. Примечаний может быть от нуля и более. Для поддержки национальных языков, этот элемент поддерживает атрибут 'xml:lang'. Для каждого национального языка может быть несколько примечаний.

Контент: строка
Основание: 0-n
Родительский элемент: <platform>
Атрибуты: xml:lang
Дочерний элемент: нет

<logical-test>

Этот элемент добавляется как дочерний к платформе и может также наследоваться для создания более сложных логических операций. Содержимое состоит из одного или более компонент, разрешены дочерние элементы <fact-ref>, <logical-test>. Используется атрибут operator и не обязательный атрибут отрицающий операцию.

Контент: элемент
Основание: 0-n
Родительский элемент: <platform>
Атрибуты: operator, negate
Дочерний элемент: <fact-ref>, <logical-test>

ПРИМЕЧАНИЕ - operator может принимать значения "AND", "OR"

<fact-ref>

Этот элемент является дочерним к logical-test. Он ссылается на CPE Name которое всегда приводится к логическому результату.

Контент: нет
Основание: 0-n
Родительский элемент: <logical-test>
Атрибуты: name
Дочерний элемент: нет

7. Matching

Matching это процесс определения указывает ли имеющееся CPE Name или CPE Language на платформу определенную как набор CPE Name.

Например, когда тестовое или анализирующее средство проверяет существующую целевую ИТ систему оно должно быть способно определить отношение любого данного CPE Name к этой системе и наоборот. Если CPE Name связано с OVAL определением, и процедура matching истина, тогда система будет признана как соответствующая этому имени. Однако не каждое CPE Name имеет OVAL определение. Это особенно верно если CPE Name создано отдельным автором или приложением для идентификации новой или не распространенной платформы, а также в случае если CPE Language использован для описания сложной платформы. Для этих случаев, определен процесс сопоставления CPE Name или CPE Language тестируемой системе, он основывается на других известных CPE Name (тех которые были получены через OVAL определения). Это процесс называется matching.

Matching позволяет определить отношения между различными CPE Name (или CPE Language) и проследить иерархические взаимосвязи в именах. Важно помнить, что часто имеют место различные отношения между CPE Name и внешними элементами данных. Связывание каких-нибудь элементов данных с CPE Name не означает, что используется тип внешних взаимосвязей CPE. Важно, что разработчик данных самостоятельно определяет тип отношений, которые он имеет с CPE. Также важно помнить, что сравнение не распространяется на эти отношения с внешними данными и, что необходимо быть осторожным в определении отношений между CPE Name которые применяют внешние взаимосвязи. Результат может быть не всегда вереным.

Например, уязвимость связана с CPE Name cpe:/o:microsoft:windows_xp, при этом она может быть не актуальна для service pack 2, что с помощью обычного языка формулируется следующим образом: "уязвимость может относится, а может и нет, к платформе совпадающей с CPE Name, но определенно не относится к платформам не совпадающим с ним". cpe:/o:microsoft:/windows_xp::sp2 попадает в область заданную cpe:/o:microsoft:windows_xp однако с последним именем также связаны внешние данные, которые исключают sp2 и не поддерживаются CPE. Вместе с этим sp1 также относится к заданному имени, внешние данные его не исключают, таким образом эта платформа имеет уязвимость. На лицо не однозначность определения уязвимостей только средствами CPE, если с CPE Name связаны какие-то внешние данные.

Помните, что определенные отношения между CPE Name и внешними данными не используются во время matching.

7.1 Концептуальная модель

Концептуальная модель сравнения состоит из двух шагов:

1. Создание списка всех CPE Name и логических отношений между ними.
2. Для каждого имени, проверяется имеет ли целевая система аппаратное, программное обеспечение или приложения связанные с именем. Если проверка удачна для всех имен и удовлетворяет логическим отношениям, то целевая система является реализацией CPE Name или CPE Language.

Пока что концептуальная модель очень простая и не практикуется всеми средствами анализа. Как правило, очень сложно проверить составные части системы ИТ.

В более реальной ситуации, средство тестирования поддерживает стандартный словарь CPE Name для обычного аппаратного обеспечения, ОС и приложений. Используя этот словарь и OVAL определения включенные в него, средство анализа может собрать известный набор K из CPE Name которым соответствует тестируемая платформа. Затем, имея эталонные CPE Name или языковые отношения, средство может установить соответствует ли им тестируемая система. Это называется "known instanse based matching". Рисунок 3 показывает основную этой концепцию; более формальное описание приведено далее.

Рисунок 3. Known instanse based matching

Важно: в CPE нет механизма позволяющего квалифицировать платформы основываясь на отсутствии системных показателей. Все сравнения положительные или отрицательные.

7.2 Алгоритм сравнения: known instanse based matching

Сравнение состоит из двух алгоритмов.

1. CPE_Name_Match - этот алгоритм принимает группы CPE Name K и кандидата CPE Name X. Возвращаемое значение истина если X совпадает с любым из членов K, и ложь в ином случае.
2. CPE_Language_Match - этот алгоритм принимает группу CPE Name K и кандидата CPE Language E. Он возвращет истину если отношение может быть удовлетворено подстановкой членов K, в иных случаях - ложь.

Алгоритмы приведены далее в псевдо коде. Примеры применений алгоритмов предоставляются отдельно на web-сайте CPE.

CPE Name Match

Входные

• K — список из m CPE Name, K = {K1, K2, …, Km}.
• X — кандидат, CPE Name

Выходные данные:

• Истина если X совпадает с K, иначе ложь.

Алгоритм:

function CPE_Name_Match(K, X)
	for each N in K do
		if length(N)>= length(X) then
			r := false.
			for i := 1 to length(X) do
				if comp(X,i) = comp(N,i) or
					comp(X,i) = ""
				then
					r := true.
				else
					r := false.
					break.
				end
			end
			if r = true then
				return true.
			end
		end
	end
	return false.
end

Примечание:

• функция length(N) возвращает число компонент в CPE Name N.
• функция comp(N,i) возвращает i-ый компонент CPE Name N в виде строки.

CPE Language Match

Входные данные:

• K — список из m CPE Name, K = {K1, K2, …, Km}.
• E — выражение в CPE Language, представленное в XML (смотри секцию 6).

Выходные данные:

• Истина если E может быть удовлетворено с помощью K, иначе ложь.

Алгоритм:

function CPE_Language_Match(K, E)
	if element(E) = "platform" then
		for each C in children(E) do
			if element(C) = "logical-test" then
				return CPE_Language_Match(K, C).
			end
		end
	else if element(E) = "fact-ref" then
		return CPE_Name_Match(K, attribute(E, "name")).
	else if element(E) = "logical-test" then
		count := 0.
		len := 0.
		answer := false.
		for each C in children(E) do
			len := len + 1.
			if (CPE_Language_Match(K, C)) then
				count := count + 1.
			end
		end
		if attribute(E, "operator") = "AND" then
			if count = len then
				answer := true.
			end
		else if attribute(E, "operator") = "OR" then
			if count > 0 then
				answer := true.
			end
		end
		if attribute(E, "negate") = true then
			answer := ~answer.
		end
		return answer.
	else
		return false.
	end
end

Примечание:

• Функция element(E) возвращает имя элемента XML node в виде строки.
• Функция attribute(E, A) возвращает значение атрибута A элемента E в виде строки.

7.3 Примеры сравнений

Следующие примеры иллюстрируют «known instanse based matching».

В первом примере, с помощью OVAL определений из CPE Dictionary тестируемая система описана двумя именами. Эти имена собраны в группу K.

K = {"cpe:/o:microsoft:windows_2000::sp3:pro", "cpe:/a:microsoft:ie:5.5"}

Правило в тесте на уязвимость содержит описание проверок некоторых настроек в операционной системе Microsoft Windows 2000. Правило отмечено CPE Name показывающем это и называющимся «имя кандидата X».

X = "cpe:/o:microsoft:windows_2000"

Всего в X есть три компонента: C1=o, C2=microsoft, C3=windows_2000. Выполняя алгоритм сравнения, мы видим что каждая компонента совпадает с соответствующей компонентой первого CPE Name в K. Таким образом, алгоритм вернет истину и правило может быть применено к целевой системе.

Во втором примере, сравнивается OVAL определение из CPE Dictionary с тестируемой системой описанной двумя CPE Name.

K = {"cpe:/o:sun:sunos:5.9:::en-us", "cpe:/a:bea:weblogic:8.1"}

Правило в тесте на уязвимость безопасности указывает на приложение BEA WebLogic application server 8.0 запущенное на Solaris 8 или 9 (SunOS 5.8 или 5.9). Это показано в следующем выражении CPE Language:

X= 	<cpe:platform id="123">
	<cpe:title>Sun Solaris 5.8 or 5.9 with BEA Weblogic 8.1 installed</cpe:title>
	<cpe:logical-test operator="AND" negate="FALSE">
		<cpe:logical-test operator="OR" negate="FALSE">
			<cpe:fact-ref name="cpe:/o:sun:solaris:5.8" />
			<cpe:fact-ref name="cpe:/o:sun:solaris:5.9" />
		</cpe:logical-test>
		<cpe:fact-ref name="cpe:/ a:bea:weblogic:8.1" />
	</cpe:logical-test>
	</cpe:platform>

Следуя алгоритму сравнения CPE Language, мы видим, что оператор верхнего уровня "AND" объединяет два условия: одно из них это следующая логическая операция и второе простое fact-ref. Вложенное логическое выражение истино, поскольку одно из входящих в него простых fact-refs совпадает с членом K. Другое fact-ref также истина, поскольку также совпадает с членом K.

8. CPE Dictionary

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

Основной формат CPE Dictionary это XML. Формат определен с использованием XML схемы [1]; полная схема приведена в приложении C. Схема определяет два главных элемента:

• <cpe-list> - корневой элемент и контейнер для некоторого количества элементов <cpe-item>.
• <cpe-item> - хранит информацию о отдельном CPE Name, включающую заголовок, список (возможно пустой) поясняющих заметок, список (возможно пустой) ссылок и списка (возможно пустого) диагностических проверок.

CPE Dictionary может использоваться утилитами для тестирования и генерации отчетов, также как и API, WEB услугами и т.п. для предоставления понятных и компактных имен и описания CPE Name используемых для автоматизированной обработки руководств и определения уязвимостей.

Рисунок 4, расположенный ниже, показывает короткий пример CPE Dictionary.

<?xml version="1.0">

<cpe-list xmlns="http://cpe.mitre.org/dictionary/2.0"
    xmlns:cpe_dict="http://cpe.mitre.org/dictionary/2.0">

  <cpe-item name="cpe:/o:redhat:enterprise_linux:3">
    <title>Red Hat Enterprise Linux 3</title>
</cpe-item>

<cpe-item name="cpe:/o:sun:sunos:5.8">
  <title>Sun Microsystems SunOS 5.8</title>
  <notes>
    <note>Also known as Solaris 8</note>
  </notes>
</cpe-item>

<cpe-item name="cpe:/o:microsoft:windows_2003">
  <title>Microsoft Windows Server 2003</title>
  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
      oval:org.mitre.oval:def:128
  </check>
</cpe-item>

</cpe-list>

Рисунок 4 - Короткий CPE Dictionary

8.1 Добавления в CPE Dictionary

Производители и члены сообщества могут посылать новые имена для добавления в CPE Dictionary на email cpe@mitre.org, представив их в форме XML. XML файл должен соответствовать схеме словаря, которая приведена в приложении C. После быстрого процесса проверки, новое имя может быть автоматически добавлено в официальный словарь.

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

Внутренние процессы:

• прием файла от сообщества
• проверка XML
• если найдена ошибка, уведомления пользователя и попытка исправления проблемы
• определение содержит ли файл новые или обновленные данные
• проверка контента на правильность
• добавления корректных данных в CPE Dictionary
• обновление CPE Dctionary с новыми изменениями
• отмена старых имен если это необходимо
• отсылка сообществу сообщений о смене статуса
  • как много данных добавлено
  • как много данных удалено
  • почему

9. Ссылки

[1] Fallside, D.C., XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001.
W3C documents are available from http://www.w3.org/.

[2] Berners-Lee, T., Fielding, R., and Masinter, L., Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, January 2005.
Internet RFCs are available from http://www.rfc-editor.org.

[3] “OVAL – The Open Vulnerability and Assessment Language”, The MITRE Corporation, September 2006.
This is the OVAL web site, http://oval.mitre.org/.

[4] Mockapetris, P., "Domain Names – Implementation and Specification", RFC 1035, November 1987.
Internet RFCs are available from http://www.rfc-editor.org.

[5] Grobauer, B., "CVE, CME, ... CMSI? Standardising System Information", Siemens AG, April 2005.
This paper introduces the Common Model of System Information, a structured format for describing IT platforms.

[6] Phillips, A. and Davis, M., Tags for Identifying Languages, RFC 4646, September 2006.
Internet RFCs are available from http://www.rfc-editor.org.

Приложение A. Грамматика строк CPE names

Следующая BNF грамматика определяет синтаксис CPE Name URI (URI CPE имен).

Где ALPHA и DIGIT заданы в [2], а langtag в [6].

Приложение B. XML схема CPE Language

Следующая схема устанавливает XML формат для CPE Language.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://cpe.mitre.org/language/2.0"
    xmlns:cpe="http://cpe.mitre.org/language/2.0"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
    
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
    schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    
<xsd:annotation>

  <xsd:documentation xml:lang="en">
    This XML Schema defines the CPE Language. An individual CPE Name
    addresses a single part of an actual system. To identify more
    complex platform types, there needs to be a way to combine
    different CPE Names using logical operators. For example, there
    may be a need to identify a platform with a particular operating
    system AND a certain application. The CPE Language exists to
    satisfy this need, enabling the CPE Name for the operating system
    to be combined with the CPE Name for the application. For more
    information, consult the CPE Specification document.
  </xsd:documentation>
  
  <xsd:appinfo>
    <schema>CPE Language</schema>
    <author>Neal Ziring, Andrew Buttner</author>
    <version>2.2</version>
    <date>03/11/2009 09:00:00 AM</date>
  </xsd:appinfo>
  
</xsd:annotation>

<!-- ==================================================================== -->
<!-- ==================================================================== -->
<!-- ==================================================================== -->

<xsd:element name="platform-specification">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      This element is the root element of a CPE Language XML
      documents and therefore acts as a container for child
      platform definitions.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="platform" type="cpe:PlatformType"
	  minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  
  <xsd:key name="platformKey">
    <xsd:selector xpath="cpe:platform"/>
    <xsd:field xpath="@id"/>
  </xsd:key>
  
</xsd:element>

<!-- ==================================================================== -->
<!-- ============================ PLATFORM ============================ -->
<!-- ==================================================================== -->

<xsd:complexType name="PlatformType">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The platform element represents the description or
      qualifications of a particular IT platform type. The platform
      is defined by the logical-test child element.
      The id
      attribute holds a locally unique name for the platform.
      There is no defined format for this id, it just has to be
      unique to the containing language document.
    </xsd:documentation>
    <xsd:documentation xml:lang="en">
      The optional title element may appear as a child to a
      platform element. It provides a human-readable title for it.
      To support uses intended for multiple languages, this element
      supports the ‘xml:lang’ attribute. At most one title element
      can appear for each language.
    </xsd:documentation>
    <xsd:documentation xml:lang="en">
      The optional remark element may appear as a child of a
      platform element. It provides some additional description.
      Zero or more remark elements may appear. To support uses
      intended for multiple languages, this element supports the
      ‘xml:lang’ attribute. There can be multiple remarks for a
      single language.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:sequence>
    <xsd:element name="title"
	type="cpe:TextType"
	minOccurs="0"
	maxOccurs=" unbounded" />
    <xsd:element name="remark"
	type=" cpe:TextType"
	minOccurs="0"
	maxOccurs="unbounded" />
    <xsd:element name="logical-test"
	type="cpe:LogicalTestType"
	minOccurs="1"
	maxOccurs="1" />
  </xsd:sequence>
  
  <xsd:attribute name="id" type="xsd:anyURI" use="required" />
  
</xsd:complexType>

<xsd:complexType name="LogicalTestType">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The logical-test element appears as a child of a platform
      element, and may also be nested to create more complex
      logical tests. The content consists of one or more elements:
      fact-ref, and logical-test children are permitted. The
      operator to be applied, and optional negation of the test,
      are given as attributes.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:sequence>
    <xsd:element name="logical-test"
	type="cpe:LogicalTestType"
	minOccurs="0"
	maxOccurs="unbounded" />
    <xsd:element name="fact-ref"
	type="cpe:FactRefType"
	minOccurs="0"
	maxOccurs="unbounded" />
  </xsd:sequence>
  
  <xsd:attribute name="operator" type="cpe:operatorEnumeration"
      use="required" />
  <xsd:attribute name="negate" type="xsd:boolean"
      use="required" />
      
</xsd:complexType>

<xsd:complexType name="FactRefType">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The fact-ref element appears as a child of a logical-test
      element. It is simply a reference to a CPE Name that always
      evaluates to a Boolean result.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:attribute name="name" type="cpe:namePattern" use="required" />
  
</xsd:complexType>

<!-- ==================================================================== -->
<!-- ========================== ENUMERATIONS ========================== -->
<!-- ==================================================================== -->

<xsd:simpleType name="operatorEnumeration">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The OperatorEnumeration simple type defines acceptable
      operators. Each operator defines how to evaluate multiple
      arguments.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="AND" />
    <xsd:enumeration value="OR" />
  </xsd:restriction>
  
</xsd:simpleType>

<!-- ==================================================================== -->
<!-- ======================== SUPPORTING TYPES ======================== -->
<!-- ==================================================================== -->

<xsd:complexType name="TextType">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      This type allows the xml:lang attribute to associate a
      specific language with an element's string content.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:simpleContent>
    <xsd:extension base="xsd:string">
      <xsd:attribute ref="xml:lang" />
    </xsd:extension>
  </xsd:simpleContent>
  
</xsd:complexType>

<!-- ==================================================================== -->
<!-- ========================== ID PATTERNS =========================== -->
<!-- ==================================================================== -->

<xsd:simpleType name="namePattern">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      Define the format for acceptable CPE Names. A URN format is
      used with the id starting with the word cpe followed by :/
      and then some number of individual components separated by
      colons.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:restriction base="xsd:anyURI">
    <xsd:pattern value="[c][pP][eE]:/[AHOaho]?(:[A-Za-z0-9\._\-
	~%]*){0,6}"/>
  </xsd:restriction>
  
</xsd:simpleType>

</xsd:schema>

Приложение C. XML схема CPE Dictionary

Следующая схема устанавливает XML формат для CPE Dictionary.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://cpe.mitre.org/dictionary/2.0"
  xmlns:cpe_dict="http://cpe.mitre.org/dictionary/2.0"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xml="http://www.w3.org/XML/1998/namespace"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified">
  
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  
<xsd:annotation>
  <xsd:documentation xml:lang="en">
    This is an XML Schema for the CPE Dictionary. It is used to
    transfer a collection of official CPE Names along with any
    necessary supporting information (title, references, automated
    check, etc.). For more information, consult the CPE Specification
    document.
  </xsd:documentation>
  <xsd:appinfo>
    <schema>CPE Dictionary</schema>
    <author>Neal Ziring, Andrew Buttner</author>
    <version>2.2</version>
    <date>03/11/2009 09:00:00 AM</date>
  </xsd:appinfo>
</xsd:annotation>

<!-- ==================================================================== -->
<!-- ==================================================================== -->
<!-- ==================================================================== -->

<xsd:element name="cpe-list" type="cpe_dict:ListType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The cpe-list element acts as a top-level container for CPE
      Name items. Each individual item must be unique. Please
      refer to the description of ListType for additional
      information about the sturcture of this element.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:key name="itemURIKey">
    <xsd:selector xpath="./cpe_dict:cpe-item"/>
    <xsd:field xpath="@name"/>
  </xsd:key>
</xsd:element>

<xsd:element name="cpe-item" type="cpe_dict:ItemType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The cpe-item element denotes a single CPE Name. Please refer
      to the description of ItemType for additional information
      about the sturcture of this element.
    </xsd:documentation>
  </xsd:annotation>
    <xsd:unique name="titleLangKey">
      <xsd:selector xpath="./cpe_dict:title"/>
      <xsd:field xpath="@xml:lang"/>
    </xsd:unique>
    <xsd:unique name="notesLangKey">
      <xsd:selector xpath="./cpe_dict:notes"/>
      <xsd:field xpath="@xml:lang"/>
    </xsd:unique>
    <xsd:unique name="checkSystemKey">
      <xsd:selector xpath="./cpe_dict:check" />
      <xsd:field xpath="@system" />
    </xsd:unique>
</xsd:element>

<!-- ==================================================================== -->
<!-- ======================== SUPPORTING TYPES ======================== -->
<!-- ==================================================================== -->

<xsd:complexType name="GeneratorType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The GeneratorType complex type defines an element that is
      used to hold information about when a particular document was
      compiled, what version of the schema was used, what tool
      compiled the document, and what version of that tools was
      used. Additional generator information is also allowed
      although it is not part of the official schema. Individual
      organizations can place generator information that they feel
      are important and these will be skipped during the
      validation. All that this schema really cares about is that
      the stated generator information is there.
    </xsd:documentation>
  </xsd:annotation>
 
  <xsd:sequence>
    <xsd:element name="product_name" type="xsd:string"
	  minOccurs="0" maxOccurs="1">
      <xsd:annotation>
	<xsd:documentation xml:lang="en">
	  The optional product_name element specifies the name
	  of the application used to generate the file.
	</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
 
    <xsd:element name="product_version" type="xsd:string"
	  minOccurs="0" maxOccurs="1">
      <xsd:annotation>
	<xsd:documentation xml:lang="en">
	  The optional product_version element specifies the
	  version of the application used to generate the
	  file.
	</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
 
    <xsd:element name="schema_version" type="xsd:decimal"
	  minOccurs="1" maxOccurs="1">
      <xsd:annotation>
	<xsd:documentation xml:lang="en">
	  The required schema_version element specifies the
	  version of the schema that the document has been
	  written against and that should be used for
	  validation.
	</xsd:documentation>
      </xsd:annotation>
    </xsd:element>

    <xsd:element name="timestamp" type="xsd:dateTime"
	  minOccurs="1" maxOccurs="1">
      <xsd:annotation>
	<xsd:documentation xml:lang="en">
	  The required timestamp element specifies when the
	  particular document was compiled. The format for the
	  timestamp is yyyy-mm-ddThh:mm:ss. Note that the
	  timestamp element does not specify item in the
	  document was created or modified but rather when the
	  actual XML document that contains the items was
	  created. For example, a document might pull a bunch
	  of existing items together, each of which having
	  been created at some point in the past. The
	  timestamp in this case would be when this combined
	  document was created.
	</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
 
    <xsd:any minOccurs="0" maxOccurs="unbounded"
	namespace="##other" processContents="lax"/>
  </xsd:sequence>
</xsd:complexType>
 
<xsd:complexType name="ItemType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The ItemType complex type defines an element that represents
      a single CPE Name. The required name attribute is a URI which
      must be a unique key and should follow the URI structure
      outlined in the CPE Specification. The optional title element
      is used to provide a human-readable title for the platform.
      To support uses intended for multiple languages, this element
      supports the ‘xml:lang’ attribute. At most one title element
      can appear for each language. The notes element holds
      optional descriptive material. Multiple notes elements are
      allowed, but only one per language should be used. Note that
      the language associated with the notes element applies to all
      child note elements. The optional references element holds
      external info references. The optional check element is used
      to call out an OVAL Definition that can confirm or reject an
      IT system as an instance of the named platform. Additional
      elements not part of the CPE namespace are allowed and are
      just skipped by validation. In essence, a dictionary file
      can contain additional information the a user can choose to
      use or not, but this information is not required to be used
      or understood.
    </xsd:documentation>
  </xsd:annotation>
 
  <xsd:sequence>
    <xsd:element name="title" type="cpe_dict:TextType"
	minOccurs="1" maxOccurs="unbounded"/>
    <xsd:element name="notes" type="cpe_dict:NotesType"
	minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="references" type="cpe_dict:ReferencesType"
	minOccurs="0" maxOccurs="1"/>
    <xsd:element name="check" type="cpe_dict:CheckType"
	minOccurs="0" maxOccurs="unbounded"/>
    <xsd:any minOccurs="0"
	maxOccurs="unbounded"
	namespace="##other" processContents="lax"/>
  </xsd:sequence>

  <xsd:attribute name="name"
      type="cpe_dict:namePattern"
      use="required"/>
  <xsd:attribute name="deprecated"
      type="xsd:boolean"
      use="optional"
      default="false"/>
  <xsd:attribute name="deprecated_by"
      type="cpe_dict:namePattern"
      use="optional"/>
  <xsd:attribute name="deprecation_date"
      type="xsd:dateTime"
      use="optional"/>
</xsd:complexType>
 
<xsd:complexType name="ListType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The ListType complex type defines an element that is used to
      hold a collection of individual items. The required
      generator section provides information about when the
      definition file was compiled and under what version.
      Additional elements not part of the CPE namespace are allowed
      and are just skipped by validation. In essence, a dictionary
      file can contain additional information the a user can choose
      to use or not, but this information is not required to be
      used or understood.
    </xsd:documentation>
  </xsd:annotation>
 
  <xsd:sequence>
    <xsd:element name="generator" type="cpe_dict:GeneratorType"
	minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="cpe_dict:cpe-item"
	minOccurs="1" maxOccurs="unbounded"/>
    <xsd:any minOccurs="0"
	maxOccurs="unbounded"
	namespace="##other" processContents="lax"/>
  </xsd:sequence>
</xsd:complexType>
 
<xsd:complexType name="TextType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The TextType complex type allows the xml:lang attribute to
      associate a specific language with an element's string
      content.
    </xsd:documentation>
  </xsd:annotation>
 
  <xsd:simpleContent>
    <xsd:extension base="xsd:string">
      <xsd:attribute ref="xml:lang" />
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>
 
<xsd:complexType name="NotesType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The notesType complex type defines an element that consists
      of one or more child note elements. It is assumed that each
      of these note elements are representative of the same
      language as defined by their parent.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:element name="note" type="xsd:string"
	minOccurs="1" maxOccurs="unbounded"/>
  </xsd:sequence>

  <xsd:attribute ref="xml:lang"/>
</xsd:complexType>
 
<xsd:complexType name="ReferencesType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The ReferencesType complex type defines an element used to
      hold a collection of individual references. Each reference
      consists of a piece of text (intended to be human-readable)
      and a URI (intended to be a URL, and point to a real
      resource) and is used to point to extra descriptive material,
      for example a supplier's web site or platform documentation.
    </xsd:documentation>
  </xsd:annotation>
 
  <xsd:sequence>
    <xsd:element name="reference"
      minOccurs="1" maxOccurs="unbounded">
      <xsd:complexType>
	<xsd:simpleContent>
	  <xsd:extension base="xsd:string">
	    <xsd:attribute name="href" type="xsd:anyURI"/>
	  </xsd:extension>
	</xsd:simpleContent>
      </xsd:complexType>
    </xsd:element>
  </xsd:sequence>
</xsd:complexType>
 
<xsd:complexType name="CheckType">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      The CheckType complex type is used to define an element for
      hold information about an individual check. It includes a
      checking system specification URI, string content, and an
      optional external file reference. The checking system
      specification should be the URI for a particular version of
      OVAL or a related system testing language, and the content
      will be an identifier of a test written in that language. The
      external file reference could be used to point to the file in
      which the content test identifier is defined.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
    <xsd:extension base="xsd:string">
      <xsd:attribute name="system" type="xsd:anyURI" use="required"/>
      <xsd:attribute name="href" type="xsd:anyURI" use="optional" />
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>
 
<!-- ==================================================================== -->
<!-- ========================== ID PATTERNS =========================== -->
<!-- ==================================================================== -->
 
<xsd:simpleType name="namePattern">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      Define the format for acceptable CPE Names. A URN format is
      used with the id starting with the word cpe followed by :/
      and then some number of individual components separated by
      colons.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:restriction base="xsd:anyURI">
    <xsd:pattern value="[c][pP][eE]:/[AHOaho]?(:[A-Za-z0-9\._\-
	~%]*){0,6}"/>
  </xsd:restriction>
</xsd:simpleType>
 
</xsd:schema>