ISSN 1991-3087
Рейтинг@Mail.ru Rambler's Top100
Яндекс.Метрика

НА ГЛАВНУЮ

Оценка защищенности информационных систем по методологии общих критериев.

 

Суханов Андрей Вячеславович,

кандидат технических наук,

начальник управления специальных работ, ЗАО «ЭВРИКА», г. Санкт – Петербург,

Суханов Вячеслав Андреевич,

студент Санкт-Петербургского Государственного Университета Телекоммуникаций

им. проф. М.А. Бонч-Бруевича.

 

Причина создания общих критериев (ОК) - необходимость унификации и взаимного признания национальных стандартов в области безопасности ИТ. Единый набор международных стандартов позволяет унифицировать процесс принятия решений при приобретении защищенной информационной системы (ИС) [5, 6]. Присоединение России к странам, использующим ОК в качестве стандарта [1 - 3], сделало актуальной задачу автоматизации процессов оценивания ИС.

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

 

Методология общих критериев как объект моделирования.

 

Основной документ ОК [1 - 3] излагает единый подход к оценке безопасности ИС и содержат средства регламентации деятельности по оцениванию безопасности ИС. Согласно подходу оценщик отказывается от фиксированных классов защищенности, к которым относят продукт или ИС, а составляет стандартным образом структурированный документ – задание по безопасности (ЗБ) или профиль защиты (ПЗ), содержащий характеристики защищенности, которые необходимы для оценки, в первую очередь, – индивидуальный набор функций безопасности объекта (ФБО). ФБО выбираются из структурированного каталога, который является частью стандарта.

Опыт сертификаций показал, что предусмотренные в стандарте ОК средства регламентации деятельности по оценке безопасности ИС нуждаются в нормативном документе «Общая методология оценки» (ОМО) [4, 7].

Предметом ОК являются элементы защиты (функции защищенности, свидетельства оценки, компоненты доверия к ним), а предметом рассмотрения ОМО - действия по оценке защищенности с использованием критериев и свидетельств оценки, определенных в ОК. ОМО предназначена для оценщиков, использующих ОК, и экспертов органов по сертификации, подтверждающих действия оценщиков. Документ может использоваться заявителями на проведение оценки для получения исходной информации, разработчиками продуктов и ИС, профилей защиты, заданий по безопасности и др. сторонами [8, 9]. Мотивация для создания ОМО - унификация способов проведения оценки по ОК для взаимного признания оценок.

Понятие «методология ОК» было введено в [10] как совокупность спецификаций свойств безопасности ИС, представленных в ОК и ОМО, и их связей с возможными нарушениями безопасности. ОК задают систему понятий, в терминах которых должна производиться оценка [11, 12]. В работе под методологией ОК понимается совокупность понятий, методов, средств, функций и процессов задания требований, обеспечения и оценки безопасности продуктов и ИС в рамках единого подхода, который основан на систематизированных каталогах требований безопасности и требований доверия и изложен в ОК, ОМО и в ряде нормативно-методических документах, посвященных оцениванию изделий ИТ по ОК, в частности, Руководстве по разработке профилей защиты и заданий по безопасности Гостехкомиссии РФ [13].

ОК позволяют решать теоретические задачи, например, разрабатывать подходы и методы обеспечения защиты информации в ИС, выполнения требований конфиденциальности, целостности, достоверности и доступности информации [14], применять методы научного анализа, в частности, построение формальных моделей. Полнота описания предметной области по методологии ОК может быть достигнута путем построения разноплановых проекций: структурных моделей защищенности ИС, функциональной модели деятельности по оценке защищенности ИС и математической модели экономических аспектов защищенности ИС [15]. В структурных моделях представлены концепции методологии ОК, функциональных моделях - основные действия оценщика и разработчика, описанные в ОМО, а математической модели - описание процесса выбора экономически обоснованного набора ФБО в соответствии с системой показателей защищенности по ОК.

 

Актуальность формального моделирования методологии ОК.

 

