Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Yazov_ITKS

.pdf
Скачиваний:
253
Добавлен:
31.05.2015
Размер:
7.37 Mб
Скачать

нитных жестких и лазерных дисков, блока питания и т.п.);

микросхемы внешних устройств (монитора, клавиатуры, принтера, модема, сканера и т.п.).

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

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

технологические разъемы подключения микросхем на системных платах компьютера;

технологические разъемы подключения микросхем на системных платах внешних устройств компьютера;

разъемы подключения устройств, встраиваемых в системный блок;

разъемы подключения внешних устройств и ли-

ний связи.

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

201

3.3. Уязвимости информационнотелекоммуникационной системы, используемые для реализации угроз безопасности информации

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

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

Уязвимость кода это уязвимость, появившаяся в результате разработки программного обеспечения и технических средств ИТКС без учета требований безопасности или в случае наличия ошибок проектирования и реализации.

Уязвимость конфигурации – это уязвимость, по-

явившаяся в результате определения конфигурации (параметров настройки) программного обеспечения и технических средств ИТКС.

Уязвимость архитектурная (архитектурная уяз-

вимость) – это уязвимость, появившаяся в результате выбора компонентов (элементов) ИТКС, номенклатура которых определяется с учетом технологии обработки (передачи) информации, протоколов информационного взаимодействия и особенностей аппаратной платформы.

Уязвимость технологии обработки (передачи)

информации – это уязвимость, появившаяся в результате использования технологии обработки (передачи) информации, которая отличается возможностью компрометации

202

ИТКС, обусловленной особенностями её применения, и приводит к реализации угроз безопасности информации и их последствиям.

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

Уязвимость многофакторная – это уязвимость,

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

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

Вместе с тем базы данных по уязвимостям информационных систем, их программного обеспечения сегодня ведутся преимущественно за рубежом.

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

MITRE Corporation.

203

Перечень уязвимостей используется в Национальной базе управления уязвимостями. Несмотря на название, это не столько база данных, сколько база знаний. Она ведется силами NIST (Национальный Институт стандартов и технологий от англ. The National Institute of Standards and Technology - NIST). База включает несколько инструментов, необходимых для выполнения установленных нормативными документами NIST процедур идентификации и учета уязвимостей. Кроме того, база содержит программные средства выявления уязвимостей и проверки продуктов на соответствие нормативным документам.

Нормативные документы NIST являются обязательными для применения в государственных организациях США. Другие (частные) организации и физические лица могут использовать базу знаний на добровольной основе или на основе коммерческих соглашений.

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

FISMA - закон об управлении информационной безопасностью государственных информационных систем;

Национальная стратегия безопасности киберпространства (в ней программа уменьшения уязвимостей имеет второй приоритет);

целый ряд подзаконных актов и организационных документов;

нормативные документы NIST.

Для единого подхода к описанию уязвимостей и устранения неоднозначностей с их именованием еще в 1999 году компания MITRE Corporation предложила решение, независимое от различных производителей средств поиска уязвимостей. Это решение было реализовано в виде базы данных CVE (Common Vulnerability Enumeration), ко-

204

торая затем была переименована в Common Vulnerabilities and Exposures. По сути CVE – стандарт, определяющий единое именование уязвимостей. Его поддерживают практически все производители сканеров безопасности

Полностью CVE содержится в Национальной базе уязвимостей США (NVD – National Vulnerabilities Database) или на официальном сайте [20]. Данная база распространяется в нескольких форматах: xml, html, csf, xsd schema. Из-за такой доступности, открытости и удобства к базе CVE часто обращаются сами разработчики различного ПО (в первую очередь, нацеленного на рынок средств защиты информации). База данных CVE накапливается за счет сведений, поступающих в инициативном порядке от исследователей и организаций - разработчиков программных продуктов. По составу содержащихся сведений данная база, по сравнению с другими известными базами, является наиболее представительной.

Структура записей базы данных CVE представлена на рис. 3.4.

Запись CVE

Идентификатор

Описание

Ссылки

(ID)

(Description)

(Reference)

Рис. 3.4. Структура записи базы данных CVE

В поле «ID» указывается код и порядковый номер уязвимости. В поле «Reference» записываются различного рода ссылки на так называемые «заплатки» или «патчи», позволяющие нейтрализовать уязвимость, рекомендатель-

205

ного рода документы или комментарии разработчика. Поле «Description» отвечает за описание самой уязвимости. Пример записи в базе данных уязвимостей CVE приведен на рис. 3.5.

Name: CVE-1999-0003

Description:

Execute commands as root via buffer overflow in Tooltalk database server (rpc.ttdbserverd).

