- •Учебное пособие
- •Аннотация
- •Список сокращений
- •Содержание
- •Введение
- •Научные и технические предпосылки кризисной ситуации.
- •Бурное развитие программного обеспечения.
- •Понятие «защищенная система».
- •1. Основные понятия и определения предмета защиты информации
- •1.1. Общее содержание проблемы информационной безопасности
- •1.2 Информация и информационные отношения. Субъекты информационных отношений
- •1.3. Ценность информации
- •1.4. Модель решетки ценностей
- •1.5. Mls решетка
- •1.6. Определение требований к защищенности информации
- •1.7. Критерии, условия и принципы отнесения информации к защищаемой. Виды конфиденциальной информации.
- •1.8. Выводы
- •1.9. Вопросы для самоконтроля
- •Угрозы информации, методология их выявления и оценки
- •2.1. Санкционированный и несанкционированный доступ
- •2.2. Угрозы информации, методология их выявления и оценки
- •2.3. Ретроспективный анализ подходов к формированию множества угроз информации
- •2.4. Цели и задачи оценки угроз информации в современных системах ее обработки
- •2.5. Система показателей уязвимости информации
- •2.6. Классификация и содержание угроз информации
- •2.7. Методы и модели оценки уязвимости информации
- •2.8. Выводы
- •2.9. Вопросы для самоконтроля
- •3. Общая классификация защитных мер
- •3.1. Базовые свойства безопасности информации. Каналы реализации угроз
- •3.2. Основные принципы обеспечения информационной безопасности
- •3.3. Меры обеспечения безопасности компьютерных систем
- •3.4. Характеристика способов защиты компьютерной информации с помощью аппаратно-программных мер
- •3.5. Выводы
- •3.6. Вопросы для самоконтроля
- •4. Идентификация и аутентификация субъектов
- •4.1. Классификация подсистем идентификации и аутентификации субъектов
- •4.2. Парольные системы идентификации и аутентификации пользователей
- •4.3. Идентификация и аутентификация с использованием индивидуальных биометрических характеристик пользователя
- •4.4. Выводы
- •4.5. Вопросы для самоконтроля
- •5. Элементы теории чисел
- •5.1. Модулярная арифметика
- •5.2. Простые числа и их свойства
- •5.3. Числовые функции
- •5.4. Выводы
- •5.5. Вопросы для самоконтроля
- •6. Методы и средства криптографической защиты
- •6.1. Принципы криптографической защиты информации
- •6.2. Традиционные симметричные криптосистемы
- •6.2.1. Шифрование методом замены
- •6.2.2. Шифрование методами перестановки
- •6.2.3. Шифрование методом гаммирования
- •6.3. Элементы криптоанализа
- •6.4. Современные симметричные системы шифрования
- •6.4.1. Стандарт шифрования des (сша)
- •6.4.2. Отечественный стандарт симметричного шифрования
- •6.5. Асимметричные криптосистемы
- •6.5.1. Недостатки симметричных криптосистем и принципы асимметричного шифрования
- •6.5.2. Однонаправленные функции
- •6.5.3. Алгоритм шифрования rsa
- •6.6. Выводы
- •6.7. Вопросы для самоконтроля
- •7. Контроль целостности информации. Электронно-цифровая подпись
- •7.1. Проблема обеспечения целостности информации
- •7.2. Функции хэширования и электронно-цифровая подпись
- •7.3. Выводы
- •7.4. Вопросы для самоконтроля
- •8. Протоколы безопасной аутентификации пользователей
- •8.1. Аутентификация на основе сертификатов
- •8.2. Процедура «рукопожатия»
- •8.3. Протокол Диффи-Хеллмана
- •8.4. Выводы
- •8.5. Вопросы для самоконтроля
- •9. Управление носителями конфиденциальной информации и внесением изменений.
- •9.1. Носители информации как объект защиты
- •9.2 Разделение тестовой среды и среды промышленной эксплуатации информационной системы. Процесс управления изменениями.
- •9.3. Выводы
- •9.4. Вопросы для самоконтроля
- •10. Разграничение доступа к информации в компьютерных системах
- •10.1. Модели разграничения доступа к информации
- •10.2. Субъектно-объектная модель компьютерной системы в механизмах и процессах коллективного доступа к информационным ресурсам
- •10.2. Монитор безопасности и основные типы политик безопасности
- •10.3. Гарантирование выполнения политики безопасности
- •10.4. Выводы
- •10.5. Вопросы для самоконтроля
- •11. Политики безопасности
- •11.1. Формальные и неформальные политики безопасности
- •11.2. Формальные методы анализа систем
- •11.3. Характеристика моделей безопасности
- •11.4. Выводы
- •11.5. Вопросы для самоконтроля
- •12. Модели безопасности
- •12.1. Модели разграничения доступа
- •12.2. Модели дискреционного доступа
- •12.2.1. Модель дискреционного доступа адепт-50.
- •12.2.2. Пятимерное пространство Хартсона
- •12.2.3. Модель Харрисона-Руззо-Ульмана
- •12.3. Модели мандатного доступа
- •12.3.1. Модель Белла и Лападула
- •12.4. Специализированные модели
- •12.4.1. Модель mms
- •12.5. Проблемы моделей предоставления прав
- •12.6. Информационные модели
- •12.6.1. Модель невмешательства
- •12.6.2. Модель невыводимости
- •12.7. Вероятностные модели
- •12.7.1. Игровая модель
- •12.7.2.Модель системы безопасности с полным перекрытием
- •12.8 .Модели контроля целостности
- •12.8.1. Модель Биба
- •12.8.2. Модель Кларка-Вилсона
- •12.9. Механизмы защиты от угрозы отказа в обслуживании
- •12.9.1. Основные понятия ово
- •12.9.2. Мандатная модель ово
- •12.9.3. Модель Миллена распределения ресурсов (мрр)
- •12.10. Выводы
- •12.11. Вопросы для самоконтроля
- •13. Обзор и сравнительный анализстандартов информационной безопасности
- •13.1. Основные понятия и определения
- •13.2. Критерии безопасности компьютерных систем министерства обороны сша ("Оранжевая книга")
- •13.2.1. Таксономия требований и критериев "Оранжевой книги"
- •13.2.2. Классы безопасности компьютерных систем
- •13.2.3. Интерпретация и развитие "Оранжевой книги"
- •13.3. Европейские критерии безопасности информационных технологий
- •13.3.1. Основные понятия
- •13.3.2. Функциональные критерии
- •13.3.3. Критерии адекватности
- •13.4. Руководящие документы Гостехкомиссии России
- •13.4.1. Основные положения
- •13.4.2. Концепция защиты свт и ас от нсд к информации
- •13.4.3. Показатели защищенности средств вычислительной техники от нсд
- •13.4.4. Показатели защищенности автоматизированных систем от нсд
- •13.5. Федеральные критерии безопасности информационных технологий
- •13.5.1. Цель разработки
- •13.5.2. Основные положения
- •13.5.3. Профиль защиты
- •13.5.4. Этапы разработки Профиля защиты
- •13.5.5. Функциональные требования к ит–продукту
- •13.5.6. Таксономия функциональных требований
- •13.5.7. Ранжирование функциональных требований
- •13.5.8. Требования к технологии разработки ит–продукта
- •13.5.9. Требования к процессу квалификационного анализа ит-продукта
- •13.6. Единые критерии безопасности информационных технологий
- •13.6.1. Цель разработки
- •13.6.2. Основные положения
- •13.6.3. Профиль защиты
- •13.6.4. Проект защиты
- •13.6.5. Требования безопасности
- •13.6.6. Функциональные требования
- •13.6.7. Требования адекватности
- •13.7. Анализ стандартов информационной безопасности
- •13.8. Выводы
- •13.9. Вопросы для самоконтроля
- •Список литературы
- •420111, Г. Казань, ул. К.Маркса, 10
13.6.7. Требования адекватности
Требования адекватности "Единых критериев" жестко структурированы и регламентируют все этапы проектирования, создания и эксплуатации ИТ–продукта с точки зрения обеспечения надежности работы средств защиты и их адекватности функциональным требованиям, задачам защиты и угрозам безопасности, действующим в среде эксплуатации ИТ–продукта.
Таксономия требований адекватности "Единых критериев" представлена на рис. 3.16.
Ранжирование требований адекватности представлено в виде упорядоченных списков. Критерии адекватности используются в ходе квалификационного анализа ИТ–продукта для определения степени корректности реализации функциональных требований и назначения ИТ–продукту соответствующего уровня адекватности. Для этого "Единые критерии" предлагают семь стандартных уровней адекватности, жесткость требований адекватности возрастает от первого уровня к седьмому. Каждый уровень характеризуется набором требований адекватности, регламентирующих применение различных методов и технологий разработки, тестирования, контроля и верификации, ИТ–продукта:
Уровень 1. Функциональное тестирование.
Уровень 2. Структурное тестирование.
Уровень 3. Методическое тестирование и проверка.
Уровень 4. Методическая разработка, тестирование и анализ.
Уровень 5. Полуформальные методы разработки и тестирование.
Уровень 6. Полуформальные методы верификации разработки и тестирование.
Уровень 7. Формальные методы верификации разработки и тестирование.
Кратко охарактеризуем каждый уровень адекватности с точки зрения области его применения, условий разработки, уровня проводимого анализа, состава материалов, подтверждающих результаты анализа, и проследим усиление требований от уровня к уровню.
Уровень 1. Функциональное тестирование предназначено для тех случаев, когда угрозам безопасности не придается большого значения. Предлагается использовать его в тех ситуациях, когда все что требуется – это независимая гарантия того, что в состав продукта входят средства за щиты персональной или подобной информации, реализованные в соответствии с указанными требованиями.
Рис. 3.16. Таксономия требований адекватности «Единых критериев»
Анализ ИТ–продукта на соответствие данному уровню адекватности ограничивается исследованием функций защиты и проверкой функциональных спецификаций, интерфейсов и документации.
Результаты анализа подтверждаются независимым тестированием средств защиты ИТ–продукта на соответствие спецификациям и документации.
Сертификация ИТ–продукта на данный уровень адекватности является подтверждением соответствия свойств ИТ–продукта его документации и спецификациям, а также наличия работоспособной защиты против угроз безопасности.
Уровень 2. Структурное тестирование используется тогда, когда пользователи или разработчики согласны удовлетвориться низкой или умеренной степенью независимого подтверждения адекватности обеспечиваемого уровня безопасности. Особо рекомендуется применять требования данного уровня для унаследованных систем, уже находящихся в эксплуатации.
Разработка продукта в соответствии с требованиями данного уровня не требует от производителя никаких дополнительных затрат, по сравнению с разработкой обычных коммерческих или промышленных продуктов, кроме предоставления результатов тестирования.
Для этого уровня анализ должен проводиться не в отношении функциональных спецификаций, интерфейсов и документации, но и для архитектуры защиты ИТ–продукта.
Кроме независимого тестирования средств защиты ИТ–продукта результаты анализа подтверждаются протоколами тестирования функциональных спецификаций, представленными разработчиком, а также независимым выборочным контролем результатов этих испытаний и глубины проведенного тестирования, и независимым подтверждением поиска разработчиком явных уязвимостей. Кроме того, для этого уровня требуется наличие документированного состава конфигурации продукта и доказательство безопасности процедуры поставки.
Данный уровень расширяет требования предыдущего за счет включения в материалы, подтверждающие анализ, результатов тестов, проведенных разработчиком ИТ–продукта, необходимостью осуществления анализа уязвимостей и независимого тестирования с использованием более детальных спецификаций.
Уровень 3. Методическое тестирование применяется тогда, когда потребителям или пользователям требуются умеренная степень независимого подтверждения свойств ИТ–продукта, а также полное и последовательное исследование свойств продукта и контроль в процессе создания, но без проведения дорогостоящего обратного проектирования (reengineering).
Этот уровень позволяет получить максимальной степени адекватности, не требующий никаких изменений в обычную процедуру разработки, поскольку все регламентированные им меры, направленные на обеспечение адекватности, применяются на этапе проектирования.
Для этого уровня проводятся те же виды анализа, что и для уровня 2, но в дополнение к материалам тестирования спецификаций функций зашиты от разработчика требуется предоставление результатов тестирования архитектуры защиты ИТ–продукта. Требования к процессу создания продукта дополняются использованием средств управления конфигурацией проекта.
Уровень расширяет требования предыдущего за счет более полного тестирования функций защиты и средств их реализации, а также применением мер, дающих определенную уверенность в том, что ИТ–продукта не был подменен в процессе разработки.
Уровень 4. Уровень методической разработки, тестирования и анализа применим в тех обстоятельствах, когда разработчики или пользователи требуют умеренную или высокую степень независимого подтверждения адекватности защиты ИТ–продукта и готовы нести определенные дополнительные технические затраты.
Этот уровень, несмотря на достаточно сильные требования, не требует от разработчика специальных знаний в области разработки защищенных систем и применения специальных, методов и технологий отличающихся от общепринятых. Это наивысший уровень адекватности, на который можно рассчитывать без дополнительных экономических затрат.
В отличие от предыдущих уровней для сертификации продукта на четвертый уровень адекватности анализу подвергаются все интерфейсы без исключения, все частные спецификации, а также детали реализации средств защиты. Кроме того должна быть предоставлена неформальная модель политики безопасности.
В дополнение к предыдущему уровню результаты анализа подтверждаются независимым исследованием уязвимостей средств защиты, демонстрирующим стойкость системы против слабых атак. Требования к процессу создания продукта расширяются дополнительными требованиями применения автоматизированных средств управления конфигурацией.
Данный уровень отличается от предыдущего ужесточением требований к процессу проектирования и разработки, а также усилением мер, гарантирующих, что ИТ–продукт не был подменен в процессе создания.
Уровень 5. Полуформальные методы разработки и тестирование рекомендуется применять в том случае, когда разработчики или пользователи требуют высокой степени независимого подтверждения адекватности средств зашиты, а также строгого применения определенных технологий разработки ИТ–продукта, но без чрезмерных затрат.
Этот уровень требует от разработчика применения определенных технологий и методов разработки, однако, их использование может ограничиваться проектированием и реализацией средств защиты.
В отличие от предыдущих уровней анализу подвергаются все средства защиты без исключения. Кроме того, требуется наличие формальной модели политики безопасности и полуформальное представление функциональных спецификаций и архитектуры защиты, а также, полуформальная демонстрация их взаимного соответствия. Архитектура ИТ–продукта должна отвечать требованиям модульности.
В дополнение к предыдущим уровням для подтверждения результатов анализа требуется тестирование разработчиком частных спецификаций, а анализ уязвимостей должен демонстрировать стойкость против атак умеренной силы. Кроме того, требуется независимая проверка проведенного разработчиком анализа скрытых каналов.
Требования к процессу разработки дополняются необходимостью расширения состава конфигурации продукта, управляемой с помощью автоматических средств.
Таким образом, этот уровень усиливает требования предыдущего в части полуформального описания процесса проектирования и реализации, более структурированной архитектуры защиты, более тщательного анализа скрытых каналов, более полного контроля в процессе разработки.
Уровень 6. Полуформальные методы верификации, разработки и тестирование применяются при разработке защищенных продуктов, предназначенных для использования в ситуациях с высокой степенью риска, где ценность защищаемой информации оправдывает дополнительные затраты.
Данный уровень требует строгого и последовательного применения определенных методов проектирования и разработки, позволяющих обеспечивать адекватность защиты при эксплуатации в условиях повышенного риска.
Требования этот уровня дополняют предыдущие необходимостью структурного описания реализации продукта и полуформального представления частных спецификаций, а также требованием многоуровневой архитектуры.
Для подтверждения результатов анализа кроме мер, предусмотренных уровнем 5, анализ уязвимостей должен демонстрировать стойкость системы против сильных атак, и должны быть получены независимые подтверждения проведения разработчиком систематического поиска скрытых каналов.
Требования к процессу разработки расширяются необходимостью структурирования этого процесса и полной автоматизации управления конфигурацией проекта.
Уровень расширяет требования предыдущего применением более глубокого анализа, структуризацией представления ИТ–продукта, многоуровневой архитектурой, усилением анализа уязвимостей, применением систематического поиска скрытых каналов, а также усовершенствованным управлением конфигурацией и среды разработки.
Уровень 7. Формальные методы верификации, разработки и тестирование могут быть использованы для разработки защищенных продуктов, предназначенных для использования в ситуациях с исключительно высокой степенью риска, и/или там, где ценность защищаемых объектов оправдывает высокие дополнительные затраты. Практическое применение этого уровня в настоящее время ограничено компактными продуктами, в которых сконцентрированы средства защиты, и которые легко поддаются формальному анализу.
В отличие от предыдущих уровней требуется формальное представление функциональных спецификаций и архитектуры защиты, а также формальная и полуформальная демонстрация соответствия между ними. Архитектура системы должна быть не только модульной, но и простой и ясной.
В дополнение к предыдущим уровням результаты анализа подтверждаются тестированием формы реализации, а также обоснованным независимым подтверждением всех результатов проведенных разработчиком испытаний.
Таким образом, этот уровень усиливает требования предыдущего за счет более последовательного анализа с использованием формального описания системы на различных уровнях представления и формального доказательства взаимного соответствия этих описаний, а также всеобъемлющего тестирования.
"Единые критерии безопасности информационных технологий" представляют собой результат обобщения всех достижений последних лет в области информационной безопасности. Впервые документ такого уровня содержит разделы, адресованные потребителям, производителям и экспертам по квалификации ИТ–продуктов.
Предложенные "Едиными критериями" механизмы Профиля защиты и Проекта защиты позволяют потребителям и производителям в полной мере выразить свой взгляд на требования безопасности и задачи защиты, а с другой стороны дают возможность экспертам по квалификации проанализировать взаимное соответствие между требованиями, нуждами потребителей, задачами защиты и средствами защиты ИТ–продукта. В отличие от Профиля защиты "Федеральных критериев", который ориентирован исключительно на среду применения ИТ–продукта, Профиль защиты "Единых критериев" предназначен непосредственно для удовлетворения запросов потребителей.
Разработчики "Единых критериев" продолжили подход "Федеральных критериев", направленный на отказ от единой шкалы безопасности, и усилили гибкость предложенных в них решений путем введения частично упорядоченных шкал, благодаря чему потребители и производители получили дополнительные возможности по выбору требований и их адаптации к свои прикладным задачам.
Особое внимание этот стандарт уделяет адекватности реализации функциональных требований, которая обеспечивается как независимым тестированием и анализом ИТ–продукта, так и применением соответствующих технологий на всех этапах его проектирования и реализации.
Таким образом, требования "Единых критериев" охватывают практически все аспекты безопасности ИТ–продуктов и технологии их создания, а также содержат все исходные материалы, необходимые потребителям и разработчикам для формирования Профилей и Проектов защиты.
Кроме того, требования "Единых критериев" являются практически всеобъемлющей энциклопедией информационной безопасности, поэтому их можно использовать в качестве справочника по безопасности информационных технологий.
Данный стандарт ознаменовал собой новый уровень стандартизации информационных технологий, подняв его на межгосударственный уровень. За этим проглядывается реальная перспектива создания единого безопасного информационного пространства, в котором сертификация безопасности систем обработки информации будет осуществляться на глобальном уровне, что предоставит возможности для интеграции национальных информационных систем, что в свою очередь откроет совершенно новые сферы применения информационных технологий. Остается только посетовать, что наша страна, как всегда, осталась в стороне этого процесса.
С 2004 года в России введен ГОСТ Р МЭК/ИСО 15408, определяющий критерии оценки безопасности ИТ и являющийся адаптированным к Российским условиям аналогом стандарта ISO/IEC 15408 – единых критериев безопасности ИТ (ОК). Он является действующим наряду с ранее изданными РД ГосТехКомиссии, определяющими критерии оценки безопасности средств вычислительной техники и автоматизированных систем.