Методология ОК основывается на концепции угроз безопасности ИС и является базой для формулирования частных концепций – уязвимости, функции безопасности и пр., а также представления свидетельств оценки и действий разработчика и оценщика. В ОК элементы частных концепций рассредоточены по тексту стандарта, а русскоязычная методическая документация находится в стадии разработки [16]. Пояснения к стандарту неполны и публикуются лишь в ряде специализированных журналов [17]. В этой связи представление методологии ОК в виде наглядных формализованных моделей актуально для эффективного применения стандарта.

Существенная мотивация построения формальных моделей ОК - необходимость разработки методов оперативной актуализации вносимых в стандарт изменений и дополнений [16]. Внедрение ГОСТ Р ИСО/МЭК 15408-1-2002 является частью правительственной программы по вступлению России в ВТО, что обуславливает масштабную деятельность по оцениванию и сертификации продуктов ИТ согласно стандарту ОК [8]. Объемы работ по оценке и сертификации ИС свидетельствую об актуальности разработки инструментальных средств поддержки деятельности по подготовке и проведению оценок, применения формальных моделей предметной области на стадиях специфицирования и высокоуровневого проектирования.

 

Структурное моделирование методологии ОК.

 

Под структурной моделью понимается модель объектная (классы, отношения, механизмы), дополняемая моделями поведения (взаимодействия, прецеденты, процессы). Построение системы структурных моделей предметной области является необходимым этапом исследования, предваряющим построение функциональных и математических моделей. Структурное моделирование фиксирует терминологию предметной области через формальное описание лексики и семантики (например, в виде классов), а также взаимосвязь основных понятий и их составляющих через формальное описания отношений между классами. В стандарте ОК отсутствует систематизированное изложение основных понятий и описание связей между ними [11]. Отмечается основная проблема, возникающая при построении структурных моделей методологии ОК - функциональные требования не сгруппированы в осмысленные наборы (объектные интерфейсы), которые можно наследовать.

Решению трудоемкой задачи разработки структурной модели по методологии ОК в зарубежных публикациях уделяется недостаточно внимания [18 - 20]. В связи с чем решение задачи структурного моделирования аспекта защищенности ИС актуально.

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

Понятия методологии ОК включает в себя объекты и процессы, описываемые методами функционального и информационного моделирования: IDEF0 (методика SADTSystems Analysis and Design Techniques) [21]; DFD (методика SADT) [22]; IDEF1X (методика IADTInformation Analysis and Design Techniques) [23]; IDEF5 (методика OAOntology Analysis) [24]; UML (методика OOADObject Oriented Analysis and Design) [25]. Рассматривались также технологии семантического связывания на основе онтологий – язык OWL (Ontology Web Language) и RDF (Resourse Description Framework) [26], а также языки представления знаний – динамические семантические сети [27].

Для упомянутых методов проведено сравнение возможности представления элементов моделирования (табл. 1), а также возможностей и свойств, перечисленных выше (табл. 2). В качестве метода и языка моделирования был выбран OMG UML 1.4/2.0, благодаря возможностям расширения набора элементов моделирования за счет встроенных в стандарт механизмов расширения (стереотипы, тэги, ограничения, отмеченные значения), а также богатой библиотеке стандартных отношений.

 

Функциональное моделирование методологии ОК.

 

Представление деятельности по оцениванию защищенности ИС, регламентируемой ОК, в виде стандартизованной функциональной модели предоставляет средства контроля стандарта [15, 28, 29]. Функциональная модель обеспечивает возможность прослеживания последствий принимаемых в новых версиях изменений до уровня конкретных операций, что облегчает работу разработчиков и испытательных лабораторий при проведении оценки.

Методика ARIS (Architecture of Integrated Information System) [30, 31] ориентирована на процессы в рамках сложной организационной структуры, методика CALS (Continuous Acquisition and Life cycle Support) [32] - на сложные технологические цепочки процессов в многоагентной среде, т.е. обе методики избыточны для данной задачи и методика SADT не имеет альтернативы.

Сравнительный анализ методов моделирования в рамках методики SADT позволяет выбрать метод DFD для задач функционального моделирования методологии ОК.

При построении функциональных моделей методологии ОК вновь возникает проблема рассогласования парадигм. Основным источником данных для построения функциональных моделей являются часть 3 ОК [3], описывающая требования доверия, и ОМО, которые построены в объектной парадигме: компоненты и элементы действий оценщика (функциональные единицы методологии) составляют иерархическую структуру и организованы по принципу наследования. По описаниям этих структур приходится строить функциональную модель, семантика которой не предполагает наследование. В такой ситуации требуется переструктурирование исходного материала из объектной в функциональную парадигму.