Reference: NAI:NAI-29

Reference: CERT:CA-98.11.tooltalk Reference: SGI:19981101-01-A

Reference:

URL:ftp://patches.sgi.com/support/free/security/advisories/19981101- 01-A

Reference: SGI:19981101-01-PX

Reference:

URL:ftp://patches.sgi.com/support/free/security/advisories/19981101- 01-PX

Reference: XF:aix-ttdbserver Reference: XF:tooltalk

Reference: BID:122

Reference: URL:http://www.securityfocus.com/bid/122

Рис. 3.5. Пример записи в базе данных уязвимостей CVE

Таким образом, CVE - это система широкого профиля, которая не сосредоточивается только на клиентских уязвимостях или исключительно на WEB-протоколе. Изначально она задумывалась как единый стандарт идентификации уязвимостей, который должен быть ориентирован на несколько звеньев информационной системы: систему поиска и обнаружения брешей (например, сканер безопасности), антивирусное ПО, а также исследуемое ПО.

206

Наряду со стандартов CVE, разработаны еще целый ряд стандартов, таких как:

CCE (Common Configuration Enumeration – «Пе-

речисление общих конфигураций») – стандарт описания конфигураций;

CEE (Common Event Expression – «Описание об-

щих событий») – стандарт описания, хранения и обмена сигналами тревоги между разнородными средствами защиты;

CWE (Common Weakness Enumeration – «Пере-

числение общих слабостей») – стандартизованный набор слабых мест в ПО. В этом стандарте уделяется внимание не только уязвимостям как в CVE, он является более высокоуровневым, описывая типы проблем, а не их конкретные имена и проявления;

CAPEC (Common Attack Pattern Enumeration and Classification – «Перечисление и классификация общих образцов атак») – публичный каталог и схема классификации шаблонов атак;

CRF (Common Result Format – «Формат общих

результатов») – стандарт описания результатов тестирования или оценки защищенности.

Значительная работа по созданию стандартов подобного рода была проведена в Национальном институте стандартов и технологии США (NIST). В данной организации были разработаны следующие стандарты:

SCAP (Security Content Automation Protocol –

«Протокол автоматизации содержания безопасности») – это в большей степени не стандарт, а метод, использующий различные стандарты для автоматизации процесса управления уязвимостями;

207

CVSS (Common Vulnerability Scoring System –

«Общая система оценки уязвимостей») – стандарт установления рейтингов уязвимостей;

XCCDF (eXtensible Configuration Checklist Description Format – «Расширяемый формат описания контрольного списка конфигураций») – стандартизованный язык описания отчетов про-

верок, тестирований и т.п.

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

группа базовых метрики (base metric);

группа временных метрик (temporal metric);

группа контекстных метрик (environmental

metric).

Каждая метрика представляет собой число (оценку) в интервале от 0 до 10 и вектор – краткое текстовое описание со значениями, которые используются для вывода оценки.

Группа базовых метрик (рис. 3.6) отображает характеристики уязвимости, которые не меняются со временем и не зависят от окружения.

Группа временных метрик (см. рис. 3.6) отображает характеристики уязвимости, которые могут изменяться со временем. Данная группа является необязательной, поэтому она не влияет на базовую оценку. Временные метрики

208

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

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

Описание метрик CVSS, их значений и групп, в которые они входят, представлено в табл. 3.1 – 3.3, а их подробное описание, а также порядок получения оценок уязвимостей ПО приведены в документе «Полное руководство по общему стандарту оценки уязвимостей, версии 2»

[21].

Пример оценки по стандарту CVSS уязвимости в

SCADA18-системе RealWin, способная вызвать переполнение буфера.

Выбор значений базовых метрик:

вектор доступа (AV) – сетевой (network(N));

сложность доступа (AC) – низкая (low(L));

аутентификация (Au) – не требуется (none(N));

влияние уязвимости на конфиденциальность информации (C) – полное раскрытие (complete(C));

влияние уязвимости на целостность информации

(I)– полное нарушение (complete(C));

влияние уязвимости на доступность информации

(A) – полное нарушение (complete(C)).

18 SCADA (от англ. supervisory control and data acquisition) - диспет-

черское управление и сбор данных

209

Группа базовых метрик Вектор доступа

Сложность доступа Аутентификация

Влияние на конфиденциальность

Влияние на целостность Влияние на доступность

Стандарт CVSS

Группа временных метрик

Возможность использования

Уровень исправления

Степень достоверности отчета

Рис. 3.6. Структура групп метрик CVSS

210

Группа контекстных метрик

Вероятность нанесения ущерба

Плотность целей

Требования к безопасности

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]