- •1.1. Введение. Понятие политики безопасности
- •Рис. 1. Основные каналы утечки информации при ее обработке на отдельной ПЭВМ
- •1.2. Модель компьютерной системы. Понятие доступа и монитора безопасности
- •Рис. 2. Порождения субъекта и понятие потока
- •Рис. 3. Примеры потоков в КС
- •1.3. Описание типовых политик безопасности
- •1.3.1. Модели на основе дискретных компонент
- •1.3.1.1. Модель АДЕПТ-50
- •1.3.1.2. Пятимерное пространство безопасности Хартстона
- •1.3.1.3. Резюме по моделям Адепт и Хартстона
- •1.3.2. Модели на основе анализа угроз системе
- •1.3.2.1. Игровая модель
- •1.3.2.2. Модель системы безопасности с полным перекрытием
- •1.3.2.3. Резюме по моделям анализа угроз
- •1.3.3. Модели конечных состояний.
- •1.3.3.1. Модель Белла-ЛаПадула.
- •1.3.3.2. Модель low-water-mark (LWM)
- •Таблица 1. Операции в модели LWM
- •1.3.3.3. Модель Лендвера
- •Определение 10
- •1.3.3.4. Резюме по моделям состояний
- •1.4. Обеспечение гарантий выполнения политики безопасности
- •Утверждение 1 (достаточное условие гарантированного выполнения политики безопасности в КС 1).
- •Утверждение 2 (достаточное условие гарантированного выполнения политики безопасности в КС 2).
- •Утверждение 3 (базовая теорема ИПС)
- •Рис. 5. Классическая модель ядра безопасности
- •Рис. 6. Ядро безопасности с учетом контроля порождения субъектов
- •1.5. Метод генерации изолированной программной среды при проектировании механизмов гарантированного поддержания политики безопасности
- •Таблица 2. Иерархия уровней при загрузке ОС
- •Утверждение 4 (условие одинакового состояния КС).
- •Утверждение 5 (достаточное условие ИПС при ступенчатой загрузке).
- •Утверждение 6 (требования к субъектному наполнению изолированной программной среды).
- •Утверждение 7 (достаточное условие чтения реальных данных).
- •1.6. Реализация гарантий выполнения заданной политики безопасности
- •Утверждение 8 (условия генерации ИПС при реализации метода доверенной загрузки).
- •1.7. Опосредованный несанкционированный доступ в компьютерной системе. Модель опосредованного НСД
- •Таблица 3. Полная группа событий в системе «ПП-РПВ»
- •Утверждение 9 (условия невозможности опосредованного НСД в ИПС).
- •Литература к первой части
- •Часть 2. Модели безопасного субъектного взаимодействия в компьютерной системе. Аутентификация пользователей. Сопряжение защитных механизмов
- •2.1. Введение
- •2.1. Процедура идентификации и аутентификации
- •Таблица 1. Объект-эталон для схемы 1
- •Таблица 2. Объект-эталон для схемы 2
- •Утверждение 1 (о подмене эталона).
- •2.2. Формализация задачи сопряжения. Методы сопряжения
- •Утверждение 2. (необходимое условие корректного взаимодействия сопрягаемых субъектов)
- •Утверждение 3. (о свойствах модуля сопряжения)
- •Рис. 1. Методы эмуляции органов управления и замены аутентифицирующего субъекта
- •2.3. Типизация данных, необходимых для обеспечения работы средств сопряжения
- •Таблица 3. Структура объекта вторичной аутентификации
- •Утверждение 4 (о свойствах объекта первичной аутентификации).
- •Утверждение 5 (об изменении информации пользователя в АНП).
- •2.4. Использование внешних субъектов при реализации и гарантировании политики безопасности
- •2.5. Понятие внешнего разделяемого сервиса безопасности. Постановка задачи
- •Рис. 2. Схема взаимодействия МРЗФ с МБО И МБС
- •2.6. Понятие и свойства модуля реализации защитных функций
- •Утверждение 6 (о потенциальной возможности некорректного возврата результата из МРЗФ)
- •Утверждение 7 (о потенциально возможном некорректном вызове МРЗФ)
- •2.7. Проектирование модуля реализации защитных функций в среде гарантирования политики безопасности
- •Утверждение 8 (достаточные условия корректного использования МРЗФ)
- •2.8. Передача параметров при составном потоке
- •Таблица 4. (Свойства составного потока при использовании МРЗФ)
- •2.9. Методика проверки попарной корректности субъектов при проектировании механизмов обеспечения безопасности с учетом передачи параметров
- •Заключение
- •Литература ко второй части
- •Часть 3. Управление безопасностью в компьютерной системе
- •3.1. Введение
- •3.2. Модель управления безопасностью. Термины
- •Утверждение 1 (о корректном управлении в ИПС).
- •Утверждение 2 (условия нарушения корректности управления).
- •Рис. 1. Локализация субъекта и объектов управления в распределенной КС
- •Таблица 1. (локализация управляющего субъекта и объекта управления)
- •3.3. Система удаленного управления безопасностью в отсутствии локального объекта управления
- •Утверждение 3 (необходимое условие 1 для создания системы корректного управления)
- •Утверждение 4 (необходимое условие 2 для создания системы корректного управления)
- •Утверждение 5
- •3.5. Метод “мягкого администрирования”. Автоматизированное формирование списков разрешенных задач и правил разграничения доступа
- •Утверждение 6 (лемма для обоснования метода мягкого администрирования)
- •3.6. Системы управления безопасностью при распределенном объекте управления
- •Утверждение 7 (условия корректности управления при мягком администрировании).
- •Заключение
- •Литература к третьей части
- •Часть 4. Модели сетевых сред. Создание механизмов безопасности в распределенной компьютерной системе
- •4.1. Введение
- •4.2.Модели воздействия внешнего злоумышленника на локальный сегмент компьютерной системы
- •Рис. 1. К моделям воздействия внешнего злоумышленника на локальный сегмент КС
- •4.3. Механизмы реализации политики безопасности в локальном сегменте компьютерной системы
- •Утверждение 1 (о распределенной КС с полным проецированием прав пользователя на субъекты).
- •Утверждение 2 (о доступе в системе с проецированием прав)
- •Таблица 1. Групповые правила разграничения доступа в ЛС КС
- •Таблица 2. Правила разграничения доступа при запрете транспортировки вовне избранных объектов
- •4.4. Метод межсетевого экранирования. Свойства экранирующего субъекта
- •Утверждение 3 (о существовании декомпозиции на подобъекты).
- •Утверждение 4 (Основная теорема о корректном экранировании).
- •Утверждение 6 (о тождестве фильтра сервисов и изолированной программной среды в рамках локального сегмента КС)
- •4.5. Модель политики безопасности в распределенной системе
- •4.6. Архитектура фильтрующего субъекта и требования к нему
- •Таблица 3. Показатели и классы защищенности межсетевого экрана
- •Заключение
- •Литература к четвертой части
- •Часть 5. Нормативные документы для решения задач компьютерной безопасности
- •Введение к пятой части
- •5.1.2. Структура требований безопасности
- •5.1.3. Показатели защищенности средств вычислительной техники от несанкционированного доступа
- •Таблица 1. Требования к защите от НСД СВТ
- •5.1.5. Классы защищенности автоматизированных систем
- •Таблица 2. Требования к защите от НСД АС
- •5.1.6. Выводы
- •5.2. Критерии безопасности компьютерных систем Министерства обороны США (“Оранжевая книга”)
- •5.2.1. Цель разработки
- •5.2.2. Общая структура требований «Оранжевой книги»
- •5.2.3. Классы безопасности компьютерных систем
- •Таблица 3. Требования «Оранжевой книги»
- •5.2.4. Интерпретация и развитие “Оранжевой книги”
- •5.2.5. Выводы
- •5.3. Европейские критерии безопасности информационных технологий
- •5.3.1. Основные понятия
- •5.3.2. Функциональные критерии
- •5.3.3. Критерии адекватности
- •5.3.4. Выводы
- •5.4. Федеральные критерии безопасности информационных технологий
- •5.4.1. Цель разработки
- •5.4.2. Основные положения
- •5.4.3. Профиль защиты
- •Назначение и структура Профиля защиты
- •Этапы разработки Профиля защиты
- •5.4.4. Функциональные требования к продукту информационных технологий
- •Таблица 4. Применение критериев ранжирования
- •5.4.5. Требования к процессу разработки продукта информационных технологий
- •5.4.6. Требования к процессу сертификации продукта информационных технологий
- •5.4.7. Выводы
- •Литература к пятой части
- •Заключение. Процесс построения защищенной компьютерной системы
- •Рис. 1. Взаимосвязь методов проектирования защищенной КС.
- •Список сокращений
-156-
Политика аóäèòа |
|
|
|
|
Идентификация и |
|
|
* |
* |
аутентификация |
|
|
|
|
Регистрация в системе |
|
|
* |
|
Обеспечение прямого |
* |
|
* |
|
взаимодействия с ßÇ |
|
|
|
|
Регистрация и учет событий |
|
|
* |
* |
Политика управления |
* |
* |
* |
|
доступом |
|
|
|
|
Контроль скрытых каналов |
* |
|
* |
|
Политика обеспечения |
|
|
|
|
работоспособности |
|
|
|
|
Контроль за распределением |
* |
|
* |
|
ресурсов |
|
|
|
|
Отказоустойчивость |
- |
- |
- |
- |
Управление безопасностью |
|
|
* |
* |
Мониторинг взаимодействий |
* |
* |
* |
|
Логическая защита ßÇ |
|
|
* |
|
Физическая защита ßÇ |
|
|
* |
* |
Самоконтроль ßÇ |
* |
|
* |
|
Инициализация и |
|
|
* |
|
восстановление ßÇ |
|
|
|
|
Ограничение привилегий при |
|
* |
|
|
работе с ßÇ |
|
|
|
|
Простота использования ßÇ |
* |
|
* |
|
5.4.5. Требования к процессу разработки продукта информационных технологий
Основное назначение требований к технологии разработки ПИТ — обеспечить адекватность условий разработки функциональным требованиям, выдвинутым в соответствующем разделе Профиля защиты, и установить ответственность разработчика за корректность реализации этих требований. Данный раздел регламентирует процесс создания, тестирования, документирования и сопровождения ПИТ. Требования к технологии разработки ПИТ включают четыре раздела: требования к процессу разработки, к среде разработки, документированию и сопровождению.
Требования к процессу разработки содержат подразделы, относящиеся к проектированию, реализации, тестированию и анализу ПИТ. Особую роль играют требования адекватности реализации функций ßÇ, обеспечивающие корректность выполнения функциональных требований Профиля защиты.
Требования к среде разработки позволяют обеспечить качество процесса создания ПИТ с помощью применения современных технологий проектирования, программирования и тестирования, а также регламентируют управление процессом разработки и дистрибуцию конечного продукта.
-157-
Требования к документированию определяют состав и содержание технологической документации, позволяющей производителю ПИТ доказать соответствие самого продукта и технологии его изготовления выдвинутым требованиям.
Требования к сопровождению ПИТ содержат обязательства производителя перед пользователями, выполнение которых позволяет обеспечить эффективную и надежную эксплуатацию ПИТ. Данные требования регламентируют состав пользовательской и административной документации, процедуру обновления версий и исправления ошибок, а также инсталляцию продукта.
“Федеральные критерии” содержат ранжированный перечень типовых требований к технологии разработки ПИТ [17]. Выполнение требований к технологии разработки является необходимым условием для проведения процедуры сертификации.
5.4.6.Требования к процессу сертификации продукта информационных технологий
Требования к процессу сертификации ПИТ призваны обеспечить надежность и корректность процесса анализа ПИТ на соответствие выдвинутым функциональным требованиями и требованиям к технологии разработки. Раздел содержит три группы требований, регламентирующих анализ, контроль
итестирование ПИТ. Раздел требований к анализу ПИТ содержит требования к проведению независимого анализа предложенного решения (архитектуры) и его реализации как конкретного средства.
Раздел требований к контролю регламентирует проверку соответствия среды разработки ПИТ и обеспечиваемого производителем сопровождения требованиям к технологии разработки.
Требования к тестированию описывают процедуру проведения тестирования функций ßÇ как самим разработчиком ПИТ, так и независимыми экспертами.
Эти требования регламентируют процесс сертификации только в общих чертах и, по замыслу разработчиков стандарта, должны послужить основой для разработки специализированных методик сертификации, ориентированных на различные области применения и классы ПИТ.
5.4.7.Выводы
“Федеральные критерии безопасности информационных технологий” являются первым стандартом в области безопасности систем обработки информации, в котором определены и рассмотрены три независимые группы требований: функциональные требования к средствам защиты, требования к технологии разработки и к процессу сертификации. Авторами этого документа предложена концепция Профиля защиты — документа, содержащего полное описание всех требований безопасности, к процессу разработки, сертификации и эксплуатации ПИТ.
-158-
Функциональные требования к средствам защиты четко структурированы и описывают все аспекты функционирования ßÇ. Требования к технологии разработки, впервые появившиеся в этом документе, позволяют разработчикам использовать современные технологии программирования в качестве основы для подтверждения безопасности своего продукта. Требования к процессу сертификации носят довольно общий характер и не содержат конкретных методик тестирования и исследования ПИТ.
Разработчики “Федеральных критериев” отказались от используемого в “Оранжевой книге” подхода к оценке уровня безопасности ПИТ путем введения обобщенной универсальной шкалы классов безопасности. Вместо этого предлагается независимое ранжирование требований по каждой группе, т.е. вместо одной шкалы используется множество частных критериев, характеризующих обеспечиваемый уровень безопасности. Данный подход позволяет разработчикам и пользователям ПИТ выбрать наиболее приемлемое решение и определить необходимый и, в ряде случаев, достаточный набор требований для каждого конкретного случая.
Литература к пятой части
1.Зегжда Д.П., Ивашко А.М. Как построить защищенную информационную систему? Под научной ред. Зегжды Д.П. и Платонова В.В. -
Спб: Мир и семья-95, 1997 - 312 стр., с илл. ISBN-88857-010Х.
2.Гостехкомиссия России. Руководящий документ. Концепция защиты средств вычислительной техники от несанкционированного доступа к информации. М.: Военное издательство, 1992.
3.Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. М.: Военное издательство, 1992.
4.Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. М.: Военное издательство, 1992.
5.Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от несанкционированного доступа в автоматизированных системах и средствах вычислительной техники. М.: Военное издательство, 1992.
6.Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. М.: Военное издательство, 1992.
7.Trusted Computer System Evaluation Criteria. US Department Of Defense. CSC-STD-00l-83, Aug. 1983.
8.Trusted Network Interpretation. National Computer Security Center. NCSC- TG-005 Version 1, July 1987.
-159-
9.Trusted Database Management System Interpretation. National Computer Security Center. NCSC-TG-021 Version 1, April 1991.
10.A guide to understanding discretionary access control in trusted systems. National Computer Security Center. NCSC-TG-003 Version 1, September 1987.
11.Password management guideline. US Department Of Defense. CSC-STD- 002-85, April 1985.
12.Guidance for applying the Department Of Defense Trusted Computer System Evaluation Criteria in specific environment. US Department Of Defense. CSC-STD- 003-85, June 1985.
13.A Guide to Understanding Audit in Trusted Systems. National Computer Security Center. NCSC-TG-001, July 1987.
14.Guide to understanding configuration management in trusted systems. National Computer Security Center. NCSC-TG-006-88, March 1988.
15.The Interpreted Trusted Computer System Evaluation Criteria Requirements. National Computer Security Center. NCSC-TG-00?-95, Jan. 1995.
16.Information Technology Security Evaluation Criteria. Harmonized Criteria
Of France-Germany-Netherlands-United Kingdom. - Department Of Trade and Industry. London, 1991.