Обзор зарубежных источников выявил работу, посвященную функциональному моделированию фрагментов методологии ОК [33]. Комплексная модель процесса оценки ИС по ОК содержит несколько функциональных диаграмм, которые получены по методике, напоминающей SADT. Диаграммы модели не взаимосвязаны по ресурсам, носят иллюстративный характер.

 

Таблица 1.

Методика

SADT

IADT

OA

OOAD

Метод

IDEF0

DFD

IDEFLX

IDEF5

UML

Элемент моделирования

Представление в методе.

Объект

только в виде ресурса

только в виде ресурса

экземпляр

индивидуум (представитель вида)

экземпляр (объект)

Характеристика объекта

имя, определение

имя, определение

имя, определение, атрибут

имя, определение, атрибут, свойство

имя, определение, атрибут, операция

Связь между объектами

связь между ресурсами

связь между ресурсами

простое отношение

отношение (многоместное, первого и высшего порядков,… между объектами)

отношение (зависимость, ассоциация, обобщение, реализация,…) между объектами

Группирование объектов

нет

нет

сущность

вид

Структурная сущность (класс, прецедент)

Группирующая сущность (пакет)

Связь между группами объектов

нет

нет

отношение

отношение (многоместное, первого и высшего порядков,… между видами)

отношение (зависимость, ассоциация, обобщение, реализация,…) между классами

Процесс

работа

деятельность

(>>отношение)

практически нет (простейшие переходы состояний)

Поведенческая сущность (авто-мат, взаимодействие)

Структурная сущность (прецедент, кооперация)

Ресурс

вход/выход

поток

(<<сущность)

(<<вид)

Сообщение (<<класс) (<<ассоциация)

Ресурс

механизм

нет

(<<сущность)

(<<вид)

актер

Ресурс

управление

нет

(<<сущность)

(<<вид)

(<<класс)

Связь между ресурсами

разделение, слияние

разделение, слияние

практически нет

отношение (многоместное, первого и высшего порядков,… между объектами)

отношение (зависимость, ассоциация, обобщение, реализация,…) между объектами

 

Таблица 2.

Методика

SADT

IADT

OA

OOAD

Метод

IDEF0

DFD

IDEFLX

IDEF5

UML

Возможности и свойства

Наличие в методе.

Стандартный метод

есть

есть

есть

есть

есть

Формализованный синтаксис (язык)

Язык схематик с частично формализованным синтаксисом.

Язык схематик с частично формализованным синтаксисом.

Язык схематик с частично формализованным синтаксисом.

Правила нормализации.

Язык схематик с частично формализованным синтаксисом.

Язык предикативной логики

Язык схематик без формализованного синтаксиса. Набор рекомендуемых семантических правил для схематик.

Язык OCL для ограничений (семантика).

Расширение набора элементов

нет

нет

нет

нет

есть – встроенный стандартный набор механизмов расширения (стереотипы, тэги, ограничения,…)

Расширение набора графических примитивов

встроены в ПС

встроены в ПС

встроены в ПС

нет

встроены в ПС

Множественность проекций

мосты к другим методам

мосты к другим методам

мосты к другим методам

около 20 типов диаграмм

9 рекомендуемых типов диаграмм

Поддержка структур элементов

иерархия процессов

иерархия процессов

типизирующие отношения для сущностей

для всех видов объектов

для всех видов объектов - ассоциации (агрегирование)

Отображение структур элементов

для процессов - Node Tree

для процессов - Node Tree

Типизирующие отношения для сущностей

для всех видов объектов

для всех видов объектов - ассоциации (агрегирование)

Замечание. Символ «элемент» >> «представление» в табл. 1 означает, что элемент моделирования может быть представлен с помощью элемента метода, но такое представление либо сужает семантику элемента моделирования, либо его трудно использовать на практике.

Символ «элемент» << «представление» имеет обратный смысл.

 

В отечественной литературе идея использования полнофункциональной методики SADT в совокупности с методом DFD для построения формальной модели процессов оценки безопасности ИС по методологии ОК была предложена в [34] и получила практическое приложение в [35].

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

 

Математическое моделирование методологии ОК.

 

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

Стандарт предлагает совокупность функциональных требований безопасности, которые могут применяться при создании доверенных продуктов, отвечающих потребностям рынка. Однако при их формировании не всегда учитывается важная характеристика - стоимость обеспечения заданного уровня безопасности, которая зависит от рыночных цен на реализацию тех или иных ФБО, поскольку экономические аспекты не являются предметом рассмотрения в ОК. Этим вопросам посвящен международный стандарт – ISO 17799 [36], использующий отличную от ОК методологию.

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

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

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

 

Таблица 3.

Раздел

стандарта

Класс / семейство

3

Класс FAU. Аудит безопасности

3.1

Автоматическая реакция аудита безопасности (FAU_ARP)

3.2

Генерация данных аудита безопасности (FAU_GEN)

3.3

Анализ аудита безопасности (FAU_SAA)

3.4

Просмотр аудита безопасности (FAU_SAR)

3.5

Выбор событий аудита безопасности (FAU_SEL)

3.6

Хранение данных аудита безопасности (FAU_STG)

4

Класс FCO. Связь

4.1

Неотказуемость отправления (FCO_NRO)

4.2

Неотказуемость получения (FCO_NRR)

5

Класс FCS. Криптографическая поддержка

5.1

Управление криптографическими ключами (FCS_CKM)

5.2

Криптографические операции (FCS_COP)

6

Класс FDP. Защита данных пользователя

6.1

Политика управления доступом (FDP_ACC)

6.2

Функции управления доступом (FDP_ACF)

6.3

Аутентификация данных (FDP_DAU)

6.4

Экспорт данных за пределы действия ФБО (FDP_ETC)

6.5

Политика управления информационными потоками (FDP_IFC)

6.6

Функции управления информационными потоками (FDP_IFF)

6.7

Импорт данных из-за пределов действия ФБО (FDP_ITC)

6.8

Передача в пределах ОО (FDP_ITT)

6.9

Защита остаточной информации (FDP_RIP)

6.10

Откат (FDP_ROL)

6.11

Целостность хранимых данных (FDP_SDI)

6.12

Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)

6.13

Защита целостности данных пользователя при передаче между ФБО (FDP_UIT)

7

Класс FIA. Идентификация и аутентификация

7.1

Отказы аутентификации (FIA_AFL)

7.2

Определение атрибутов пользователя (FIA_ATD)

7.3

Спецификация секретов (FIA_SOS)

7.4

Аутентификация пользователя (FIA_UAU)

7.5

Идентификация пользователя (FIA_UID)

7.6

Связывание пользователь-субъект (FIA_USB)

8

Класс FMT. Управление безопасностью

8.1

Управление отдельными функциями ФБО (FMT_MOF)

8.2

Управление атрибутами безопасности (FMT_MSA)

8.3

Управление данными ФБО (FMT_MTD)

8.4

Отмена (FMT_REV)

8.5

Срок действия атрибута безопасности (FMT_SAE)

8.6

Роли управления безопасностью (FMT_SMR)

9

Класс FPR. Приватность

9.1

Анонимность (FPR_ANO)

9.2

Псевдонимность (FPR_PSE)

9.3

Невозможность ассоциации (FPR_UNL)

9.4

Скрытность (FPR_UNO)

10

Класс FPT. Защита ФБО

10.1

Тестирование базовой абстрактной машины (FPT_AMT)

10.2

Безопасность при сбое (FPT_FLS)

10.3

Доступность экспортируемых данных ФБО (FPT_ITA)

10.4

Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

10.5

Целостность экспортируемых данных ФБО (FPT_ITI)

10.6

Передача данных ФБО в пределах JJ (FPT_ITT)

10.7

Физическая защита ФБО (FPT_PHP)

10.8

Надежное восстановление (FPT_RCV)

10.9

Обнаружение повторного использования (FPT_RPL)

10.10

Посредничество при обращениях (FPT_RVM)

10.11

Разделение домена (FPT_SEP)

10.12

Протокол синхронизации состояний (FPT_SSP)

10.13

Метки времени (FPT_STM)

10.14

Согласованность данных ФБО между ФБО (FPT_TDC)

10.15

Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

10.16

Самотестирование ФБО (FPT_TST)

11

Класс FRU. Использование ресурсов

11.1

Отказоустойчивость (FRU_FLT)

11.2

Приоритет обслуживания (FRU_PRS)

11.3

Распределение ресурсов (FRU_RSA)

12

Класс FTA. Доступ к ОО

12.1

Ограничение области выбираемых атрибутов (FTA_LSA)

12.2

Ограничение на параллельные сеансы (FTA_MCS)

12.3

Блокирование сеанса (FTA_SSL)

12.4

Предупреждения перед предоставлением доступа к ОО (FTA_TAB)

12.5

История доступа к ОО (FTA_TAH)

12.6

Открытие сеанса с ОО (FTA_TSE)

13

Класс FTP. Доверенный маршрут/канал

13.1

Доверенный канал передачи между ФБО (FTP_ITC)

13.2

Доверенный маршрут (FTP_TRP)

 

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

Потребитель может управлять уровнем защищенности ИС, исходя из собственных предпочтений и рыночной стоимости реализации компонента защиты, а также бюджетных ограничений на стоимость системы защиты. Поведение потребителя м.б. описано с помощью математической модели, аналогично тому, как это делается в задачах микроэкономики [37, 38]. Помимо задачи выбора в предложенной математической модели [15] рассматриваются эффекты замены (замещения) наборов функциональных компонентов.

 

Литература.

 

1.                   ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. - Часть1. Введение и общая модель. – Госстандарт России, Москва, 2002.

2.                   ГОСТ Р ИСО/МЭК 15408-2-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. – Госстандарт России, Москва, 2002.

3.                   ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности. – Госстандарт России, Москва, 2002.

4.                   Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 1: Introduction and general model. – January 2004.

5.                   Рэдклифф Д. Одна мера безопасности на всех. – Computerworld, № 12, 2000.

6.                   Осовецкий Л. Г., Суханов А. В., Мануйлов Н. А. Общие Критерии: Реальность и мифы. Научно – технические аспекты.// 9 НТК «Майоровские чтения». Теория и технология программирования и защиты информации. Применение вычислительной техники - СПб. 2005. С. 3 – 5.

7.                   РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). – ФСТЭК России, 2005.

8.                   Кобзарь М., Сидак А. Стандартизация безопасности ИТ. Мир Связи. – №3, 2003.

9.                   Кобзарь М., Сидак А. Методология оценки безопасности информационных технологий по общим критериям. – JetInfo, № 6 (133), 2004.

10.               Towns M. L. Common Criteria Paradigm (CC) – Annual Computer Security Applications Conference, Sheraton New Orleans, Louisiana, USA, December 11 – 15, 2000.

11.                Бетелин В. В., Галатенко В. А., Кобзарь М.Т., Сидак А. А., Трифаленков И. А. Профили защиты на основе «Общих критериев». Аналитический обзор. Jet Info, Информационный бюллетень, №3(118), 2003.

12.                Шеин А. В. Об использовании "Общих критериев". – Инфофорум, 02.04.2004.

13.                РД Руководство по разработке профилей защиты и заданий по безопасности. Гостехкомиссия России, 2003.

14.                Афанасьев В. Н. Общие критерии безопасности информационных систем // Междун. студ. школа-семинар "Новые информационные технологии", г. Судак, 14 – 21 мая, 2003, Тезисы докладов XI в 2-х томах - М.: МГИЭМ, 2003.

15.                Суханов А. В. Формальные модели защищенности информационных технологий на основе общих критериев. Диссертация на соискание ученой степени кандидата технических наук. – СПб. 2006.

16.                Калайда И. А., Трубачев А. П. Современное состояние и направления совершенствования нормативной базы в области IT-безопасности. – Information Security/Информационная безопасность, № 3, 2004.

17.                Просяников Р. Е., Савельев М. С. Станут ли общими "Общие критерии". - BYTE, № 8, 2004.

18.                Jurjens J. Towards development of secure systems using UMLsec. In H. Hubmann, editor, Fundamental Approaches to Software Engineering (FASE/ETAPS, International Conference), volume 2029 of LNCS, pp. 187-200. Springer-Verlag, 2001.

19.                Jurjens J. UMLsec: Extending UML for Secure Systems Development, UML 2002, Dresden, Sept. 30 . Oct. 4, 2002, LNCS, Springer-Verlag.

20.                Jurjens J., Fernandez E. B., France R. B., and B. Rumpe editors. Critical systems development with UML (CSDUML 2004). TU Munchen Technical Report, 2004. UML 2004 satellite workshop proceedings.

21.                Federal Information Processing Standards Publication 183. Announcing the Standard for "Integration Definition for Function Modeling (IDEF0)". – 1993 December 21.

22.                Калянов A. Н., Козлинский А. В., Лебедев В. Н. Сравнительный анализ структурных методологий // Системы управления базами данных, № 05-06, 1997.

23.                Federal Information Processing Standards Publication 184. Announcing the Standard for “Integration Definition for Information Modeling (IDEF1X)”. – 1993 December 21.

24.                Information Integration for Concurrent Engineering (IICE). IDEF5 Method Report. – Knowledge Based Systems, Inc., 1408 University Drive East College Station, Texas, USA. – September 21, 1994.

25.                Unified Modeling Language Specification. Version 1.4.2. Formal/04-07-02, - OMG, July 2004.

26.                Stojanovic L., Schneider J., Maedche A., Libischer S., Studer R., Lumpp Th., Abecker A., Breiter G., Dinger J. The role of ontologies in autonomic computing systems. – IBM Systems Journal, vol 43, no 3, 2004.

27.                Виноградов А. Н., Осипов Г. С., Жилякова Л. Ю. Динамические интеллектуальные системы. Ч.2. Моделирование целенаправленного поведения // Известия АН. Теория и системы управления. – М: Наука, 2003, № 1. с.87 - 94.

28.                Калашник Е. О., Суханов А. В. Логический контроль использования Общих Критериев // В мат III Межвуз. конференции молодых ученных - СПб. 2006.

29.                Калашник Е. О., Осовецкий Л. Г., Суханов А. В. Комплекс логического контроля использования Общих Критериев. // В сб. Технологии Microsoft в теории и практике программирования. С.41 – 42.

30.                Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы. Весть - Метатехнология, 1999.

31.                Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. – М.: Весть-МетаТехнология, 2001.

32.                Судов Е. В., Левин А. И., Давыдов А. Н., Барабанов В. В. Концепция развития CALS-технологий в промышленности России. М.: НИЦ CALS-технологий "Прикладная логистика", 2002.

33.                Prieto-Diaz, R. The Common Criteria Evaluation Process. Process Explanation, Shortcomings, and Research Opportunities. - Commonwealth Information Security Center Technical Report CISC-TR-2002-03, December 2002 – CISC, James Madison University, USA.

34.                Любимов А. В. Функциональная структура общих критериев оценки безопасности информационных технологий. // Тр. 9-й НТК "Теория и технология программирования и защиты информации. Применение вычислительной техники" - Санкт-Петербург, 18 мая 2005г, с. 20 – 24.

35.                Николаев А. Ю., Любимов А. В., Суханов А. В. Автоматизация оценки объектов информатизации в соответствии с требованиями руководящих документов "Безопасность информационных технологий" Гостехкомиссии России. // IV Всероссийская конференция "Обеспечение информационной безопасности. Региональные аспекты."- Сочи. 2005. С. 27 – 31.

36.                ISO/IEC 17799:2005. Information technology – Security techniques – Code of practice for information security management (2nd edition). – ISO/IEC, 2005.

37.                Гальперин В. М., Игнатьев С. М., Моргунов В. И. Микроэкономика: В 2-х т. – СПб.: Экономическая школа, 1994. т. 1.

38.                Хикс Дж. Р., Аллен Р. Г. Д. Пересмотр теории ценности. Теория потребительского поведения и спроса. – СПб.: Экономическая школа, 1993, с. 117-141.

 

Поступила в редакцию 23.04.2008 г.

2006-2019 © Журнал научных публикаций аспирантов и докторантов.
Все материалы, размещенные на данном сайте, охраняются авторским правом. При использовании материалов сайта активная ссылка на первоисточник обязательна.