Содержание
Введение
Глава 1
Проблемы создания защищенных информационных систем
1.1. Актуальность защиты систем обработки информации
1.2. Предпосылки кризиса обеспечения безопасности компьютерных систем
1.3. Задачи данной книги
1.4. Структура данной книги
1.5. Заключение к главе 1
Литература к главе 1
Глава 2
Обзор и сравнительный анализ стандартов информационной безопасности
2.1. Введение
2.2. Основные понятия и определения
2.3. Угрозы безопасности компьютерных систем
2.4. Роль стандартов информационной безопасности
2.5 Критерии безопасности компьютерных систем министерства обороны США («Оранжевая книга»)
2.5.1. Цель разработки
2.5.2. Таксономия требовании и критериев «Оранжевой книги»
2.5.2.1. Политика безопасности
2.5.2.2. Аудит
2.5.2.3. Корректность
2.5.2.4. Таксономия критериев безопасности
2.5.3. Классы безопасности компьютерных систем
2.5.4. Интерпретация и развитие «Оранжевой книги»
2.5.5. Выводы
2.6. Европейские критерии безопасности информационных технологий.
2.6.1. Основные понятия
2.6.2. Функциональные критерии
2.6.3. Критерии адекватности
2.6.4. Выводы
2.7. Руководящие документы Гостехкомиссии России.
2.7.1. Основные положения
2.7.2. Таксономия критериев и требований безопасности
2.7.2.1. Показатели защищенности СВТ от НСД
2.7.2.2. Требования к защищенности aвтоматизированных систем
2.7.3. Классы защищенности автоматизированных систем
2.7.4. Выводы
2.8. Федеральные критерии безопасности информационных технологий
2.8.1. Цель разработки
2.8.2. Основные положения
2.8.3. Профиль защиты
2.8.3.1. Назначение и структура профиля защиты
2.8.3.2 Этапы разработки профиля защиты
2.8.4. Функциональные требования к ИТ-продукту
2.8.4.1. Таксономия функциональных требований
2.8.4.2. Ранжирование функциональных требований
2.8.5. Требования к технологии разработки ИТ-продукта
2.8.6. Требования к процессу квалификационною анализа ИТ-продукта
2.8.7. Выводы
2.9. «Канадские критерии безопасности компьютерных систем»
2.9.1. Цель разработки
2.9.2. Базовые понятия «Канадских критериев»
2.9.2.1 Объекты и субъекты
2.9.2.2. Теги
2.9.3. Основные положения и структура «Канадских критериев»
2.9.4. Выводы
2.10. Единые критерии безопасности информационных технологий
2.10.1. Цель разработки
2.10.2. Основные положения
2.10.2.1. Профиль защиты
2.10.2.2. Проект защиты
2.10.3. Требования безопасности
2.10.3.1 Функциональные требования.
2.10.3.2. Требования адекватности
2.10.4. Выводы
2.11. Анализ стандартов информационной безопасности
2.11.1. Универсальность
2.11.2. Гибкость
2.11.3. Гарантированность
2.11.4. Реализуемость
2.11.5. Актуальность
2.12. Заключение
Литература к главе 2
Глава 3
Исследование причин нарушений безопасности ВС
3.1. Нарушения безопасности ВС и изъяны защиты
3.2. Исследования нарушений безопасности компьютерных систем
3.3. Таксономия ИЗ
3.3.1. Классификация ИЗ по источнику появления
3.3.1.1. Преднамеренно внедренные ИЗ с наличием деструктивных функций
3.3.1.2. Преднамеренно внедренные ИЗ без деструктивных функций
3.3.1.3. Непреднамеренные ошибки и ИЗ
3.3.2. Классификация ИЗ по этапу возникновения
3.3.2.1. Возникновение ИЗ в процессе разработки системы
3.3.2.1.1. Составление требований и спецификаций
3.3.2.1.2. Создание исходных текстов программ
3.3.2.1.3. Генерация исполняемого кода
3.3.2.2. Возникновение ИЗ в процессе сопровождения и развития системы
3.3.2.3. Возникновение ИЗ в процессе функционирования системы
3.3.3. Классификация ИЗ по размещению в системе
3.3.3.1. Системное программное обеспечение
3.3.3.2. Сервисное программное обеспечение
3.3.3.3. Прикладное программное обеспечение
3.3.4. Результаты исследования таксономии ИЗ и их практическое применение
3.4. Исследование причин возникновения ИЗ
3.4.1. Таксономия причин возникновения ИЗ
3.4.2. Взаимосвязь таксономии причин нарушения безопасности и классификации ИЗ
3.5 Заключение
Литература к главе 3
Приложение I
Ранжированные функциональные требования «Федеральных критериев безопасности информационных технологий»
1. Идентификация и аутентификация
2. Регистрация пользователя в системе
3. Обеспечение прямого взаимодействия с ТСВ
5. Политика управления доступом (произвольное и нормативное управление доступом)
6. Контроль скрытых каналов
7. Контроль за распределением ресурсов
8. Политика управления безопасностью
9. Мониторинг взаимодействий
10. Логическая защита ТСВ
11. Физическая защита ТСВ
12. Самоконтроль ТСВ
14. Ограничение привилегий при работе с ТСВ
15. Простота использования ТСВ
Приложение II
Ранжированные требования «Канадских критериев безопасности компьютерных систем»
1. Критерии конфиденциальности
1.1. Контроль скрытых каналов
1.2. Произвольное управление доступом
1.3. Нормативное управление доступом
1.4. Повторное использование объектов
2. Критерии целостности
2.1. Домены целостности
2.2. Произвольное управление целостностью
2.3. Нормативное управление целостностью
2.4. Физическая целостность
2.5. Возможность осуществления отката
2.6. Разделение ролей
2.7. Самотестирование
3. Критерии работоспособности
3.1. Контроль за распределением ресурсов
3.2. Устойчивость к отказам и сбоям
3.3. Живучесть
3.4. Восстановление
4. Критерии аудита
4.1. Регистрация и учет событий в системе
4.2. Идентификация и аутентификация
4.3. Прямое взаимодействие с ТСВ
5. Критерии адекватности реализации
Приложение III.
Ранжированные требования «Единых критериев безопасности информационных технологий»
Приложение IV
Статистика нарушений безопасности компьютерных систем
Введение
Проблемами обеспечения информационной безопасности занимаются многие организации, однако среди них очень немногие проводят научные исследования в области современных технологий обеспечения безопасности.
Именно такой подход развивается в Специализированном центре защиты информации Санкт-Петербургского государственного технического университета, объединяющим научных сотрудников и преподавателей, последовательно реализующих системный подход к проблемам безопасности, базирующийся на анализе современных достижений в этой области. Результаты этой деятельности отражены в целой серии книг сотрудников Центра, посвященных различным аспектам проблемы информационной безопасности — от компьютерных вирусов до информационных атак в Internet.
Данная постановка своей попыткой комплексного решения поставленной проблемы является новой Для отечественной литературы, посвященной данному вопросу и систематизирует мировой опыт в области обеспечения безопасности информационных технологий и создания защищенных систем обработки информации. Авторы ставили своей целью определить пути и методы создания подобных систем и решить возникающие при этом проблемы. Книга представляет собой попытку найти ответы на следующие вопросы:
1. Что представляет собой защищенная система?
2. Какими должны быть требования к ее безопасности?
3. Каким образом можно учесть негативный опыт нарушения безопасности существующих систем?
4. С помощью каких механизмов можно создать средства защиты адекватно реализующие выдвинутые требования?
5. Какие принципы могут быть положены в основу технологии создания защищенных систем обработки информации?
Авторы пытаются найти ответы на эти вопросы опираясь на свой опыт исследований в данной облает и результаты разработок проводимых в Центре защиты информации.
Коротко об авторах:
Дмитрий Петрович Зегжда — ведущий научный сотрудник Центра защиты информации, кандидат технических наук, доцент кафедры Информационной безопасности компьютерных систем СПбГТУ. специализирующийся в области защиты операционных систем и моделей безопасности (E-mail [email protected]).
Андрей Михайлович Ивашко — сотрудник Федерального Агентства Правительственной Связи и Информации при Президенте Российской Федерации (E-mail Bellamy@aha. ru).
Научная редакция:
Петр Дмитриевич Зегжда — доктор технических наук, профессор, директор Центра защиты информации, заведующий кафедры Информационной безопасности компьютерных систем СПбГТУ.
Владимир Владимирович Платонов — сотрудник Центра защиты информации, профессор кафедры Информационной безопасности компьютерных систем СПбГТУ, эксперт в области информационной безопасности.
Разделы 2.8 и глава 3 написаны при участии В.М. Кузмича.
Авторы будут благодарны за отзывы и пожелания, а также любые предложения о сотрудничестве в области безопасности информационных технологий, которые можно отправлять по адресу:
195251 Санкт-Петербург Политехническая 29. Специализированный центр защиты информации СПбГТУ.
Тел./факс: (812) 552-64-89
Internet:
WWW – www.ssl.stu.neva.iu
E-mail – Dmitry.ssl.stu.neva.ru
Глава 1
Проблемы создания защищенных информационных систем
1.1. Актуальность защиты систем обработки информации
Обеспечение собственной безопасности — задача первостепенной важности для любой системы независимо от ее сложности и назначения, будь то социальное образование, биологический организм или система обработки информации.
Жизнь современного общества немыслима без повсеместного применения информационных технологий. Компьютеры обслуживают банковские системы, контролируют работу атомных реакторов, распределяют энергию, следят за расписанием поездов, управляют самолетами и космическими кораблями. Компьютерные системы и телекоммуникации предопределяют надежность и мощность систем’ обороны и безопасности страны. Компьютеры обеспечивают хранение информации, ее обработку и предоставление потребителям, реализуя таким образом информационные технологии.
Однако именно высочайшая степень автоматизации, к которой стремится современное общество, ставит его в зависимость от степени безопасности используемых им информационных технологий, от которых зависит благополучие и даже жизнь множеств людей. Технический прогресс обладает одной неприятной особенностью в каждом ею достижении таится нечто, ограничивающее его развитие и на каком-то этапе обращающее его достижения не во благо, а во вред человечеству.
Применительно к информационным технологиям одним из аргументов консервативных оппонентов их популяризации является проблем безопасности этих технологий, или. если точнее, их не безопасности. Действительно, широкое внедрение популярных дешевых компьютерных систем массового применения спроса делает их чрезвычайно уязвимыми по отношению к деструктивным воздействиям.
Примеры, подтверждающие распространенность этого явления, можно во множестве найти на страницах многочисленных изданий и еще в большем количестве на «страницах» Internet. He будем отвлекать внимание читателя на изложение скандальных фактов нарушения безопасности, оценку принесенного ущерба и описание хитроумных уловок компьютерных нарушителей. Приведем только некоторые факты, свидетельствующие об актуальности проблемы безопасности информационных технологий. Каждые двадцать секунд в Соединенных Штатах происходит преступление с использованием программных средств. В более чем 80% компьютерных преступлений, расследуемых ФБР, «взломщики» проникают в атакуемую систему через глобальную сеть Internet. Последние оценки исчисляют потери от хищения или повреждения компьютерных данных в 100 млн. долларов за год, но точные данные не поддаются учету. Во многих случаях организации не знают о том, что вторжение имело место, информация воруется незаметно, и похитители гениально заметают свои следы.
Авторы данной книги принимали участие в публикациях. посвященных компьютерным вирусам [1] и общим проблемам обеспечения информационной безопасности [2]. Наши коллеги по Центру защиты информации опубликовали труд, в котором анализируются механизмы осуществления нарушений безопасности в сети Internet [3].
Цель книги авторы видят в том, чтобы, опираясь на собственные исследования и мировой опыт последних достижений в области информационной безопасности, предложить основные принципы построения защищенных систем обработки информации.
Все вышесказанное доказывает актуальность поставленной проблемы, решение которой следует начать с анализа причин сложившейся ситуации.
1.2. Предпосылки кризиса обеспечения безопасности компьютерных систем
Не останавливаясь на социальных, правовых и экономических аспектах проблемы, систематизируем научные и технические предпосылки сложившейся ситуации с обеспечением безопасности информационных технологий.
1. Современные компьютеры за последние годы стали приобретать гигантскую вычислительную мощь, но (что на первый взгляд парадоксально!) стали гораздо проще в эксплуатации. Это означает, что пользоваться ими стало намного легче и что все большее количество новых пользователей получает доступ к компьютерам. Средняя квалификация пользователей снижается, что в значительной мере облегчает задача злоумышленникам, так как в результате «персонализации» средств вычислительной .техники большинство пользователей имеют личные рабочие станции и сами осуществляют их администрирование. Большинство из них не в состоянии постоянно поддерживать безопасность своих систем на высоком уровне, поскольку это требует соответствующих знаний. навыков, а также времени и средств. Повсеместное распространение сетевых технологий объединило отдельные машины в локальные сети, совместно использующие общие ресурсы, а применение технологии «клиент—сервер» преобразовало такие сети в распределенные вычислительные среды. Безопасность сети зависит от безопасности всех ее компьютеров, и злоумышленнику достаточно нарушить работу одного из них, чтобы скомпрометирован, всю сеть.
Современные телекоммуникационные технологии объединили локальные сети в глобальные. Эго привело к появлению такого уникального явления, как Internet. Именно развитие Internet вызвало всплеск интереса к проблеме безопасности и заставило частично пересмотреть ее основные положения. Дело в том, что Internet (кроме всего прочего) обеспечивает широкие возможности для осуществления нарушений безопасности систем обработки информации всего мира. Если компьютер. который является объектом атаки, подключен к Internet, то для злоумышленника не имеет большого значения, где он находится — в соседней комнате или на другом континенте.
2. Прогресс в области аппаратных средств сочетается с еще более бурным развитом программною обеспечения. Как показывает практика, большинство распространенных современных программных средств. (в первую очередь операционных систем), хотя их разработчики и осуществляют определенные усилия в этом направлении, не отвечает даже минимальным требованиям безопасности. Главным образом, эго выражается в наличии изъянов в организации средств, отвечающих за безопасность, и различных «недокументированных» возможностей. После обнаружения многие изъяны ликвидируются с помощью обновления версий или дополнительных средств, однако то постоянство, с которым обнаруживаются все новые и новые изъяны, не может не вызывать опасений. Это означает, что большинство систем представляют злоумышленнику широкие возможности для осуществления нарушений.
3. На наших глазах практически исчезает различие между данными и исполняемыми программами за счет появления и широкого распространения виртуальных машин и интерпретаторов. Теперь любое развитое приложение от текстового процессора (MSWord — WordBasic) до браузера Internet (Netscape Navigator— Java) не просто обрабатывает данные, а интерпретирует интегрированные в них инструкции специального языка программирования, т. е. по сути дела является отдельной машиной. Эго увеличивает возможности злоумышленников по созданию средств внедрения в чужие системы и затрудняет защиту, т. к. требует осуществлять контроль взаимодействий еще на одном уровне — уровне виртуальной машины или интерпретатора.
4. Имеет место существенный разрыв между теоретическими моделями безопасности, оперирующими абстрактными понятиями типа объект, субъект и т. п. и современными информационными технологиями. Это приводит к несоответствию между моделями безопасности и их воплощением в средствах обработки информации. Кроме того, многие средства защиты, например, средства борьбы с компьютерными вирусами и системы firewall вообще не имеют системной научной базы. Такое положение является следствием отсутствия общей теории защиты информации, комплексных моделей безопасности обработки информации, описывающих механизмы действий злоумышленников в реальных системах, а также отсутствием систем, позволяющих эффективно проверить адекватность тех или иных решений в области безопасности. Следствием этого является то, что практически все системы защиты основаны на анализе результатов успешно состоявшейся атаки, что предопределяет их отставание от текущей ситуации. В качестве примера можно привести распространенную практику закрытия «внезапно» обнаружившихся пробелов в системе защиты. Кроме всего перечисленного, в этой области (особенно в нашей стране) отсутствует даже общепринятая терминология. Теория и практика зачастую действуют в разных плоскостях.
5. В современных условиях чрезвычайно важным является обоснование требований безопасности, создание нормативной базы не осложняющей задачи разработчиков. а, наоборот, устанавливающей обязательный уровень безопасности. Существует ряд международных стандартов, пытающихся решить эту проблему, однако вплоть до последнего времени они не могли претендовать на то, чтобы стать руководством к действию или хотя бы заложить фундамент безопасных информационных технологий будущего. В России единственным официальным стандартом в этой области являются документы, подготовленные Гостехкомиссией РФ, и представляющие собой подражание зарубежным стандартам десятилетней давности. В условиях повальной информатизации и компьютеризации важнейших сфер экономики и государственного аппарата нашей стране необходимы новые решения в этой области.
Итак, развитие аппаратных и программных средств. распространение локальных и глобальных сетей привели к возрастанию количества видов и способов осуществления нарушения безопасности информации, что создало предпосылки для изменения требований к средствам защиты. Рассмотрим изменение функций средств защиты в современной обстановке.
1. Управление доступом. Компьютерные системы теперь напрямую интегрированы в информационные структуры современного общества; следовательно, управление доступом должно учитывать современные формы представления информации (гипертекст, мультимедиа и т. д.), а системы защиты должны обеспечивать безопасность на уровне информационных ресурсов, а не отдельных документов или сообщений.
2. Идентификация и аутентификация. Развитие сетей и Internet диктует необходимость добавления идентификации и аутентификации удаленных пользователей. Причем, поскольку проблема стоит именно в глобальном масштабе, эти средства должны обеспечивать идентификацию и аутентификацию объектов и субъектов, находящихся в разных частях планеты и функционирующих на различных аппаратных платформах и в разных операционных системах.
3. Наконец, от защиты требуются совершенно новые функции, а именно) механизмы, обеспечивающие безопасность системы в условиях возможного появления в виде программ, осуществляющих деструктивные действия, компьютерных вирусов и автоматизированных средств взлома. На первый взгляд кажется, что проблема решается средствами разграничения доступа, однако это не так, что подтверждается известными случаями распространения компьютерных вирусов в «защищенных» системах.
4. Для того чтобы быть жизнеспособными и не вступать в безнадежный конфликт с существующими информационными технологиями, системы безопасности должны по мере возможности сохранять совместимость с популярными в настоящее время системами.
Решение этих задач нельзя откладывать на потом. ибо без него дальнейшее развитие информационных технологий окажется под вопросом. В нашей стране, которая в настоящее время, благодаря тому, что мы начинаем информатизацию «с нуля», является полигоном для применения последних достижений информационных технологий, это актуально как нигде в мире.
Взгляд авторов на проблемы информационной безопасности и попытка решить их определяют тематику этой книги.
1.3. Задачи данной книги
Данная книга должна ответить на остающийся без конструктивного ответа вопрос, волнующий всех людей, занимающихся обеспечением информационной безопасности: как в сложившихся обстоятельствах обеспечить безопасность в соответствии с современными требованиями?
Ответ на данный вопрос не является очевидным в силу следующих факторов:
· на отечественном рынке отсутствуют защищенные (официально сертифицированные) системы обработки информации, такие, как операционные системы, СУБД, информационные системы, системы обработки документов, системы передачи информации и т. д.;
· все широко распространенные в нашей стране операционные системы (MS DOS, MS Windows, Windows 95, Novell NetWare) и протоколы передачи информации (IPX/SPX, TCP/IP) с точки зрения безопасности не выдерживают никакой критики;
· предлагаемые на отечественном рынке отдельные средства защиты не в состоянии решить проблему в целом (а другого решения в принципе быть не может).
Данная книга посвящена поиску выхода из этой ситуации и пытается ответить на целый ряд вопросов, связанных с обеспечением информационной безопасности. Существующие публикации на эту тему в основном ограничиваются перечислением угроз и аналитическими обзорами. Данная книга — первое издание, содержащее позитивную информацию о том, как строить защищенные системы, которую можно применить на практике.
Главная задача книги — помочь людям, перед которыми стоит задача создания защищенной системы обработки информации. Действительно, создание такой системы не ограничивается выбором тех или иных аппаратных и программных средств; в любом случае для обеспечения достаточно высокого уровня безопасности необходима разработка специальных средств защиты. Эта книга определяет набор средств защиты, которые должны быть разработаны для создания защищенной системы обработки информации, а также требования к ним, технологию их создания и эксплуатации. Для этого необходимо, во-первых, понять, что представляет из себя защищенная система, какие к ней предъявляются требования, рассмотреть существующий опыт создания подобных систем и причины нарушения их безопасности и, во-вторых, определить, какие функции защиты и каким образом должны быть реализованы, и как они противодействуют угрозам и устраняют причины нарушения безопасности.
Разумеется, данная публикация не претендует на окончательное разрешение всех проблем информационной безопасности, но, как надеются ее авторы, объяснит ряд вопросов и позволит решить некоторые практические задачи.
1.4. Структура данной книги
Коротко рассмотрим содержание остальных глав данной книги;
Вторая глава посвящена анализу и сопоставлению существующих стандартов в области безопасности информационных технологий, регламентирующих требования к защищенным системам обработки информации и критерии анализа уровня их безопасности.
Данное исследование содержит подробный обзор базовых положений всех основных стандартов, существующих на сегодняшний день. Сопоставление и сравнение требований и критериев этих стандартов позволяет понять основы информационный безопасности, главные принципы технологии создания защищенных систем, а также место и роль всех участников этого процесса.
Третья глава представляет собой исследование причин нарушений информационной безопасности, их систематизацию и выявление первопричин, обусловливающих возможность осуществления нарушений. Именно ликвидация этих первопричин должна быть положена в основу создания средств защиты.
В четвертой главе II тома рассматриваются формальные модели безопасности и принципы их использования в системах обработки информации, а также исследуется проблема внедрения моделей безопасности в реальные системы. Решение проблемы авторы видят в индивидуальном применении моделей безопасности на различных уровнях иерархического представления информации в компьютерной системе.
Пятая глава II тома содержит основные положения технологии построения безопасных систем обработки информации и защищенных операционных систем. Предлагаемый подход к созданию защищенных систем обработки информации основан на устранении причин нарушения информационной безопасности и обеспечении адекватности средств защиты уровню представления защищаемой информации.
1.5. Заключение к главе 1
Прогресс в области развития средств вычислительной техники, программного обеспечения и сетевых технологий стимулировал развитие средств обеспечения безопасности, что потребовало во многом пересмотреть существующую научную парадигму информационной безопасности. Данная книга является результатом работы авторов в этом направлении. Основными положениями авторского подхода к решению проблемы информационной безопасности являются:
· исследование и анализ причин нарушения безопасности компьютерных систем;
· разработка эффективных моделей безопасности, адекватных современной степени развития программных и аппаратных средств, а также возможностям злоумышленников;
· создание методов и средств корректного внедрения моделей безопасности в существующие системы, с возможностью гибкого управления безопасностью в зависимости от выдвигаемых требований, допустимого риска и расхода ресурсов.
Все эти положения в той или иной степени Представлены в данной книге.
Литература к главе 1
1. Д. Зегжда, А. Мешков, П. Семъянов, Д. Шведов. Как противостоять вирусной атаке. BHV — Санкт-Петербург, 1995. 318 стр.
2. Теория и практика обеспечения информационной безопасности /Под ред. П. Д. Зегжда. -М.: изд-во Агентства «Яхтсмен», 1996.
3. Атака через Internet. /Под ред. П. Д. Зегжда. — Санкт-Петербург. Мир и семья, 1997.
Глава 2
Обзор и сравнительный анализ стандартов информационной безопасности
(по материалам отечественных и зарубежных стандартов)
Если начинают с неправильного, то мало надежды на правильное завершение.
Конфуций
2.1. Введение
Любой проект может быть успешно завершен только в том случае, если его участники хорошо представляют, что они хотят получить в результате. Только четкое понимание цели позволит выбрать оптимальный путь ее достижения. Следовательно, прежде чем приступить к созданию защищенной системы обработки информации, надо сперва получить четкий и недвусмысленный ответ на вопрос: что представляет собой защищенная система?
Цель данной главы — выяснить, что скрывается за понятием «защищенная вычислительная система», или «защищенная система обработки информации», так как без конструктивного определения этого понятия невозможно рассматривать основные принципы функционирования подобных систем и технологию их создания.
Как уже говорилось, безопасность является качественной характеристикой системы, ее нельзя измерить в каких-либо единицах, более того, нельзя даже с однозначным результатом сравнивания безопасность двух систем – одна будет обладать лучшей защитой в одном случае, другая — в другом. Кроме того, у каждой группы специалистов, занимающихся проблемами безопасности информационных технологий, имеется свой взгляд на безопасность и средства ее достижения, следовательно, и свое представление о том, что должна представлять собой защищенная система. Разумеется, любая точка?. зрения имеет право на существование и развитие, но чтобы объединить усилия всех специалистов в конструктивной работе над созданием защищенных систем, все-таки необходимо определить, что является целью исследований, что мы хотим получить в результате и чего в состоянии достичь?
Для ответа на эти вопросы и согласования всех точек зрения на проблему создания защищенных систем разработаны и продолжают разрабатываться стандарт информационной безопасности. Это документы, регламентирующие основные понятия и концепции информационной безопасности на государственном или межгосударственном уровне, определяющие понятие «защищенная система» посредством стандартизации требований и критериев безопасности, образующих шкалу оценки степени защищенности ВС.
В соответствии с этими документами ответ на поставленный вопрос в общем виде звучит так: защищенная система обработки информации — это система, отвечающая тому или иному стандарту информационной безопасности. Конечно, это условная характеристика, она зависит от критериев, по которым оценивается безопасность, но у нее есть одно неоспоримое преимущество — объективность. Именно это позволяет осуществлять сопоставление степени защищенности различных систем относительно установленного стандарта.
Итак, рассмотрим, что представляет собой защищенная система с точки зрения существующих стандартов 6езопасности.
2.2. Основные понятия и определения
Для того чтобы приступить к дальнейшему изложению, необходимо установить некоторые термины и определения, позволяющие сформулировать базовые концепции безопасности компьютерных систем. Несмотря на то что практически каждый из рассматриваемых далее стандартов представляет оригинальный подход к определению понятия безопасной системы обработки информации, существует ряд понятий, используемых всеми стандартами. Приведем те из них, которые являются наиболее важными для понимания и практикуются во все стандартах (за редким исключением) практически одинаково.
Политика безопасности (Security Policy). Совокупность норм и правил, обеспечивающих эффективную защиту системы обработки информации от заданного множества угроз безопасности.
Модель безопасности (Security Model). Формальное представление политики безопасности.
Дискреционное, или произвольное, управление доступом (Discretionary Access Control). Управление доступом, основанное на заданном администратором по своему усмотрению множестве разрешенных отношений доступа (например, в виде троек ).
Мандатное, или нормативное, управление доступом (Mandatory Access Control). Управление доступом, основанное на совокупности правил предоставления доступа. определенных на множестве атрибутов безопасности субъектов и объектов, например в зависимости от грифа секретности информации и уровня допуска пользователя.
Ядро безопасности {Trusted Computing Base. TCB). Совокупность аппаратных, программных и специальных компонент ВС. реализующих функции защиты и обеспечения безопасности. Далее в тексте будет использоваться аббревиатура TCB ввиду ее распространенности и неточности предложенного перевода.
Идентификация (Identification). Процесс распознавания сущностей при помощи присвоенных им уникальных меток (идентификаторов).
Аутентификация {Authentication). Проверка подлинности идентификаторов сущностей с помощью различных (преимущественно криптографических) методов.
Адекватность (Assurance). Показатель реально обеспечиваемого уровня безопасности, отражающий степень эффективности и надежности реализованных средств защиты и их соответствия поставленным задачам (в большинстве случаев это задача реализации политики безопасности)
Квалификационный анализ, квалификация уровня безопасности (Evaluation). Анализ ВС с целью определения уровня ее защищенности и соответствия требованиям безопасности на основе критериев стандарта безопасности. Квалификация уровня безопасности является конечным этапом технологического цикла создания защищенных систем, непосредственно предшествует процедуре сертификации и завершается присвоением ВС того или иного класса или уровня безопасности. В терминологии Гостехкомиссии РФ есть близкий по значению термин «сертификационные испытания», но он не совсем точен — квалификационный анализ не ограничивается простыми испытаниями, а включает в себя подробное исследование архитектуры ВС и технологии ее разработки, а, также анализ слабых сторон ее зашиты. Соответственно, специалистов, занимающихся квалификационным анализом. будем называть экспертами по квалификации.
Таксономия (Тахопоту), Наука о систематизации и классификации сложноорганизованных объектов и явлений, имеющих иерархическое строение (от греческого taxis — расположение, строй, порядок и nomos — закон).Прямое взаимодействие (Trusted Path). Принцип организации информационного взаимодействия (как правило, между пользователем и ‘системой), гарантирующий, что передаваемая информация не подвергается перехвату или искажению.
Отметим, что часть приведенных определений не совпадает с официальной трактовкой руководящими документами Гостехкомиссии России [I]. С точки зрения авторов, предложенные определения совпадают по смыслу с общепринятыми и распространенными английскими терминами.
2.3. Угрозы безопасности компьютерных систем
Под угрозой безопасности вычислительной системы понимаются воздействия на систему, которые прямо или косвенно могут нанести ущерб ее безопасности. Разработчики требований безопасности и средств защиты выделяют три вида угроз: угрозы нарушения конфиденциальности обрабатываемой информации, угрозы нарушения целостности обрабатываемой информации и угрозы нарушения работоспособности системы (отказа в обслуживании).
Угрозы конфиденциальности направлены на разглашение секретной информации, т. е. информация становится известной лицу, которое не должно иметь к ней доступ. Иногда для обозначения этого явления используется понятие «несанкционированный доступ» (НСД), особенно популярное у отечественных специалистов. Традиционно противостоянию угрозам этого типа уделялось максимальное внимание, и фактически подавляющее большинство исследований и разработок было сосредоточено именно в этой области, так как она непосредственно относится к задаче охраны государственных и военных секретов.
Угрозы целостности представляют собой любое искажение или изменение неуполномоченным на это действие лицом хранящейся в вычислительной системе или передаваемой информации. Целостность информации может быть нарушена как злоумышленником, так и в результате объективных воздействий со стороны среды эксплуатации системы. Наиболее актуальна эта угроза для систем передачи информации — компьютерных сетей и систем телекоммуникаций.
Угрозы нарушения работоспособности (отказ в обслуживании) направлены на создание ситуаций, когда в результате преднамеренных действий снижается работоспособность вычислительной системы, либо ее ресурсы становятся недоступными. Цель защиты систем обработки информации — противодействие угрозам безопасности. Следовательно, безопасная или защищенная система — это система, обладающая средствами защиты, которые успешно и эффективно противостоят угрозам безопасности.
2.4. Роль стандартов информационной безопасности
Главная задача стандартов информационной безопасности — создать основу для взаимодействия между производителями, потребителями и экспертами по квалификации продуктов информационных технологий. Каждая из этих групп имеет свои интересы и свои взгляды на проблему информационной безопасности.
Потребители, во-первых, заинтересованы в методике, позволяющей обоснованно выбрать продукт, отвечающий их нуждам и решающий их проблемы, для чего им необходима шкала оценки безопасности, и, во-вторых, нуждаются в инструменте, с помощью которого они могли бы формулировать свои требования производителям. При этом потребителей (что вполне естественно) интересуют исключительно характеристики и свойства конечного продукта, а не методы и средства их достижения. С этой точки зрения идеальная шкала оценки безопасности должна была бы выглядеть примерно следующим образом:
Уровень 1. Система для обработки информации с грифом не выше „для служебного пользования”;
Уровень 2. Система для обработки информации с грифом не выше „секретно”, и т. д.
Соответственно и требования потребители хотели бы формулировать примерно в такой форме: «Мы хотим, чтобы у нас все было защищено для обработки совершенно секретной информации». Этот неконструктивный подход сам по себе не так страшен, гораздо хуже другое — многие потребители не понимают, что за все надо платить (и не только деньгами) и что требования безопасности обязательно противоречат функциональным требованиям (удобству работы, быстродействию и т. п.), накладывают ограничения на совместимость и, как правило, вынуждают отказаться от очень широко распространенных незащищенных прикладных программных средств.
Производители, в свою очередь, нуждаются в стандартах для сравнения возможностей своих продуктов и в применении процедуры сертификации для объективной оценки их свойств, а также в стандартизации определенного набора требований безопасности, который мог бы ограничить фантазию заказчика конкретного продукта и заставить его выбирать требования из этого набора. С точки зрения производителя, требования должны быть максимально конкретными и регламентировать необходимость применения тех или иных средств, механизмов, алгоритмов и т. д. Кроме того, требования не должны вступать в конфликт с существующими парадигмами обработки информации, архитектурой вычислительных систем и технологиями создания информационных продуктов. Этот подход также не может быть признан в качестве доминирующего, так как он не учитывает нужд пользователей (удовлетворение которых — главная задача разработчика) и пытается подогнать требования защиты под существующие системы и технологий, а это далеко не всегда возможно осуществить без ущерба для безопасности.
Эксперты по квалификации и специалисты по сертификации рассматривают стандарты как инструмент, позволяющий им оценить уровень безопасности, обеспечиваемый продуктами информационных технологий, и предоставить потребителям возможность сделать обоснованный выбор. Производители в результате квалификации уровня безопасности получают объективную оценку возможностей своего продукта. Эксперты по квалификации находятся в двойственном положении. С одной стороны они, как и производители, заинтересованы в четких и простых критериях, над применением которых к конкретному продукту не надо ломать голову (например, в виде анкеты с ответами типа «ДА/НЕТ»). С другой стороны, они должны дать обоснованный ответ пользователям — удовлетворяет продукт их нуждам или нет. Именно эксперты принимают на себя ответственность за безопасность продукта, получившего квалификацию уровня безопасности и прошедшего сертификацию.
Таким образом, перед стандартами информационной безопасности стоит непростая задача — примирить эти три точки зрения и создать эффективный механизм взаимодействия всех сторон. Причем «ущемление» потребностей хотя бы одной из них приведет к невозможности взаимопонимания и взаимодействия и, следовательно, не позволит решить общую задачу — создание защищенной системы обработки информации. Необходимость в подобных стандартах была осознана уже достаточно давно (по меркам развития информационных технологий ) и в этом направлении достигнут существенный прогресс закрепленный в новом поколении документов разработки 90-годов. Наиболее значимыми стандартами информационной безопасности являются (в хронологическом порядке): «Критерии безопасности компьютерных систем министерства обороны США» [7], Руководящие документы Гостехкомиссии России [1,2,3,4,5] (только для нашей страны), «Европейские критерии безопасности информационных технологий» [16] «Федеральные критерии безопасности информационных технологий США»[17], «Канадские критерии безопасности компьютерных систем» [18] и «Единые критерии безопасности информационных технологий» [19].
Представляется целесообразным проанализировать эти документы, сопоставить их структуру, содержащиеся в них требования и критерии, а также оценить эффективность их практического применения. Следующий далее обзор стандартов строится по следующей схеме: цель разработки, основные положения, таксономия и ранжирование требований и критериев.
2.5 Критерии безопасности компьютерных систем министерства обороны США («Оранжевая книга»)
2.5.1. Цель разработки
«Критерии безопасности компьютерных систем» (Trusted Computer System Evaluation Criteria») [7], получившее неформальное, но прочно закрепившееся название «Оранжевая книга», были разработаны Министерством обороны США в 1983 году с целью определения требований безопасности, предъявляемых к аппаратному, программному и специальному обеспечение компьютерных систем и выработки соответствующей методологии анализа политики безопасности, реализуемой в компьютерных системах военного назначения.
В данном документе были впервые нормативно определены такие понятия, как «политика безопасности», ТСВ и т. д. Согласно «Оранжевой книге», безопасная компьютерная система — это система, поддерживающая управление доступом к обрабатываемой в ней информации такое, что только соответствующим образом уполномоченные пользователи или процессы, действующие от их имени, получают возможность читать, писать, создавать и удалять информацию. Предложенные в этом документе концепции защиты и набор функциональных требований послужили основой для формирования всех появившихся впоследствии! стандартов безопасности.
2.5.2. Таксономия требовании и критериев «Оранжевой книги»
В «Оранжевой книге» предложены три категории требований безопасности — политика безопасности, аудит и корректность, в рамках которых сформулированы шесть базовых требований безопасности. Первые четыре требования направлены непосредственно на обеспечение безопасности информации, а два последних — на качество самих средств защиты. Рассмотрим эти требования подробнее.
2.5.2.1. Политика безопасности
Требование 1. Политика безопасности.
Система должна поддерживать точно определенную политику безопасности. Возможность осуществления субъектами доступа к объектам должна определяться на основании их идентификации и набора правил управления доступом. ‘Гам. где необходимо, должна использоваться политика нормативного упрощения доступом. позволяющая эффективно реализовать разграничение доступа к категорированной информации (информации, отмеченной грифом секретности, типа «секретно», «сов. секретно» и т.д. ).
Требование 2. Метки
С объектами должны быть ассоциированы метки безопасности, используемые в качестве атрибутов контроля доступа. Для реализации нормативного управления доступом система должна обеспечивать возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень конфиденциальности (гриф секретности) объекта и/или режимы доступа к этому объекту.
2.5.2.2. Аудит
Требование 3. Идентификации и аутентификация
Все субъекты должны иметь уникальные идентификаторы. Контроль доступа должен осуществляться на основании результатов идентификации субъекта и объекта доступа, подтверждения подлинности их идентификаторов (аутентификации) и правил разграничения (Уступа. Данные, используемые для идентификации и аутентификации. должны быть защищены от несанкционированного доступа, модификации и уничтожения и должны быть ассоциированы со всеми активными компонентами компьютерной системы, функционирование которых критично с точки зрения безопасности.
Требование 4. Регистрация и учет
Для определения степени ответственности пользователей за действия в системе, все происходящее в ней события. имеющие значение с точки зрения безопасности. должны отслеживаться и регистрироваться в защищенном протоколе. Система регистрации должна осуществлять анализ общего потока событий и выделять из пего только те события, которые оказывают влияние на безопасность для сокращения объема протокола и повышения эффективности его анализа. Протокол событий должен быть надежно защищен от несанкционированного доступа, модификации и уничтожения.
2.5.2.3. Корректность
Требование 5. Контроль корректности функционирования средств зашиты
Средства защиты должны содержать независимые аппаратные и/или программные компоненты, обеспечивающие работоспособность функций защиты. Это означает, что все средства зашиты, обеспечивающие политику безопасности, управление атрибутами и метками безопасности, идентификацию и аутентификацию, регистрацию и учет, должны находится под контролем средств проверяющих корректность их функционирования. Основной принцип контроля корректности состоит в том, что средства контроля должны быть полностью независимы от средств защиты.
Требование 6. Непрерывность зашиты
Все средства защиты (в т.ч. и реализующие данное требование) должны быть защищены от несанкционированного вмешательства и/или отключения, причем эта защита должна быть постоянной и непрерывной в любом режиме функционирования системы защиты и компьютерной системы в целом. Данное требование распространяется на весь жизненный цикл компьютерной системы. Кроме него, его выполнение является одним из ключевых аспектов формального доказательства безопасности системы.
Рассматриваемые далее критерии безопасности компьютерных систем представляют собой конкретизацию данных обобщенных требований.
2.5.2.4. Таксономия критериев безопасности
Приведенные выше базовые требования к безопасности служат основой для критериев, образующих единую шкалу оценки безопасности компьютерных систем, определяющую семь классов безопасности.
Ввиду широкой доступности самой «Оранжевой книги» и ее многочисленных обзоров и интерпретаций приведем только схему, отражающую таксономию предложенных в ней функциональных требований безопасности (рис. 2.1).
2.5.3. Классы безопасности компьютерных систем
Поскольку «Оранжевая книга» достаточно подробно освещалась в отечественных исследованиях [б], ограничимся только кратким обзором классов безопасности.
«Оранжевая книга» предусматривает четыре группы критериев, которые соответствуют различной степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов. Группы D и А содержат по одному классу (классы D1 и А1 соответственно), группа С — классы Cl, C2, а группа В — Bl, B2, ВЗ, характеризующиеся различными наборами требований безопасности. Уровень безопасности возрастает при движении от группы D к группе А, а внутри группы — с возрастанием номера класса.
Рис. 2.1 Таксономия требований «Оранжевой книги»
• Группа D. Минимальная защита
Класс D1. Минимальная защити. К этому классу относятся все системы, которые не удовлетворяют требованиям других классов.
• Группа С. Дискреционная защита
Группа С характеризуется наличием произвольного управления доступом и регистрацией действий субъектов.
Класс С1. Дискреционная защита. Системы этого класса удовлетворяют требованиям обеспечения разделения пользователей и информации и включают средства контроля и управления доступом, позволяющие задавать ограничения для индивидуальных пользователей, что дает им возможность защищать свою приватную информацию от других пользователей. Класс С1 рассчитан на многопользовательские системы, в которых осуществляется совместная обработка данных одного уровня секретности.
Класс С1. Управление доступом. Системы этого класса осуществляют более избирательное управление доступом, чем системы класса С1, с помощью применения средств индивидуального контроля за действиями пользователей, регистрацией, учетом событий и выделением ресурсов.
• Группа В. Мандатная защита
Основные требования этой группы — нормативное управление доступом с использованием меток безопасности, поддержка модели и политики безопасности, а также наличие спецификаций на функции ТСВ. Для систем этой группы монитор взаимодействий должен контролировать все события в системе.
Класс В1. Защита с применением меток безопасности.
Системы класса BI должны соответствовать всем требованиям, предъявляемым к системам класса С2, и, кроме того, должны поддерживать определенную неформально модель безопасности, маркировку данных и нормативное управление доступом. При экспорте из системы информация должна подвергаться маркировке. Обнаруженные в процессе тестирования недостатки должны быть устранены.
Класс В2. Структурированная защита. Для соответствия классу В2 ТСВ системы должно поддерживать формально определенную и четко документированную модель безопасности, предусматривающую произвольное и нормативное управление доступом, которое распространяется по сравнению с системами класса В1 на все субъекты. Кроме того, должен осуществляться контроль скрытых каналов утечки информации. В структуре ТСВ должны быть выделены элементы, критичные с точки зрения безопасности. Интерфейс ТСВ должен быть четко определен, а его архитектура и реализация должны быть выполнены с учетом возможности проведения тестовых испытаний. По сравнению с классом В1 должны быть усилены средства аутентификации. Управление безопасностью осуществляется администраторами системы. Должны быть предусмотрены средства управления конфигурацией.
Класс ВЗ. Домены безопасности. Для соответствия этому классу ТСВ системы должно поддерживать монитор взаимодействий, который контролирует все типы доступа субъектов к объектам и который невозможно обойти. Кроме того, ТСВ должно быть структурировано с целью исключения из него подсистем, не отвечающих за реализацию функции защиты, и быть достаточно компактно для эффективного тестирования и анализа. В ходе разработки и реализации ТСВ должны применяться методы и средства, направленные на минимизацию его сложности. Средства аудита должны включать механизмы оповещения администратора при возникновении событий, имеющих значение для безопасности системы. Требуется наличие средств восстановления работоспособности системы.
• Группа А. Верифицированная защита
Данная группа характеризуется применением формальных методов верификации корректное ги работы механизмов управления доступом (произвольного и нормативного). Требуется дополнительная документация, демонстрирующая, что архитектура и реализация ТСВ отвечают требованиям безопасности.
Класс А1. Формальная верификация. Системы класса А1 функционально эквивалентны системам классаВЗ, и к ним не предъявляется никаких дополнительных функциональных требований. В отличие от систем класса ВЗ в ходе разработки должны применяться формальные методы верификации, что позволяет с высокой уверенностью получить корректную реализацию функций защиты. Процесс доказательства адекватности реализации начинается на ранней стадии разработки с построения формальной модели политики безопасности и спецификаций высокого уровня. Для обеспечения методов верификации системы класса А1 должны содержать более мощные средства управления конфигурацией и защищенную процедуру дистрибуции.
Приведенные классы безопасности надолго определили основные концепции безопасности и ход развития средств защиты.
2.5.4. Интерпретация и развитие «Оранжевой книги»
Опубликование «Оранжевой книги» с гало важным этапом и сыграло значительною роль в развитии технологий обеспечения безопасности компьютерных систем. Тем не менее в ходе применения ее положений выяснилось, что часть практически важных вопросов осталась за рамками данного стандарта и, кроме того, с течением времени (с момента опубликования прошло пятнадцать лег) ряд положений устарел и потребовал пересмотра.
Круг специфических вопросов по обеспечению безопасности компьютерных сетей и систем управления базами данных нашел отражение в отдельных документах, изданных Национальным центром компьютерной безопасности США в виде дополнений к «Оранжевой книге» — «Интерпретация для компьютерных сетей» («Trusted Network Interpretation» [8]) и «Интерпретация для систем управления базами данных» («Trusted Database Management System Interpretation» [9]). Эти документы содержат трактовку основных положений «Оранжевой книги» применительно к соответствующим классам систем, обработки информации.
Потеря актуальности рядом положений «Оранжевой книги» вызвана прежде всего интенсивным развитием компьютерных технологий и переходов с мэйнфреймов (типа вычислительных комплексов IBM-360, 370; советский аналог — машины серии ЕС) к рабочим станциям, высокопроизводительным персональным компьютерам и сетевой модели вычислений. Именно для того, чтобы исключить возникшую в связи с изменением аппаратной платформы некорректность некоторых положений «Оранжевой книги», адаптировать их к современным условиям и сделать адекватными нуждам разработчиков и пользователей программного обеспечения, и была проделана огромная работа по интерпретации и развитию положений этого стандарта. В результате возник целый ряд сопутствующих «Оранжевой книге» документов, многие их которых стали ее неотъемлемой частью. К наиболее часто упоминаемым относятся:
Руководство по произвольному управлению доступом в безопасных системах («A guide to understanding discretionary access control in trusted systems») [10].
Руководство по управлению паролями («Password management guideline») [11].
Руководство по применению Критериев безопасности компьютерных систем в специфических средах («Guidance for applying the Department of Defence Trusted Computer System Evaluation Criteria in specific environment») [12].
Руководство по аудиту в безопасных системах («A Guide to Understanding Audit in Trusted Systems») [13].
Руководство по управлению конфигурацией в безопасных системах («Guide to understanding configuration management in trusted systems) [14].
Количество подобных вспомогательных документов, комментариев и интерпретаций значительно превысило объем первоначального документа, и в 1995 году Национальным центром компьютерной безопасности США был опубликован документ под названием «Пояснения к критериям безопасности компьютерных систем» [15]. объединяющий все дополнения и разъяснения. При его подготовке состав подлежащих рассмотрению и толкованию вопросов обсуждался на специальных конференциях разработчиков и пользователей защищенных систем обработки информации. В результате открытого обсуждения была создана база данных, включающая все спорные вопросы, которые затем в полном объеме были проработаны специально созданной рабочей группой. В итоге появился документ, объединивший все изменения и дополнения к «Оранжевой книге», сделанные с момента ее опубликования, что привело к обновлению стандарта и позволило применять его в современных условиях.
2.5.5. Выводы
«Критерии безопасности компьютерных систем» министерства обороны США представляют собой первую попытку создать единый стандарт безопасности, рассчитанный на разработчиков, потребителей и специалистов но сертификации компьютерных систем. В свое время этот документ явился настоящим прорывом в области безопасности информационных технологий и послужил отправной точкой для многочисленных исследований и разработок. Основной отличительной чертой этого документа является его ориентация на системы военного применения, в основном на операционные системы. Это предопределило доминирование требований, направленных на обеспечение секретности обрабатываемой информации и исключение возможностей ее разглашения. Большое внимание уделено меткам (грифам секретности) и правилам экспорта секретной информации.
При этом критерии адекватности реализации средств защиты и политики безопасности отражены слабо, соответствующий раздел ограничивастся требованиями контроля целостности средств защиты и поддержания их работоспособности, чего явно недостаточно.
Высший класс безопасности, требующий осуществления верификации средств защиты, построен на доказательстве соответствия программного обеспечения его спецификациям с помощью специальных методик, однако это доказательство (очень дорогостоящее, трудоемкое и практически неосуществимое для реальных операционных систем) не подтверждает корректность и адекватность реализации политики безопасности.
«Оранжевая книга» послужила основой для разработчиков всех остальных стандартов информационной безопасности и до сих пор используется в США в качестве руководящего документа при сертификации компьютерных систем обработки информации.
2.6. Европейские критерии безопасности информационных технологий.
Проблемы информационной безопасности актуальны не только для Соединенных Штатов. Вслед за выходом «Оранжевой книги» страны Европы совместно разработали общие «Критерии безопасности информационных технологий» («Information Technology Security Evaluation Criteria», далее «Европейские критерии») [16]. Данный обзор основывается на версии 1.2. опубликованной в июне 1991 года от имени соответствующих органов четырех стран: Франции, Германии, Нидерландов и Великобритании.
2.6.1. Основные понятия
«Европейские критерии» рассматривают следующие задачи средств информационной безопасности:
· защита информации от несанкционированного доступа с целью обеспечения конфиденциальности;
· обеспечение целостности информации посредством защиты от ее несанкционированной модификации или уничтожения;
· обеспечение работоспособности систем с помощью противодействия угрозам отказа в обслуживании.
Для того чтобы удовлетворить требованиям конфиденциальности, целостности и работоспособности, необходимо реализовать соответствующий набор функций безопасности, таких, как идентификация и аутентификация, управление доступом, восстановление после сбоев и т. п. Чтобы средства защиты можно было признать эффективными, требуется определенная степень уверенности в правильности их выбора и надежности функционирования. Для решения этой проблемы в «Европейских критериях» впервые вводится понятие адекватности (assurance) средств защиты.
Адекватность включает в себя два аспекта: эффективность, отражающую соответствие средств безопасности решаемым задачам, и корректность, характеризующую процесс их разработки и функционирования. Эффективность определяется соответствием между задачами, поставленными перед средствами безопасности, и реализованным набором функций защиты — их функциональной полнотой и согласованностью, простотой использования, а также возможными последствиями использования злоумышленниками слабых мест защиты. Под корректностью понимается правильность и надежность реализации функций безопасности.
Общая оценка уровня безопасности системы складывается из функциональной мощности средств защиты и уровня адекватности их реализации.
2.6.2. Функциональные критерии
В «Европейских критериях» средства, имеющие отношение к информационной безопасности, рассматриваются на трех уровнях детализации. На первом уровне рассматриваются цели, которые преследует обеспечение безопасности, второй уровень содержит спецификации функций защиты, а третий — реализующие их механизмы. Спецификации функций защиты предлагается’ рассматривать с точки зрения следующих требований:
· идентификация и аутентификация;
· управление доступом:
· подотчетность;
· аудит;
· повторное использование объектов;
· целостность информации;
· надежность обслуживания,
· безопасность обмена данными
Большинство из перечисленных тре6ований совпадают с аналогичными требованиями «Оранжевой книги». Остановимся лишь на специфичных для «Европейских критериев» моментах.
Требования безопасности обмена данными регламентируют работу средств, обеспечивающих безопасность данных, передаваемых но каналам связи, и включают следующие разделы:
· аутентификация,
· управление доступом,
· конфиденциальность данных,
· целостность данных,
· невозможность отказаться от совершенных действий.
Набор функций безопасности может специфицироваться с использованием ссылок на заранее определенные классы-шаблоны. В «Европейских критериях» таких классов десять. Пять из них (F-C1, F-C2, F-B1. F-B2, F-B3) соответствуют классам безопасности «Оранжевой книги» с аналогичными обозначениями. Рассмотрим подробнее другие пять классов, так как их требования отражают точку зрения разработчиков стандарты на проблему безопасности.
Класс F-IN предназначен для систем с высокими потребностями в обеспечении целостности, что типично для систем управления базами данных. Его описание основано на концепции «ролей», соответствующих видам деятельности пользователей, и предоставлении доступа к определенным объемам только посредством доверенных процессов. Должны различаться следующие виды доступа: чтение, запись, добавление, удаление, создание. переименование и выполнение объектов
Класс F-AV характеризуется повышенными трe6oваниями к обеспечению работоспособности. Это существенно, например, для систем управления технологическими процессами В требованиях этого класса указывается, что система должна восстанавливаться после отказа отдельного аппаратного компонента таким образом, чтобы все критически важные функции постоянно оставались доступными. В таком же режиме должна происходить и замена компонентов системы. Независимо от уровня загрузки должно гарантироваться определенное время реакции системы на внешние события.
Класс F-DI ориентирован на распределенные системы обработки информации. Перед началом обмена и при получении данных стороны должны иметь возможность провести идентификацию участников взаимодействия и проверить ее подлинность. Должны использоваться средства контроля и исправления ошибок. В частности, при пересылке данных должны обнаруживаться все случайные или намеренные искажения адресной и пользовательской информации. Знание алгоритма обнаружения искажений не должно позволять злоумышленнику производить нелегальную модификацию передаваемых данных. Должны обнаруживаться попытки повторной передачи ранее переданных сообщений.
Класс F-DC уделяет особое внимание требованиям к конфиденциальности передаваемой информации. Информация по канатам связи должна передаваться в зашифрованном виде. Ключи шифрования должны быть защищены от несанкционированного доступа.
Класс F-DX предъявляет повышенные требования и к целостности и к конфиденциальности информации. Его можно рассматривать как объединение классов F-DI и F-DC с дополнительными возможностями шифрования и защиты от анализа трафика. Должен быть ограничен доступ к ранее переданной информации, которая, в принципе может способствовать проведению криптоанализа.
2.6.3. Критерии адекватности
«Европейские критерии» уделяют адекватности средств защиты значительно больше внимания, чем функциональным требованиям. Как уже говорилось адекватность складывается из двух компонентов — эффективности И корректности работы средств защиты. Для оценки степени адекватности используются следующие критерии (см. рис. 2.2).
«Европейские критерии» определяют семь уровней адекватности -— от Е0 до Е6 (в порядке её возрастания). Уровень ЕО обозначает минимальную адекватность (аналог уровня D «Оранжевой книги»). При проверке адекватности анализируется весь жизненный цикл системы от начальной фазы проектирования до эксплуатации и сопровождения. Уровни адекватности от Е1 до Е6 выстроены по нарастанию требований тщательности контроля. Так, на уровне Е1 анализируется лишь общая архитектура системы, а адекватность средств защиты подтверждается функциональным тестированием. На уровне ЕЗ к анализу привлекаются исходные тексты программ и схемы аппаратного обеспечения. На уровне Е6 требуется формальное описание функций безопасности, общей архитектуры, а также политики безопасности.
Степень безопасности системы определяется самым слабым из критически важных механизмов защиты. В «Европейских критериях» определены три уровня безопасности — базовый, средний и высокий. Безопасность считается базовой, если средства защиты способны противостоять отдельным случайным атакам. Безопасность считается средней, если средства защиты способны противостоять злоумышленникам, обладающим ограниченными ресурсами и возможностями. Наконец, безопасность можно считать высокой, если есть уверенность, что средства защиты могут быть преодолены только злоумышленником с высокой квалификацией, набор возможностей и ресурсов которого выходит за рамки разумного.
Рис. 2.2 Таксономия критериев адекватности «Европейских стандартов»
2.6.4. Выводы
«Европейские критерии безопасности информационных технологий», появившиеся вслед за «Оранжевой книгой», оказали существенное влияние на стандарты безопасности и методику сертификации.
Главное достижение этого документ — введение понятия адекватности средств защиты и определение отдельной шкалы для критериев адекватности. Как уже упоминалось. «Европейские критерии» придают адекватности средств защиты даже большее значение, чем их функциональности. Этот подход используется во многих появившихся позднее стандартах информационной безопасности.
Необходимо отметить, что «Европейские критерии» тесно связаны с «Оранжевой книгой», что делает их не вполне самостоятельным документом.
На первый взгляд довольно странным выглядит тот факт, что «Европейские критерии» признают возможность наличия недостатков в сертифицированных системах (критерий возможности использования недостатков защиты), однако на самом деле это свидетельствует о трезвом взгляде на существующее положение и признании того очевидного факта, что реальные системы еще весьма несовершенны и далеки от идеала (см. главу 3).
«Европейские критерии» безопасности информационных технологий, наряду с «Оранжевой книгой» легли в основу многих стандартов безопасности компьютерных систем.
2.7. Руководящие документы Гостехкомиссии России.
2.7.1. Основные положения
В 1992 году Гостехкомиссия (ГТЮ при Президенте Российской федерации (РФ) опубликовала пять Руководящих документов, посвященных вопросам защиты от несанкционированного доступом к информации [1,2.3,4,5]. Мы рассмотрим важнейшие их них: «Концепция защиты средств вычислительной техники от несанкционированного доступа к информации», «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Пока нагели защищенности от несанкционированною доступа к информации», «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.
Идейной основой этих документов является «Концепция защиты средств вычислительной техники от несанкционированного доступа к информации (НСД)» [I], содержащая систему взглядов ГТК на проблему информационной безопасности и основные принципы защиты компьютерных систем. С точки зрения разработчиков данных документов основная и едва ли не единственная задача средств безопасности – эго обеспечение защиты or несанкционированного доступа (НСД) к информации. Если средствам контроля и обеспечения целостности, еще уделяется некоторое внимание, то поддержка работоспособности систем обработки информации (как мера защиты от угроз работоспособности) вообще не упоминается. Определенный уклон в сторону поддержания секрет носит объясняется тем что эти документы были разработаны в расчете на применение в информационных системах министерства обороны и спецслужб РФ, а также недостаточно высоким уровнем информационных технологий этих систем по сравнению с современным.
2.7.2. Таксономия критериев и требований безопасности
Руководящие документы ГТК предлагают две группы критериев безопасности – показатели защищенности средств вычислительной техники (СВТ) от НСД и критерии защищенности автоматизированных систем (АС) обработки данных. Первая группа позволяет оценить степень защищенности (правда только относительно угроз одного типа — НСД) отдельно поставляемых потребителю компонентов ВС, а вторая рассчитана на полнофункциональные системы обработки данных.
Поскольку данные документы легко доступны и часто служили объектами комментариев и критики [б], ограничимся только кратким обзором их основных положений.
2.7.2.1. Показатели защищенности СВТ от НСД
Данный руководящий документ устанавливает классификацию СВТ по уровню защищенности от НСД к информации на базе перечня показателей защищенности и совокупности описывающих их требований. Под СВТ понимается совокупность программных и технических элементов систем обработки данных, способных функционировать самостоятельно или в составе других систем.
Данные показатели содержат требования защищенности СВТ от НСД к информации и применяются к общесистемным программным средствам и операционным системам (с учетом архитектуры ЭВМ). Конкретные перечни показателей определяют классы защищенности СВТ и описываются совокупностью требований. Совокупность всех средств защиты составляет комплекс средств защиты (КСЗ).
Установлено семь классов защищенности СВТ от НСД к информации. Самые низкие требования предъявляются к системам, соответствующим седьмому классу самые высокие — к первому.
Показатели защищенности и установленные требования к классам приведены в таб. 2.1.
Таблица 2.1. Распределение показателей защищенности по классам СВТ
Наименование показателя
Класс защищенности
6
5
4
3
2
1
Дискреционным принцип контроля доступа
+
+
+
=
+
=
Мандатный принцип контроля доступа
–
–
+
=
=
=
Очистка памяти
–
+
+
+
=
=
Изоляция модулей
–
–
+
=
+
=
Маркировка документов
–
–
+
=
=
=
Защита ввода и вывода на отчужденный физический носитель информации
–
–
+
=
=
=
Сопоставление пользователя с устройством
–
–
+
=
=
=
Идентификация и аутентификация
+
=
+
=
=
=
Гарантии проектирования
–
+
+
+
+
+
Регистрация
–
+
+
+
=
=
Взаимодействие пользователя с КСЗ
–
–
–
+
=
=
Надежное восстановление
–
–
–
+
=
=
Целостность КСЗ
–
+
+
+
=
Контроль модификации
–
–
. –
–
+
=
Контроль дистрибуции
–
–
–
–
+
=
Гарантии архитектуры
–
–
–
–
–
+
Тестирование
+
+
+
+
+
=
Руководство пользователя
+
=
=
=
=
=
Руководство по КСЗ
+
+
=
+
+
=
Текстовая документация
+
+
+
+
+
=
Конструкторская(проектная)документация
+
+
+
+
+
+
Обозначения:
«-» – нет требований к данному классу
«+» – новые или дополнительные требования
«=» – требовании совпадают с требованиями к СВТ предыдущего класса
«КСЗ» – комплекс средств защиты
2.7.2.2. Требования к защищенности aвтоматизированных систем
Данные требования являются составной частью критериев защищенности автоматизированных систем обработки информации от НСД Требования сгруппированы вокруг peaлизующих их подсистем защиты. В отличие от остальных стандартов, отсутствует раздел содержащий требования по обеспечению работоспособности системы, зато присутствует раздел, посвященный криптографическим средствам (другие стандарты не содержат даже упоминания о криптографии, так как рассматривают ее исключительно в качестве механизма, реализующего остальные требования, такие, как аутентификацию, контроль целостности и т.д.). Таксономия требований к средствам защиты AC от НСД приведена на рис 2.3.
Рис. 2.3 Таксономия требования к средствам защиты АС от НДС.
2.7.3. Классы защищенности автоматизированных систем
Документы ГТК устанавливают девять классов защищенности АС от НСД, каждый из которых xapaктеризуются определенной совокупнопностью требовании к средствам защит. Классы подразделяются на три группы, отличающиеся спецификой обработки информации в АС. Группа АС определяется на основании следующих признаков:
· наличие в АС информации различного уровня конфиденциальности,
· уровень полномочий пользователей АС на доступ к конфиденциальной информации,
· режим обработки данных в АС (коллективный или индивидуальный).
В пределах каждой группы соблюдается иерархия классов защищенности АС. Класс, соответствующий высшей степени защищенности дли данной группы, обозначается индексом NA, где N – номер группы (от 1 до 3). Следующий класс обозначается NБ и т.д.
Третья группа включает АС, в которых работает один пользователь, допущенный ко всей информации АС. размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса —3Б и 3А.
Вторая группа включает АС, в которых пользователи имеют одинаковые полномочия доступа ко всей информации, обрабатываемой и/или хранимой в АС на носителях различного уровня конфиденциальности. Группа содержит два класса — 2Б и 2А.
Первая группа включает многопользовательские АС, в которых одновременно обрабатывается и/или хранится информация разных уровней конфиденциальности. Не все пользователи имеют равные права доступа. Группа содержит пять классов — 1Д, 1Г. 1В, 1Б и 1А.
В таб. 2.2 приведены требования к подсистемам защиты для каждого класса.
2.7.4. Выводы
Разработка руководящих документов ГТК явилась следствием бурно развивающегося в России процесса внедрения информационных технологий. До начала 90-х годов необходимости в подобных документах не было, так как в большинстве случаев обработка и хранение конфиденциальной информации осуществлялись без применения вычислительной техники. Поэтому разработка стандартов подобного рода представляет собой абсолютно новую и незнакомую область деятельности для соответствующих институтов и учреждений, что позволяет трактовать данные документы как первую стадию формирования отечественных стандартов в области информационной безопасности.
Таблица 2.3 Требования к классам защищенности АС
Подсистемы и требования
Классы
3Б
3А
2Б
2А
1Д
1Г
1В
1Б
1А
1.Подсистема управления доступом
1.1 Идентификация. Проверка подлинности и контроль доступа субъектов в систему
+
+
+
+
+
+
+
+
+
к терминам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ
+
+
+
+
+
к программам
+
+
+
+
+
к томам, каталогам, файлам, записям, полям записей
+
+
+
+
+
1.2 Управление потоками информации
+
+
+
+
2.Подсистема регистрации и учета
+
+
+
+
+
+
2.1 Регистрация и учет входа/выхода субъектов доступа в/из системы (узла сети)
+
+
+
+
+
+
+
+
+
Выдача печатных (графических) выходных доментов
+
+
+
+
+
+
Запуска/завершения программ и процессов (заданий,задач)
+
+
+
+
+
Доступа программ субъектов, доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ, программам, каталогам, файлам, записям, полям записей
+
+
+
+
+
Изменения полномочий субъектов доступа
+
+
+
Создаваемых защищаемых объектов доступа
+
+
+
+
2.2 Учет носителей информации
+
+
+
+
+
+
+
+
+
2.3 Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти и внешних накопителей
+
+
+
+
+
+
2.4 Сигнализация попыток нарушения защиты
+
+
+
3. Криптографическая подсистема
3.1 Шифрование конфедициальной информации
+
+
+
3.2 Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах
+
3.3 Использование аттестованных (сертифицированных) криптографических средств
+
+
+
4. Подсистема обеспечения целостности
4.1 Обеспечение целостности програмных средств и обрабатываемой информации
+
+
+
+
+
+
+
+
+
4.2 Физическая охрана средств вычислительной техники и носителей информации
+
+
+
+
+
+
+
+
+
4.3 Наличие администратора (службы) защиты информации в АС
+
+
+
4.4 Переодическое тестирование СЗИ НСД
+
+
+
+
+
+
+
+
+
4.5 Наличие средств восстановления СЗИ НСД
+
+
+
+
+
+
+
+
+
4.6 Использование сертифицированных средств защиты
+
+
+
+
+
Обозначения:
«+» – требование к данному классу присутствует
На разработку этих документов наибольшее влияние оказала «Оранжевая киша», однако но влияние в основном отражается в ориентированности обоих документов на системы военного применения и в использовании единой универсальной шкалы степени защищенности.
К недостаткам данного стандарта относятся, как мы уже говорили, отсутствие требований к защите от угроз работоспособности, ориентация на противодействие НСД и отсутствие требований к адекватности реализации политики безопасности. Понятие «политика безопасности» трактуется исключительно как поддержание режима секретности и отсутствие НСД [1], что принципиально неверно. Из-за этою средства защиты ориентируются исключительно на противодействие внешним угрозам, а к структуре самой системы и се функционированию не предъявляется никаких требований. Ранжирование требований по классам защищенности по сравнению с остальными стандартами информационной безопасности максимально упрощено и сведено до определения наличия/отсутствия заданного набора механизмов защиты, что существенно снижает гибкость требований и возможность их практического применения во многих случаях затрудняет.
Несмотря на указанные недостатки, документ ГТК заполнили правовой вакуум в области стандартов информационной безопасности в нашей стране и на определенном этапе оперативно решили актуальную проблему.
2.8. Федеральные критерии безопасности информационных технологий
2.8.1. Цель разработки
«Федеральные критерии безопасности информационных технологий» (Federal Criteria for Information Technology Security) [17] разрабатывались как одна из составляющих «Американского федерального стандарта по обработке информации» (Federal Information Processing Standard), призванного заменить «Оранжевую книгу». Авторами стандарта выступили Национальный институт стандартов и технологий США (National Institute of Standards and Technology) и Агентство национальной безопасности США (National Security Agency). Данный обзор основан на версии 1.0 этого документа, опубликованной в декабре 1992 года.
Этот документ основан на результатах многочисленных исследований в области обеспечения безопасности информационных техпомощи 80-х — начала 90-х годов, а также на анализе опыта использования «Оранжевой книги». Документ представляет собой базу дня разработки и сертификации компонентов информационных технологий с точки зрения обеспечения безопасности. Создание «Федеральных критериев безопасности информационных технологий» преследовало следующие цели.
1. Определение универсального н открытого для дальнейшего развития набора основных требований безопасности, предъявляемых к современным информационным технологиям. Требования к безопасности и критерии оценки уровня защищенности должны соответствовать современному уровню развития информационных технологий и учитывать его прогресс в будущем. Стандарт предлагает обоснованный и структурированный подход к разработке требований безопасности, налагаемый на продукты информационных технологий с учетом областей их применения.
2. Совершенствование существующих требований и критериев безопасности. В связи с развитием информационных технологий назрела необходимость пересмотра фундаментальных принципов безопасности с учетом появления новых областей их применения как в государственном, так и в частном секторе.
3. Приведение в соответствие между собой принятых в разных странах требований и критериев безопасности информационных технологий.
4. Нормативное закрепление основополагающих принципов информационной безопасности. Стандарт является обобщением основных принципов обеспечения безопасности информационных технологий, разработанных в 80-е годы, и обеспечивает преемственность по отношению к ним с целью сохранения достижений в области защиты информации.
2.8.2. Основные положения
«Федеральные критерии безопасности информационных технологий» (далее просто «Федеральные критерии») охватывают практически полный спектр проблем, связанных с защитой и обеспечением безопасности, так как включают все аспекты обеспечения конфиденциальности, целостности и работоспособности.
Основными объектами применения требований безопасности «Федеральных критериев» являются продукты информационных технологий (Information Technology Products) и системы обработки информации (Information Technology Systems). Под продуктом информационных технологий (далее просто «ИТ-продукт») понимается совокупность аппаратных и/или программных средств, которая представляет собой поставляемое конечному потребителю готовое к использованию средство обработки информации. Как правило, ИТ-продукт эксплуатируется не автономно, а интегрируется в систему обработки информации, представляющую собой совокупность ИТ-продуктов, объединенных в функционально полный комплекс, предназначенный для решения прикладных задач. В ряде случаев система обработки информации может состоять только из одного ИТ-продукта, обеспечивающего решение всех стоящих перед системой задач и удовлетворяющего требованиям безопасности. С точки зрения безопасности, принципиальное различие между ИТ-продуктом и системой обработки информации определяется средой их эксплуатации. Продукт информационных технологий обычно разрабатывается в расчете на то, что он будет использован во многих системах обработки информации, и. следовательно, разработчик должен ориентироваться только на самые общие предположения о среде эксплуатации своего продукта, включающие условия применения и общие угрозы. Напротив, система обработки информации разрабатывается для решения прикладных задач в расчете на требования конечных потребителей, что позволяет в полной мере учитывать специфику воздействий со стороны конкретной среды эксплуатации.
«Федеральные критерии» содержат положения, относящиеся только к отдельным продуктам информационных технологий. Вопросы построения систем обработки информации из набора ИТ-продуктов не являются предметом рассмотрения этого документа.
Положения «Федеральных критериев» касаются только собственных средств обеспечения безопасности ИТ-продуктов, т.е. механизмов защиты, встроенных непосредственно в эти продукты в виде соответствующих программных и аппаратных средств. Для повышения их эффективности могут дополнительно применяться внешние системы защиты и средства обеспечения безопасности, к которым относятся как технические средства, так и организационные меры, правовые и юридические нормы. В конечном счете безопасность ИТ-продукта определяется совокупностью собственных средств обеспечения безопасности и внешних средств, являющихся частью среды эксплуатации.
Ключевым понятие концепции информационной безопасности «Федеральных критериев» является понятие «профиля защиты» (Protection Profile). Профиль Защиты — это нормативный документ, который регламентирует все аспекты безопасности ИТ-продукта в виде требований к его проектированию, технологии разработки и квалификационному анализу. Как правило. одни профиль защиты описывает несколько близких по структуре и назначению ИТ-продуктов. Основное внимание в профиле защиты уделяется требованиям к составу средств защиты и качеству их реализации, а также их адекватности предполагаемым угрозам безопасности.
«Федеральные критерии» представляют процесс разработки систем обработки информации, начинающийся с формулирования требований потребителями и заканчивающийся введением в эксплуатацию в виде последовательности следующих основных этапов:
1. Разработка и анализ профиля защиты. Требования, изложенные в профиле защиты, определяют функциональные возможности ИТ-продуктов по обеспечению безопасности и условия эксплуатации, при соблюдении которых гарантируется соответствие предъявляемым требованиям. Кроме требований безопасности профиль содержит требования по соблюдению технологической дисциплины в процессе разработки, тестирования и квалификационного анализа ИТ-продукта. Профиль безопасности анализируется на полноту, непротиворечивость и техническую корректность.
2. Разработка и квалификационный анализ ИТ-продуктов. Разработанные ИТ-продукты подвергаются независимому анализу, целью которого является определение степени соответствия характерно гик продукта сформулированным в профиле защиты требованиям и спецификациям.
3. Компоновка и сертификация системы обработки информации в целом. Успешно прошедшие квалификацию уровня безопасности ИТ-продукты интегрируются в систему обработки информации. Полученная в результате система должна удовлетворять заявленным в профиле защиты требованиям при соблюдении указанных в нем условий эксплуатации.
«Федеральные критерии» регламентируют только первый этап этой схемы — разработку и анализ профиля защиты. Процесс создания ИТ-продуктов и компоновка систем обработки информации остаются вне рамок этого стандарта.
2.8.3. Профиль защиты
Как уже говорилось, профиль защиты является центральным понятием «Федеральных критериев», большая часть содержания которых представляет собой описание разделов профиля защиты, включающее таксономию требований безопасности и их ранжирование. Рассмотрим назначение, структуру и этапы разработки профиля защиты.
2.8.3.1. Назначение и структура профиля защиты
Профиль защиты предназначен для определения и обоснования состава и содержания средств защиты, спецификации технологии разработки и регламентации процесса квалификационного анализа ИТ-продукта. Профиль защиты состоит из следующих пяти разделов:
· описание;
· обоснование;
· функциональные требования к ИТ-продукту;
· требования к технологии разработки ИТ-продукта;
· требования к процессу квалификационного анализа ИТ-продукта.
Описание профиля содержит классификационную информацию, необходимую для его идентификации в специальной картотеке. «Федеральные критерии» предлагают поддерживать такую картотеку на общегосударственном уровне. Это позволит любой организации воспользоваться созданными ранее профилями защиты непосредственно или использовать их в качестве прототипов для разработки новых. В описании профиля защиты должна быть охарактеризована основная проблема или группа проблем обеспечения безопасности, решаемых с помощью применения данною профиля.
Обоснование содержит описание среды эксплуатации, предполагаемых угроз безопасности и методов использования ИТ-продукта. Кроме того, этот раздел содержит подробный перечень задач по обеспечению безопасности, решаемых с помощью данного профиля. Эта информация дает возможность определить, в какой мере данный профиль защиты пригоден для применения в той или иной ситуации. Предполагается, что данный раздел ориентирован на службы безопасности организаций. которые изучают возможность использования ИТ-продукта, соответствующего данному профилю защиты.
Раздел функциональные требовании к ИТ-продукту содержит описание функциональных возможностей средств защиты ИТ-продукта и определяет условия, в которых обеспечивается безопасность в виде перечня угроз, которым успешно противостоят предложенные средства защиты. Угрозы, лежащие вне этого диапазона, должны быть устранены с помощью дополнительных, не входящих в состав продукта, средств обеспечения безопасности. Очевидно, что чем сильнее и опаснее угрозы, тем более мощными и стойкими должны быть средства, реализующие функции защиты.
Раздел требований к технологии разработки ИТ-продукта охватывает все этапы его создания, начиная от разработки проекта и заканчивая вводом готовой системы в эксплуатацию. Раздел содержит требования как к самому процессу разработки, так и к условиям, в которых она проводится, к используемым технологическим средствам, а также к документированию этого процесса. Выполнение требований этого раздела является непременным условием для проведения квалификационного анализа и сертификации ИТ-продукта.
Раздел требований к процессу квалификационного анализа ИТ-продукта регламентирует порядок проведения квалификационного анализа в виде методики исследований и тестирования ИТ-продукта. Объем и глубина требуемых исследований зависят от наиболее вероятных типов угроз, среды применения и планируемой технологии эксплуатации.
«Федеральные критерии» содержат подробное описание всех трех разделов профиля защиты, посвященных требованиям, включающее их таксономию и ранжирование для каждого раздела. В данном обзоре основное внимание уделено функциональным требованиям, так как именно в этой области «Федеральные критерии» проделали значительный шаг вперед по сравнению с предшествующими стандартами.
2.8.3.2 Этапы разработки профиля защиты
Разработка профиля защиты осуществляется в три этапа: анализ среды применения ИТ-продукта с точки зрения безопасности, выбор профиля-прототипа и синтез требований. На рис. 2.4 приведена общая схема разработки профиля защиты.
На первой стадии проводится анализ информации о среде предполагаемого применения ИТ-продукта, действующих в этой среде угрозах безопасности и используемых этими угрозами недостатках защиты. Анализ проводится с учетом технологии использования продукта, а также существующих стандартов и нормативов, регламентирующих его эксплуатацию. Второй этап состоит в поиске профиля, который может быть использован в качестве прототипа. Как уже говорилось, «Федеральные критерии» предусматривают создание специальной, доступной для разработчиков ИТ-продуктов картотеки, в которую должны быть помещены все разработанные когда-либо профили защиты. Это позволит минимизировать затраты на создание профилей и учесть опыт предыдущих разработок.
Рис. 2.4. Схема разработки профиля согласно «Федеральным критериям».
Этап синтеза требований включает выбор наиболее существенных для условий функционирования продукта функций защиты и их ранжирование по степени важности с точки зрения обеспечения качества защиты. Выбор специфичных для среды требований безопасности должен быть основан на их эффективности для решения задачи противодействия угрозам. Разработчик профиля должен показать, что выполнение выдвинутых требований ведет к обеспечению требуемого уровня безопасности посредством успешного противостояния заданному множеству угроз и устранения недостатков защиты.
При разработке профиля защиты необходимо анализировать связи и зависимости, существующие между функциональными требованиями и требованиями к процессу разработки, а также между отдельными требованиями внутри этих разделов. По завершении разработки профиль защиты подвергается проверке, целью которой является подтверждение его полноты, корректности, непротиворечивости и реализуемости.
2.8.4. Функциональные требования к ИТ-продукту
«Федеральные критерии» предлагают набор функциональных требований, реализация которых позволяет противостоять наиболее распространенным угрозам безопасности, относящихся к широкому спектру ИТ-продуктов и областей их применения. Данные требования разработаны с учетом возможности расширения и адаптации к конкретным условиям эксплуатации ИТ-продуктов и могут совершенствоваться параллельно процессу развития информационных технологий. Требования, изложенные в «Федеральных критериях», разработаны на основе обобщения существовавших на момент их создания стандартов информационной безопасности – «Оранжевой книги» и «Европейских критериев» (п. 2.5 и 2.6).
Функциональные требования, приведенные в «Федеральных критериях», определяют состав и функциональные возможности ТСВ. Как говорилось в п.2.2, ТСВ объединяет все компоненты ИТ-продукта (аппаратные. программные и специальные средства), реализующие функции защиты. Таким образом, функциональные Требования, направленные на обеспечение безопасности. относятся либо к внутренним элементам ТСВ, либо к его внешним функциям, доступным через специальные .интерфейсы.
Для того чтобы расширить спектр потенциального применения профиля защиты, в «Федеральных критериях» при описании функциональных требований предполагается что ТСВ является единственной частью ИТ-продукта. которая нуждается в защите и обладает такой характеристикой, как уровень защищенности. По этой причине предполагается достаточным установить множество требований, касающихся только безопасности ТСВ.
Функциональные требования профиля защиты задаются в виде общих положений и косвенным образом определяют множество угроз, которым может успешно противостоять удовлетворяющий им ИТ-продукт.
2.8.4.1. Таксономия функциональных требований
Функциональные требования «Федеральных критериев» разделены на восемь классов и определяют все аспекты функционирования ТСВ. Таксономия классов функциональных требований приведена на рис. 2.5. Все классы имеют непосредственное отношение к обеспечению безопасности функционирования ТСВ. Реализация политики безопасности должна быть поддержана средствами, обеспечивающими надежность функционирования как самого ТСВ, так и механизмов осуществления политики безопасности.
Рис. 2.5 Таксономия функциональных требований «Федеральных критериев»
Эти средства также входят в состав ТСВ, хотя, с точки зрения противодействия угрозам, вносят только косвенный вклад в общую защиту И Т-продукта.
Поскольку «Федеральные критерии» по сравнению с «Оранжевой книгой» являются стандартом нового поколения и, кроме того, никогда не рассматривались в отечественных публикациях, остановимся на функциональных требованиях более подробно.
Требования к реализации политики безопасности описывают функции ТСВ, реализующие политику безопасности, и состоят из четырех групп требований: к политике аудита, к политике управления доступом, к политике обеспечения работоспособности и к управлению безопасностью. Эти требования носят весьма общий характер, что позволяет рассматривать их в качестве прототипа, обеспечивающего поддержку широкого спектра. политик и моделей безопасности (см. главу 4, II тома).
Политика аудита включают разделы, относящиеся к идентификации и аутентификации, процедуре регистрации пользователя в системе, обеспечению прямого взаимодействия с ТСВ, а также регистрацию и учет событий. Основная задача политики управления аудитом — обеспечить возможность однозначной идентификации субъекта, ответственного за те или иные действия в системе.
Идентификация и аутентификация позволяют установить однозначное соответствие между пользователями и представляющими их в ВС субъектами, а также подтвердить подлинность этого соответствия.
Регистрация пользователя в системе означает создание субъекта взаимодействия, с идентификатором которого будут ассоциироваться все последующие действия пользователя. К процедуре регистрации также относится учет места, времени и других параметров подключения к системе и ее блокирование во время отсутствия пользователя.
Обеспечение прямого взаимодействия с ТСВ гарантирует, что пользователь взаимодействует с компонентами ТСВ напрямую, т.e. информация, которая передается в ТСВ и обратно, не подвергается перехвату или искажению. Поддержка прямого взаимодействия с ТСВ особенно важна для управления безопасностью (например: при администрировании прав доступа и полномочий пользователей).
Регистрация и учет событий в системе позволяет распознавать потенциально опасные ситуации и сигнализировать о случаях нарушения безопасности. Регистрация событий включает распознавание, учет и анализ действий пользователя, представляющих интерес с точки зрения безопасности.
Политики управления доступом содержит следующие разделы: произвольное управление доступом, норматив-нос управление доступом и контроль скрытых каналов утечки информации. Политика управления доступом является основным механизмом защиты так как непосредственно обеспечивает конфиденциальность и целостность обрабатываемой информации.
Произвольное управление доступом позволяет осуществлять назначение прав доступа с точностью до идентифицируемых субъектов и объектов, а также поддерживаемых типов доступа и, кроме того, обеспечивает контроль за распространением прав доступа среди субъектов.
Нормативное управление доступом, в отличие от произвольного, основано на контроле информационных потоков между субъектами и объектами и их атрибутах безопасности, что позволяет регламентировать порядок использования информации в системе и противостоять атакам типа «троянского коня».
Контроль скрытых каналов утечки информации включает технические и административные меры, направленные на ликвидацию таких каналов посредством минимизации объема совместно используемых ресурсов и введения активных «шумовых помех».
Политика обеспечения работоспособности системы включает контроль за распределением ресурсов и обеспечение отказоустойчивости. Обеспечение работоспособности позволяет гарантировать доступность ресурсов и сервиса системы, а также корректное восстановление системы после сбоев.
Контроль за распределением ресурсов осуществляется посредством введения ограничений (квот) на их Потребление или приоритетной системы распределения ресурсов.
Обеспечение отказоустойчивости входит в сферу безопасности наравне с другими требованиями, так как противостоит угрозам работоспособности.
Управление безопасностью регламентирует следующие аспекты функционирования системы:
· компоновка, установка, конфигурация и поддержка ТСВ;
· администрирование атрибутов безопасности пользователей (идентификаторов, полномочий, доступных ресурсов и т.д.);
· администрирование политики управления доступом;
· управление потреблением ресурсов системы;
· аудит действий пользователей.
Мониторинг взаимодействии. Требования этого раздела регламентируют порядок взаимодействия между компонентами системы и прохождения информационных потоков через ТСВ. Реализация политики безопасности будет эффективна только в том случае, если все без исключения взаимодействия в системе, т. е. доступ к объектам, ресурсам и сервису, осуществляются при обязательном посредничестве ТСВ.
Логическая защита ТСВ. Требования данной группы устанавливают порядок доступа к внутренним компонентам ТСВ (данным и программам). ТСВ должна быть защищена от внешних воздействий со стороны непривилегированных пользователей, в противном случае искажение программ и данных, находящихся в ТСВ. может привести к полному подавлению функций защиты.
Необходимо подчеркнуть, что политика безопасности, мониторинг взаимодействий и логическая защита ТСВ являются обязательными компонентами всех профилей защиты вне зависимости от назначения и среды применения ИТ-продукта.
Физическая защита ТСВ. Требования этой группы задают ограничения на физический доступ к компонентам ТСВ, а также допустимые физические параметры среды функционирования ВС.
Самоконтроль ТСВ. Требования, касающиеся самоконтроля ТСВ, определяют возможности обеспечения контроля корректности выполнения функций ТСВ и целостности программ и данных, входящих в ТСВ. Выполнение этих требований позволяет вовремя обнаруживать нарушения целостности компонентов ТСВ, произошедшие либо в результате целенаправленного воздействия, либо в следствии сбоя в работе аппаратных или программных средств, и осуществлять восстановление целостности ТСВ.
Инициализация и восстановление ТСВ. Требования данной группы устанавливают возможности ТСВ по контролю за процессом собственной инициализации и способности к самовосстановлению после сбоев. Процесс восстановления после сбоя должен происходить без нарушений, даже временных, функционирования средств защиты. Восстановленное состояние ТСВ должно соответствовать требованиям политики безопасности, мониторинга взаимодействий и самоконтроля целостности.
Ограничение привилегий при работе с ТСВ. Требования этой группы устанавливают порядок назначения полномочий для работы с ТСВ. Основным принципом назначения таких полномочий является принцип минимальной достаточности. Это обеспечивается посредством постоянного контроля и, при необходимости, автоматического понижения привилегий пользователей при обращении к компонентам или сервису ТСВ. Соблюдение этого принципа позволяет минимизировать нарушения целостности в случае возникновения сбоев или нарушений безопасности.
Простота использования ТСВ. Эти требования обеспечивают удобство пользования возможностями ТСВ как для высококвалифицированных администраторов, ответственных за функционирование и безопасность системы, так и для рядовых пользователей, а также для разработчиков прикладных программ, взаимодействующих с ТСВ. К этому классу требований относятся: порядок реагирования ТСВ на ошибки в действиях пользователей и попытки нарушения безопасности, устанавливаемые по умолчанию полномочия, интерфейс пользователей и администратора.
Объем и глубина реализации функциональных требований зависят от того, какую степень защищенности должна обеспечивать ТСВ конкретного ИТ-продукта, а также от того, какие угрозы безопасности возможны в среде его эксплуатации. Степень обеспечения требуемого уровня защищенности зависит от реализованной политики безопасности, от квалификации ответственного за безопасность персонала, от правильности администрирования ТСВ и соблюдения рядовыми пользователями правил политики безопасности.
2.8.4.2. Ранжирование функциональных требований
Состав и содержание включенных в профиль защиты функциональных требований определяются средой эксплуатации ИТ-продукта. Чтобы обосновать выбор тех или иных требований и не вступать в противоречие сосуществующими стандартами в области безопасности ИТ-продуктов, функциональные требования, приведенные в «Федеральных критериях», ранжируются по уровням с помощью следующих четырех критериев: широта сферы применения, степень детализации, функциональный состав средств защиты, обеспечиваемый уровень безопасности.
Широта сферы применения определяется множеством сущностей, к которому могут быть применены данные требования, а именно:
· пользователи системы, субъекты и объекты доступа;
· функции ТСВ и интерфейс взаимодействия с ТСВ;
· аппаратные, программные и специальные компонентыТСВ;
· множество параметров конфигурации ТСВ.
Например, требования, из разделов управления доступом, аудита, обеспечения работоспособности, мониторинга взаимодействий и простоты использования ТСВ могут относиться только к определенному подмножеству объектов доступа и параметров конфигурации ТСВ. Обеспечение прямого взаимодействия с ТСВ требуется только для некоторого подмножества функций ТСВ.
Степень детализации требований определяется множеством атрибутов сущностей, к которым применяются данные требования, либо ко всем атрибутам пользователей, субъектов или объектов, либо только к некоторому подмножеству этих атрибутов. Например, требования из разделов управления доступом, аудита и мониторинга взаимодействий могут относить только к некоторому подмножеству атрибутов субъектов и объектов, а именно к правам доступа, групповым идентификаторам пользователей, но не к атрибутам состояния субъектов и объектов и не к индивидуальным идентификаторам.
Функциональный состав средств защиты определяется множеством функций, включенных в ТСВ для реализации той или иной группы функциональных требований. Например, политика управления доступом может включить либо произвольное, либо нормативное управление доступом, или и то и другое одновременно.
Обеспечиваемый уровень безопасности определяется условиями, в которых функциональные компоненты ТСВ способны противостоять заданному множеству угроз, отказам и сбоям. Например, нормативное управление доступом обеспечивает более высокий уровень безопасноести, чем произвольное, в силу ею способности противостоять атакам типа «троянского коня».
Ранжирование вести предполагает установление некоторого отношения порядка. Однако независимое ранжирование функциональных требований по каждому из описанных критериев хотя и дает некоторое представление о различиях между функциональными возможностями средств защиты, не позволяет установить четкую, линейную шкалу уровней безопасности. Однозначного отношения порядка, определенного на множестве функциональных требований, не существует, так как значение требований и уровень обеспечиваемой ими защиты зависят не только от их содержания, но и от назначения ИТ-продукта и среды его эксплуатации. Для одних систем наиболее важными будут идентификация и аутентификация пользователей, а для других — реализация политики управления доступом или обеспечение работоспособности.
Поэтому в «Федеральных критериях» отсутствую г рекомендации как по выбор) и применению тех или иных функциональных требований, так и по определению их роли в системе обеспечения безопасности вместо жестких указаний этот документ содержит согласованный с предшествующими ему стандартами («Оранжевая кита», «Европейские критерии») ранжированный перечень функциональных требовании и представляет разработчикам профиля защиты возможность самостоятельно сделать выбор необходимых методов и средств обеспечения безопасности, основанный на назначении и специфике среды эксплуатации ИТ-продукта.
Приводимое ранжирование не противоречит предшествующим стандартам и вводится для исключения ошибок в определении степени защищенности системы из-за неправильной оценки значимости отдельных групп требований. Кроме того, ранжирование предоставляет разработчикам и пользователям возможность для обоснованной оценки реально обеспечиваемого уровня безопасности.
Применение критериев ранжирования к различным группам функциональных требований представлено в табл. 2.3.
В Приложении I приведен полный ранжированный перечень функциональных требований «Федеральных критериев».
2.8.5. Требования к технологии разработки ИТ-продукта
Основное назначение требований к технологии разработки ИТ-продукта — обеспечить адекватность условий разработки функциональным требованиям, выдвинутым в соответствующем разделе профиля защиты, и установить ответственность разработчика за корректность реализации этих требований. Данный раздел регламентирует процесс создания, тестирования, документирования и сопровождения ИТ-продукта. Таксономия требований к технологии разработки ИТ-продукта приведена на рис. 2.6.
Требования к технологии разработки ИТ-продуктов включают четыре раздела: требования к процессу разработки, к среде разработки, к документированию и к сопровождению.
Таблица 2.3.Ранжирование функциональных требований «Федеральных критериев».
Функциональные требования
Широта сферы применения
Степень детализации
Функциональный состав средств защиты
Обеспечиваемый уровень безопасности
реализация политики безопасности
политика аудита
идентификация и аутентификация
*
*
peгистрация в системе
*
обеспечение прямого взаимодействия с ТСВ
*
*
регистрация и учет событий
*
*
политика управления доступом
*
*
*
контроль скрытых каналов
*
*
политика обеспечения работоспособности
контроль за распределением ресурсов
*
*
отказоустойчивость
–
–
–
–
управление безопасностью
*
*
мониторинг взаимодействий
*
*
*
логическая защита ТСВ
*
физическая защита ТСВ
*
*
самоконтроль ТСВ
*
*
инициализация и восстановление ТСВ
*
ограничение привилегий при работе с ТСВ
*
простота использования ТСВ
*
*
Требования к процессу разработки содержат подразделы, относящиеся к проектированию, реализации, тестированию и анализу ИТ-продукта. Особую роль играют требования адекватности реализации функций ТСВ, обеспечивающие корректность выполнения функциональных требований профиля защиты.
Требования к среде разработки позволяют обеспечить качество процесса создания ИТ-продукта с помощью применения современных технологий проектирования, программирования и тестирования, а также регламентируют дистрибуцию конечного продукта и управление процессом разработки.
Требования к документированию определяют состав и содержание технологической документации, позволяющей производителю ИТ-продукта оказать соответствие самого продукта и технологии ею изготовления выдвинутым требованиям.
Требования к сопровождению ИТ-продукта определяют обязательства производителя перед пользователями. Выполнение данных требований позволяет обеспечить эффективную и надежную эксплуатацию ИТ-продукта. Они регламентируют состав пользовательской и административной документации, процедуру обновления версий и исправления ошибок, а также инсталляцию продукта.
«Федеральные критерии» содержат ранжированный перечень типовых требований к технологии разработки ИТ-продуктов. Выполнение требований к технологии разработки является необходимым условием для проведения процедуры квалификационного анализа.
Рис. 2.6 Таксономия требований «Федеральных критериев» к технологии разработки ИТ-продукта.
2.8.6. Требования к процессу квалификационною анализа ИТ-продукта
Требования к процесса квалификационною анализа ИТ-продукта призваны обеспечить надежность и корректность этого процесса. Раздел содержит три группы требований, регламентирующих анализ, контроль и тестирование ИТ-продукта. Таксономия требований этого раздела приведена на рис. 2.7. к процессу квалификационного анализа ИТ-продукта.
Рис. 2.7 Таксномия требований «Федеральных критериев» к процессу квалификационнго анализа ИТ-продукта
Раздел требований к анализу ИТ-продукта содержит требования к проведению независимого анализа предложенного решения и к его реализации в виде конкретного средства.
Раздел требований к контролю регламентирует проверку соответствия среды разработки ИТ-продукта и обеспечиваемого производителем сопровождения требованиям к технологии разработки.
Требования к тестированию описывают процедуру проведения тестирования функций ТСВ как самим разработчиком ИТ-продукта, так и независимыми экспертами.
Нетрудно заметить, что эти требования регламентируют процесс квалификационного анализа только в общих чертах и, по замыслу разработчиков стандарта, должны послужить основой для разработки специализированных методик квалификации уровня безопасности, ориентированных на различные области применения и классы ИТ-продуктов.
2.8.7. Выводы
«Федеральные критерии безопасности информационных технологий» являются первым стандартом информационной безопасности, в котором определяются три независимые группы требований: функциональные требования к средствам защиты, требования к технологии разработки и к процессу квалификационного анализа. Авторами этого стандарта впервые предложена концепция профиля защиты — документа, содержащего описание всех требований безопасности как к самому ИТ-продукту, так и к процессу его проектирования, разработки, тестирования и квалификационного анализа.
Функциональные требования безопасности хорошо структурированы и описывают все аспекты функционирования ТСВ. Требования к технологии разработки, впервые появившиеся в этом документе, побуждают производителей использовать современные технологии программирования, позволяющие подтвердить безопасность своего продукта. Требования к процессу квалификационного анализа носят довольно общий характер и не содержат конкретных методик тестирования и исследования безопасности ИТ-продуктов.
Разработчики «Федеральных критериев» отказались от используемого в «Оранжевой книге» подхода к оценке уровня безопасности ИТ-продукта на основании обобщенной универсальной шкалы классов безопасности. Вместо этого предлагается независимое ранжирование требований каждой группы, т. е. вместо единой шкалы используется множество частных, шкал-критериев, характеризующих обеспечиваемый уровень безопасности. Данный подход позволяет разработчикам и пользователям ИТ-продукта выбрать наиболее приемлемое решение и точно определить необходимый и достаточный набор требований для каждого конкретного ИТ-продукта и среды его эксплуатации.
Особо отметим, что этот стандарт рассматривает устранение недостатков существующих средств безопасности как одну из задач защиты наряду с противодействием угрозам безопасности и реализацией модели безопасности.
Данный стандарт ознаменовал появление новою поколения руководящих документов в области информационной безопасности, а его основные положения послужили базой для разработки «Канадских критериев безопасности компьютерных систем» (п. 2.9) и «Единых критериев безопасности информационных технологий» (п. 2 10).
2.9. «Канадские критерии безопасности компьютерных систем»
2.9.1. Цель разработки
«Канадские критерии безопасности компьютерных систем» (Canadian Trusted Computer Product Evaluation Criteria, далее просто «Канадские критерии») [18] были разработаны в Центре безопасности ведомства безопасноси связи Канады (Canadian System Security Centre Communication Security Establishment) для использования в качестве национального стандарта безопасности компьютерных систем. Этот обзор основан на третьей версии стандарта, опубликованной в январе 1993 года.
«Канадские критерии» разрабатывались как основа для оценки эффективности средств обеспечения безопасности компьютерных систем, при этом преследовались следующие цели:
1. Предложить единую шкалу критериев оценки безопасности компьютерных систем, позволяющую сравнивать системы обработки конфиденциальной информации по степени обеспечения безопасности.
2. Создать основу для разработки спецификаций безопасных компьютерных систем, которая могла бы использоваться разработчиками при проектировании подобных систем в качестве руководства для определения состава функций средств защиты.
3. Предложить унифицированный подход и стандаршые средства для описания характеристик безопасных компьютерных систем.
«Канадские критерии» разрабатывались на основе «Оранжевой книги» (п. 2.5) и под влиянием «Федеральных критериев безопасности информационных технологий» (п. 2.8). В отличии от «Оранжевой книги», ориентированной в основном на разработку и сертификацию многопользовательских операционных систем и требующей определенной интерпретации для применения в других областях (например, для баз данных и сетей), «Канадские критерии» были изначально нацелены на широкий диапазон компьютерных систем. Этот стандарт может быть использован для разработки требований безопасности, спецификаций средств защиты и сертификации программного обеспечения как рабочих станций, так и многопроцессорных вычислительных систем, персональных и многопользовательских операционных систем, систем управления базами данных, распределенных, сетевых, встроенных, объектно-ориентированных и других систем.
2.9.2. Базовые понятия «Канадских критериев»
В «Канадских критериях» используется отличающееся от общепринятого толкование ряда терминов. Разработчики предложили оригинальный подход к описанию взаимодействия пользователей с компьютерной системой, инвариантный по отношению к политике безопасности.
2.9.2.1 Объекты и субъекты
В «Канадских критериях» все компоненты системы, находящиеся под управлением ТСВ. называются объектами. Объекты могут находиться в одном из следующих тpex состояний: объект-пользователь, объект-процесс, пассивный объект, и, в зависимости от состояния, обозначают пользователей, процессы и объекты соответственно.
Пользователь представляет собой физическое лицо. взаимодействующее с компьютерной системой. Каждый пользователь имеет собственный уникальный идентификатор, права доступа, уровень привилегий и т.д. С пользователями ассоциируются все процессы, существующие в системе. Процесс, или активный объект, представляющий пользователя в компьютерной системе, — это программа, выполнение которой инициировано пользователем. Объект представляет собой пассивный элемент, над которым выполняют действия пользователи и процессы. Все взаимодействия объектов контролируются в соответствии с реализованной в компьютерной системе поли гибкой безопасности.
Таким образом, в «Канадских критериях» отсутствует понятие субъект, широко используемое в других стандартах информационной безопасности для описания процесса взаимодействия [7, 17]. Обычно под субъектом принято понимать активного участника взаимодействия, а под объектом — пассивного. Напротив, в «Канадских критериях» все сущности компьютерной системы рассматриваются как объекты, а их взаимодействие описывается тройкой пользователь-процесс-объект. Однако, противоречия здесь нет. Обычно (например, в «Оранжевой книге») понятие субъект представляет собой комбинацию понятий пользователь и процесс, действующий от его имени. Соответственно, ситуация, когда один пользователь запускает много процессов, с позиций «Оранжевой книги» описывается с помощью множества субъектов, каждый из которых с точки зрения политики безопасности будет рассматриваться как независимый участник взаимодействия. «Канадские критерии» позволяют использовать для описания этой ситуации один объект-пользователь и множество ассоциированных с ним объектов-процессов. При этом политика безопасности будет применяться по отношению к одному пользователю, осуществляющему доступ к объектам посредством нескольких процессов. «Канадские критерии» просго конкретизируют отношение доступа пользователя к информации, находящейся в компьютерной системе, с помощью терминов, описывающих реальный механизм осуществления доступа. Соответствие между базовыми понятиями «Канадских критериев» и «Оранжевой книги» показано на рис. 2.8.
Рис. 2.8 Соответствие понятий «Канадских критериев» и «Оранжевой книги».
2.9.2.2. Теги
При описании критериев конфиденциальности и целостности (произвольного и нормативного управления доступом и целостностью) в «Канадских критериях» для обеспечения максимальной степени абстракции и инвариантности по отношению к политике безопасности и методам ее реализации используется понятие тег (tag), обозначающее совокупность атрибутов безопасности, ассоциированных с пользователем, процессом или объектом. В качестве тега пользователя, процесса или объекта могут выступать соответствующий уникальный идентификатор, метка безопасности или целостности. криптографический ключ, таблица прав доступа или другие атрибуты в соответствии с реализованной в компьютерной системе политикой безопасности.
2.9.3. Основные положения и структура «Канадских критериев»
Возможность применения «Канадских критериев» к такому широкому кругу различных по назначению систем определяется используемым в них принципом дуальною представления требований безопасное ги в виде функциональных требований к средствам защиты и требовании к адекватности их реализации.
Функциональные критерии представляют собой частые метрики. предназначенные для определения показателей эффективности и средств защиты в виде уровня их возможностей по отражению угроз соответствующего типа. Функциональные критерии разделяются на четыре группы: критерии конфиденциальности, целостности, работоспособности и аудита. Угрозы несанкционированного доступа к информации предотвращаются с помощью средств требования к которым содержатся в разделе критериев конфиденциальности. Угрозам несанкционированного изменения информации или ее искажения противостоят средства защиты, функциональные требования к которым задаются критериями целостности. Требования к средствам, обеспечивающим защиту от угроз работоспособности, описаны в разделе критериев работоспособности. Угрозы, направленные на фальсификацию протоколов и манипуляции с внутрисистемной информацией, предотвращаются средствами аудита, требования к которым содержатся в одноименном разделе функциональных критериев. Такая специализация критериев и требований и, соответственно, реализующих эти требования средств защиты позволяет четко определить стоящие перед ними задачи и разграничить их функции.
Таблица 2.4. Идентификаторы уровней «Канадских критериев» .
Идентификатор
Наименование
Уровни
Критерии конфиденциальности
СС
Контроль скрытых каналов
СС-О — СС-3
СО
Произвольное управление доступом
CD-0 — CD-4
CM
Нормативное управление доступом
СМ-0 — СМ-4
CR
Повторное использование объектов
CR-0—CR-1
Критерии целостности
IB
Домены целостности
1В-0—1В-2
ID
Произвольное управление целостностью
ID-0—ID-4
IM
Нормативное управление целостностью
IM-0—IM-4
IP
Физическая целостность
IP-0—IP-4
IR
Возможность осуществления отката
IR-O—IR-2
IS
Разделение ролей
IS-O—IS-3
IT
Самотестирование
IT-0—IT-3
Критерии работоспособности
AC
Контроль за распределением ресурсов
AC-0—AC-3
AF
Устойчивость к отказам и сбоям
AF-()—AF-3
AR
Живучесть
AR-O—AR-3
AY
Восстановление
AY-0—AY-3
Критерии аудита
WA
Регистрация и учет событий в системе
WA-O—WA-3
WI
Идентификация и аутентификация
WI-0—WI-3
WT
Прямое взаимодействие с ТСВ
WT-O—WT-3
T
Адекватность
T-O—T-7
Рис. 2.9 Таксономия функциональных критериев «Канадских критериев».
Рис. 2.10. Таксономия критериев адекватности реализации политики безопасности «Канадских критериев».
Внутри каждой труппы критериев определены уровни безопасности, отражающие возможное и средств защиты по решению задач данного раздела. Ранжирование по уровням производится на основании мощности используемых методов защиты и класса отражаемых угроз соответствующего типа. Уровни с большим номером обеспечивают более полную функциональность и, соответственно, более высокую степень безопасности. Таксономия функциональных критериев показана на рис. 2.9, а в таб. 2.4 приведены идентификаторы уровней.
Адекватность реализации определяется тем, насколько точно и последовательно средства, обеспечивающие защиту, реализуют принятую в компьютерной системе политику безопасности. Согласно «Канадским критериям», политика безопасности представляет собой множество правил, регламентирующих обработку, хранение и использование информации. Критерии адекватности рассматриваются без разделения на подгруппы и определяют требования к процессу проектирования и разработки компьютерной системы. Уровень адекватности присваивается всей системе в целом, причем более высокий уровень означает более полную и корректную реализацию политики безопасности. Таксономия критериев адекватности показана на рис. 2.10. Критерии адекватности отражают уровень корректное и реализации политики безопасности и охватывают все стадии проектирования, разработки и эксплуатации компьютерной системы. За некоторым исключением (контроль скрытых каналов) взаимосвязь между функциональными требованиями к средствам защиты и требованиями адекватности реализации политики безопасности отсутствует.
Таким образом, «Канадские критерии» определяют степень безопасности компьютерной системы как совокупность функциональных возможностей используемых средств защиты, характеризующуюся частными показателями обеспечиваемого уровня безопасности, и одного обобщенного параметра — уровня адекватности реализации политики безопасности.
В состав приложений к «Канадским критериям» входят руководства по применению функциональных критериев и критериев адекватности реализации, а также подробное описание предложенной в них концепции обеспечения безопасности информации. Присутствует приложение, включающее набор стандартных профилей защиты, содержащих типовые наборы требований к компьютерным системам, применяющимся в государственных учреждениях. Этот подход имеет много общего с концепцией профилей защиты, предлагаемой в «Федеральных критериях» (п. 2.8). Приложение 11 содержит ранжированный перечень функциональных критериев и критериев адекватности «Канадских критериев».
2.9.4. Выводы
«Канадские критерии оценки безопасности компьютерных систем явились первым стандартом информационной безопасности, в котором на уровне структуры документа функциональные требования к средствам защиты отделены от требований адекватности и качества реализации политики безопасности. Функциональные требования к средствам защиты четко структурированы и описывают все аспекты функционирования ТСВ. Требования к адекватности реализации политики безопасности, впервые появившиеся в виде отдельного раздела, позволяющего определить степень доверия к средствам обеспечения безопасности
Впервые столько внимания уделено взаимному соответствию и взаимодействию всех систем средств обеспечения безопасности. Наиболее прогрессивными являются требования доказательств корректности реализации функциональных требований и их формального соответствия политике и модели безопасности.
В «Канадских критериях», как и в «Федеральных критериях», отвергается подход к оценке уровня безопасности с помощью универсальной шкалы и используется независимое ранжирование требований по каждому разделу, образующее множество частых критериев, характеризующих работу подсистем обеспечения безопасности. Кроме того, уровень адекватности реализации политики безопасности характеризует качество всей системы в целом. Однако по сравнению с «Федеральными критериями» требования к технологии разработки выражены слабо и недостаточно конкретизированы в части используемых методов и средств.
«Канадские критерии оценки безопасности компьютерных систем» представляют собой хорошо сбалансированный конгломерат «Оранжевой книги» и «Федеральных критериев», усиленный требованиями адекватности реализации политики безопасности, и наравне с другими стандартами послужили основой для разработки «Единых критериев безопасности информационных технологий» (п. 2.10).
2.10. Единые критерии безопасности информационных технологий
2.10.1. Цель разработки
«Единые критерии безопасности информационных технологий» (Common Criteria for Information Technology Security Evaluation, далее просто «Единые критерии») [19] являются результатом совместных усилий авторов «Европейских критериев безопасности информационных технологий», «Федеральных критериев безопасности информационных технологий» и «Канадских критериев безопасности компьютерных систем» по объединению этих стандартов в единый согласованный документ. Работа над этим самым масштабным в истории стандартов информационной безопасности проектом началась в июне 1993 года с целью преодоления концептуальных и технических различий между указанными документами, их согласования и создания единого международного стандарта. Данный стандарт должен быть утвержден Международной организацией по стандартизации (ISO) в рамках начатого этой организацией в 1990 году проекта по созданию международного стандарта информационной безопасности.
Первая версия «Единых критериев» была опубликована 31 января 1996 года. Разработчиками документа выступили Национальный институт стандартов и технологий и Агентство национальной безопасности США, а также соответствующие организации Великобритании, Канады, Франции и Нидерландов. В течение 1997 года ожидается следующая версия с исправлениями и дополнениями.
«Единые критерии» согласованы с существующими стандартами и развивают их путем введения новых концепций, соответствующих современному уровню развития информационных технологий. Этот документ разработан на основе достижений многочисленных исследований в области безопасности информационных технологий 90-х годов и на результатах анализа опыта применения положенных в его основу стандартов. «Единые критерии» оперируют ‘уже знакомым нам по «Федеральным критериям» понятием «продукт информационных технологий», или ИТ-продукт, и используют предложенную в них концепцию профиля защиты.
«Единые критерии» разрабатывались в расчете на три группы специалистов, в равной степени являющихся пользователями этого документа: производителей и; потребителей продуктов информационных технологий, а также экспертов по квалификации уровня безопасности (см. п. 2.2).
Потребители рассматривают квалификацию уровня безопасности ИT- продукта как метод определения соответствия ИТ-продукта запросам. Обычно эти запреты составляются на основании результатов проведенного анализа рисков и выбранной политики безопасноести. «Единые критерии» играют существенную роль в процессе формирования запросов потребителей, так как содержат механизмы, позволяющие, сформулировать эти запросы в виде стандартизованных требований. Это позволяет потребителям принять обоснованное решение о возможности использования тех или иных продуктов. Наконец, «Единые критерии» предоставляют потребителям механизм профилей защиты, с помощью которого они могут выразить специфичные для них требования, не заботясь о механизмах их реализации.
Производители должны использовать «Единые критерии» в ходе проектирования и разработки ИТ-продуктов, а также при их подготовке к квалификационному анализу и сертификации. Этот документ дает возможность производителям на основании анализа запросов потребителей определить набор требований, которым должен удовлетворять разрабатываемый ими продукт. Производители используют предлагаемую «Едиными критериями» технологию для того, чтобы заявить, что созданный ими продукт удовлетворяет выдвинутым функциональным требованиям и обладает достаточным уровнем адекватности. «Единые критерии» предлагают производителям специальный механизм, так называемый проект защиты, дополняющий профиль защиты и позволяющий соединить описания механизмов реализации средств защиты и требований, на которые ориентировался разработчик. Кроме того, производители могут использовать «Единые критерии» для определения своей ответственности, а также действий, необходимых для поддержки процесса квалификационного анализа и сертификации созданного ими продукта.
Эксперты по квалификации используют положения этого документа в качестве критериев для определения соответствия между ИТ-продуктом и предъявляемыми к нему требованиями. «Единые критерии» описывают только общую схему проведения квалификационного анализа и сертификации, но не регламентируют процедуру их осуществления. Вопросам методологии квалификационного анализа и сертификации посвящен отдельный документ тех же авторов — «Общая методология оценки безопасности информационных технологий» [20].
Таким образом, «Единые критерии» обеспечивают решение задач выбора и сертификации ИТ-продуктов и служат руководящим материалом для разработчиков информационных систем, обладающих функциями защиты, а также определяют шкалу оценки уровня безопасности, обеспечиваемого ИТ-продуктом.
«Единые критерии» рассматривают безопасность как совокупность конфиденциальности, целостности и доступности ресурсов ВС и ставят перед средствами защиты задачи противодействия соответствующим типам угроз и реализации политики безопасности, однако не ограничиваются этими традиционными целями и позволяют учитывать угрозы, которые не могут быть отнесены ни к одному из перечисленных выше типов.
2.10.2. Основные положения
«Единые критерии» регламентируют все стадии; разработки, квалификационного анализа и эксплуатации ИТ-продуктов, уже знакомых нам по «Федеральным критериям» (п. 2.8.2). «Единые критерии» предлагают достаточно сложную и бюрократичную концепцию процесса разработки и квалификационного анализа ИТ-продуктов, требующую от потребителей и производителей огромного количества бумажной работы по составлению и оформлению весьма объемных и подробных нормативных документов. Коротко рассмотрим основные положения и разделы этих документов, но сперва введем определения для некоторых базовых понятий «Единых критериев»:
Задачи защиты — базовое понятие «Единых критериев», выражающее потребность носителей ИТ-продукта в противостоянии заданному множеству угроз безопасности или в необходимости реализации политики безопасности.
Профиль защиты — специальный нормативный документ, представляющий собой совокупность Задач защиты, функциональных требований, требований адекватности и их обоснования. Служит руководством для разработчика ИТ-продукта при создании проекта защиты.
Проект защиты — специальный нормативный документ, представляющий собой совокупность задач защиты, функциональных требований, требований адекватности. общих спецификаций средств защиты и их обоснования. В ходе квалификационного анализа служит в качестве описания ИТ-продукта.
Согласно «Единым критериям», безопасность информационных технологий может быть достигнута посредством применения предложенной в них технологии разработки, сертификации и эксплуатации ИТ-продуктов. На рис. 2.11 представлена схема технологического цикла применения «Единых критериев».
Обозначение:
———————— à – информационные потоки
– – – – – – – – – – – – – -à – влияние по принципу обратной связи
Рис 2.11. Схема процесса разработки и кавлифакационного анализа ИТ-продукта с точки зрения “Единых критериев”
С точки зрения авторов «Единых критериев» наиболее существенным аспектом требований безопасности, на которые ориентируются разработчики при создании ИТ-продукта, является их соответствие нуждам его потребителей. Только при соблюдении этого условия будет достигнута поставленная цель — обеспечение безопасности информационных технологий. «Единые критерии» определяют .множество типовых требований, которые в совокупности с механизмом профилей защиты позволяют потребителям создавать Частные наборы требований, отвечающие их нуждам. Разработчики могут использовать профиль защиты как основу для создания спецификаций своих продуктов. Профиль защиты и спецификации средств защиты составляют проект защиты, который представляет ИТ-продукт в ходе квалификационного анализа.
Квалификационный анализ может осуществляться как параллельно с разработкой, так и следовать за ней. Для проведения квалификационного анализа должны быть получены следующие материалы:
· проект защиты, описывающий функции защиты ИТ-продукта и требования безопасности, соответствующие требованиям Профиля защиты, на реализацию которого претендует ИТ-продукт;
· доказательства возможностей ИТ-продукта. представленные его разработчиком:
· сам ИТ-продукт:
· дополнительные сведения, полученные путем проведения различных экспертиз.
Процесс квалификационного анализа включает три стадии:
1. Анализ профиля защиты на предмет его полноты, непротиворечивости, реализуемости и возможности использования в качестве набора требований для анализируемого продукта.
2. Анализ проекта защиты на предмет его соответствия требованиям профиля защиты, а также полноты, непротиворечивости, реализуемости и возможности использования в качестве описания ИТ-продукта.
3. Анализ ИТ-продукта на предмет соответствия проекту защиты.
Результатом квалификационного анализа является заключение о том, что проанализированный ИТ-продукт соответствует представленному проекту защиты. Заключение состоит из нескольких отчетов, отличающихся уровнем детализации и содержащих мнение экспертов по квалификации об ИТ-продукте на основании критериев квалификации — «Единых критериев». Эти отчеты могут использоваться как производителями, так и потребителями ИТ-продукта.
Применение квалификационного анализа сертификации приводит к повышению качества работы производителен в процессе проектирования и разработки ИТ-продуктов, а также к повышению безопасности их эксплуатации. Кроме того, в продуктах, прошедших квалификацию уровня безопасности, уменьшается вероятность появления ошибок и изъянов. Все это позволяет говорить о том, что «Единые критерии» оказывают положительное и конструктивное влияние на процесс формирование требований, разработку ИТ-продукта, сам ^продукт и его эксплуатацию.
Основными документами, описывающими все аспекты безопасности ИТ-продукта с точки зрения пользователей и разработчиков, являются соответственно профиль защиты и проект защиты. Рассмотрим структуру и содержание этих документов.
2.10.2.1. Профиль защиты
Профиль защиты определяет требования безопасности к определенной категории ИТ-продуктов, не уточняя методы и средства их реализации. С помощью профилей защиты потребители формулируют свои требования к производителям.
Структура профиля защиты «Единых критериев» существенно отличается от документа с тем же названием, обсуждавшегося в разделе, посвященном «Федеральным критериям» (п. 2.8.3), и показана на рис. 2.12.
Рассмотрим назначение и содержание разделов профиля защиты.
Введение содержит всю информацию, необходимую для поиска профиля защиты в библиотеке профилей.
Идентификатор профиля защиты представляет собой уникальное имя, пригодное для его поиска среди подобных ему профилей и обозначения ссылок на него.
Обзор содержания содержит краткую аннотацию профиля защиты, на основании которой потребитель может сделать вывод о пригодности данного профиля для его нужд.
Описание ИТ-продукта должно содержать его краткую характеристику, функциональное назначение, принципы работы, методы использования и т. д. Эта информация не подлежит анализу и сертификации, но предоставляется производителям и экспертам по квалификации для пояснения требований безопасности и определения их соответствия задачам, решаемым с помощью ИТ-продукта, а также для общего понимания его структуры и принципов работы.
Среда эксплуатации. Этот раздел содержит описание всех аспектов функционирования ИТ-продукта, связанных с безопасностью.
Угрозы безопасности. Описание угроз безопасности, присущих среде эксплуатации ИТ-продукта, которым должна противостоять защита. Для каждой угрозы должен быть указан ее источник, а также метод воздействия и его объект.
Политика безопасности. Описание политики безопасности должно определять и, при необходимости, объяснять правила политики безопасности, которая должна быть реализована в ИТ-продукте.
Условия эксплуатации. Описание условий эксплуатации ИТ-продукта должно содержать исчерпывающую характеристику среды его эксплуатации с точки зрения безопасности.
Задачи защиты отражают потребности пользователей в противодействии указанным угрозам безопасности и/или в реализации политики безопасности.
Задачи защиты ИТ-продукта должны быть четко определены и отражать потребности в противодействии угрозам безопасности и/или в реализации политики безопасности.
Другие задачи защиты отражают потребности в противодействии угрозам безопасности и/или в реализации политики безопасности других (не относящихся к сфере информационных технологий) компонентов ВС.
Требования безопасности. В этом разделе профиля защиты содержатся требования безопасности, которым должен удовлетворять ИТ-продукт для решения задач защиты.
Рис. 2.12. Структура профиля защиты «Единых критериев».
Раздел функциональных требовании должен содержать только типовые требования, предусмотренные соответствующими разделами «Единых критериев». Необходимо обеспечить такой уровень детализации требований, который позволяет продемонстрировать их соответствие задачам защиты. Функциональные требования могут предписывать или запрещать использование конкретных методов и средств защиты.
Раздел требований адекватности также состоит из типовых требований соответствующих разделов «Единых критериев».
Раздел требовании к среде эксплуатации является необязательным и может содержать функциональные требования и требования адекватности, которым должна удовлетворять среда эксплуатации ИТ-продукта. В отличие от предыдущих разделов использование типовых требований «Единых критериев» является желательным, но не обязательным.
Дополнительные сведения — необязательный раздел, содержащий любую дополнительную информацию, которая может быть полезна для проектирования, разработки, квалификационного анализа и сертификации ИТ-продукта.
Обоснование должно демонстрировать, что профиль защиты содержит полное ч связное множество требований, и что удовлетворяющий им ИТ-продукт будет эффективно противостоять угрозам безопасности среды эксплуатации.
Обоснование задач защиты должно демонстрировать, что задачи защиты, предложенные в профиле, соответствуют свойствам среды эксплуатации, так как их решение позволит эффективно противостоять угрозам безопасности и реализовать политику безопасности.
Обоснование требовании безопасности показывает, что требования безопасности позволяют решить задачи защиты, так как:
· совокупность целей, преследуемых отдельными функциональными требованиями, соответствует установленным задачам защиты;
· требования безопасности являются согласованными, т. е. не противоречат друг другу, а, напротив, взаимно усиливаются;
· все взаимосвязи между требованиями учтены либо посредством их указания в требованиях, либо| посредством установления требований к среде эксплуатации;
· выбранный набор требований и уровень адекватности могут быть обоснованы.
Профиль защиты служит отправной точкой для производителя, ИТ-продукта, который должен на основании этого материала и предложенных им технических решений разработать проект защиты, который будет представлять ИТ-продукт в ходе квалификационного анализа.
2.10.2.2. Проект защиты
Проект защиты содержит требования и задачи защиты ИТ-продукта, а также описывает уровень функциональных возможностей реализованных в нем средств защиты, их обоснование и подтверждение степени их адекватности. Проект защиты представляет собой основу Для совместной работы производителей и экспертов по квалификации. Структура проекта представлена на рис. 2.13.
Многие разделы проекта защиты совпадают с одноименными разделами профиля защиты, поэтому рассмотрим только те разделы, которые специфичны для проекта защиты, а также те, которые претерпели изменения.
Введение содержит информацию, необходимую для идентификации проекта защиты, определения назначения, а также обзор его содержания.
Идентификатор представляет собой уникальное имя проекта защиты, необходимое для поиска и идентификации проекта защиты и соответствующею ему ИТ-продукта.
Обзор содержании представляют собой достаточно подробную аннотацию проекта защиты, позволяющую потенциальным потребителям определить пригодность ИТ-продукта для решения их задач.
Заявка на соответствие «Единым критериям» содержит описание всех свойств ИТ-продукта, подлежащих квалификационному анализу на основе «Единых критериев».
Раздел Требований безопасности проекта защиты содержит требования безопасности к ИТ-продукту, которыми руководствовался производитель в ходе его разработки, что позволяет ему заявлять об успешном решении поставленных задач защиты. Этот раздел несколько отличается от аналогичного раздела профиля защиты.
Раздел функциональных требований к ИТ-продукту в отличие от соответствующего раздела профиля защиты допускает использование кроме типовых требований «Единых критериев» других, специфичных для данного продукта и среды его эксплуатации. При описании специфичных требований необходимо сохранять стиль и подробность, присущие требованиям «Единых критериев».
Раздел требований адекватности по сравнению с соответствующим разделом профиля защиты может включать уровни адекватности, не предусмотренные в «Единых критериях». В этом случае описание уровня адекватности должно быть четким, непротиворечивым и обладать степенью подробности, допускающей его использование в ходе квалификационного анализа. При этом желательно использовать стиль и подробность описания уровней адекватности, принятые в «Единых критериях».
Рис. 2.13. Структура проекта зашиты согласно «Единым критериям».
Общие спецификации ИТ-продукта отражают реализацию ИТ-продуктом требований безопасности с помощью определения высокоуровневых спецификаций функций защиты, реализующих функциональные требования и требования адекватности.
Спецификации функций защиты описывают функциональные возможности средств защиты ИТ-продукта, заявленные его производителем как реализующие требования безопасности. Форма представления спецификаций должна позволять определять соответствия между функциями защиты и требованиями безопасности.
Спецификации уровня адекватности определяют заявленный уровень адекватности защиты ИТ-продукта и его соответствие требованиям адекватности в виде представления параметров технологии проектирования и создания ИТ-продукта. Эти параметры должны быть представлены в форме, позволяющей определить их соответствие требованиям адекватности.
Заявка на соответствие профилю защиты. Проект защиты претендует на удовлетворение требований одного или нескольких профилей защиты. Этот необязательный раздел содержит материалы, необходимые для подтверждения заявки. Для каждого профиля защиты, на реализацию которого претендует проект защиты, этот раздел должен содержать следующую информацию:
Ссылка на профиль защиты однозначно идентифицирует профиль защиты, на реализацию которого претендует проект безопасности, с указанием случаев, в которых обеспечиваемый уровень защиты превосходит требования профиля. Корректная реализация профиля защиты подразумевает корректную реализацию всех его требований без исключения.
Соответствие профилю защиты определяет возможности ИТ-продукта, которые реализуют задачи защиты и требования, содержащиеся в профиле защиты.
Усовершенствования профиля защиты отражают возможности ИТ-продукта, которые выходят за рамки задач защиты и требований, установленных в профиле защиты.
Oбoснование должно показывать, что проект защиты содержит полное и связное множество требований, что реализующий его ИТ-продукт будет эффективно противостоять угрозам безопасности среды эксплуатации и что общие спецификации функций защиты соответствуют требованиям безопасности. Кроме того, обоснование содержит подтверждения заявленного соответствия профилю защиты. Обоснование проекта защиты включает следующие разделы:
Обоснование задач защиты должно демонстрировать, что задачи защиты, предложенные в проекте защиты, соответствуют свойствам среды эксплуатации, т.е. их решение позволит эффективно противодействовать угрозам безопасности и реализовать политику безопасности.
Обоснование требований безопасности показывает, что требования безопасности позволяют решить задачи защиты, так как:
· функциональные требования безопасности соответствуют задачам защиты;
· требования адекватности соответствуют функциональным требованиям и усиливают их;
· совокупность всех функциональных требований (как стандартных, предусмотренных «Едиными критериями», так и специфических) обеспечивает решение задач защиты;
· все взаимосвязи между требованиями «Единых критериев» учтены либо посредством их указания в требованиях, либо посредством предъявления соответствующих требований к среде эксплуатации;
· все требования безопасности успешно реализованы;
· заявленный уровень адекватности может быть подтвержден.
Обоснование функций защиты должно демонстрировать их соответствие функциональным требованиям безопасности и задачам защиты. Для этого должно быть показано, что:
· указанные функции защиты соответствуют заявленным задачам защиты;
· совокупность указанных функций защиты обеспечивает эффективное решение совокупности задач защиты;
· заявленные возможности функций защиты соответствует действительности.
Обоснование уровня адекватности подтверждает, что заявленный уровень безопасности соответствует требованиям адекватности.
Обоснование соответствия профилю защиты показывает, что требования проекта защиты поддерживают все требования профиля защиты. Для этого должно быть показано, что:
· все усовершенствования задач защиты по сравнению с профилем защиты осуществлены корректно и в направлении их развития и конкретизации;
· все усовершенствования требований безопасности по сравнению с профилем защиты осуществлены корректно и в направлении их развития и конкретизации;
· все задачи защиты профиля защиты успешно решены и все требования профиля защиты удовлетворены;
· никакие дополнительно введенные в проект защиты специальные задачи защиты и требования безопасности не противоречат профилю защиты.
Как видно из приведенных структуры и обзора содержания профиля защиты и проекта защиты, эти документы практически исчерпывающим образом регламентируют взаимодействие потребителей, производителей и экспертов по квалификации в процессе создания ИТ-продукта. Фактически, положения этих документов определяют технологию разработки защищенных систем.
Самым важным элементом этой технологии являются требования безопасности. Поскольку «Единые критерии» обобщают все предшествующие достижения в этой области, рассмотрим их более подробно.
2.10.3. Требования безопасности
«Единые критерии разделяют требования безопасности на две категории: функциональные требования и требования адекватности.
Функциональные требования регламентируют функционирование обеспечивающих безопасность компонентов ИТ-продукта и определяют возможности средств защиты.
Адекватность представляет собой характеристику ИТ-продукта, которая отражает насколько эффективно обеспечивается заявленный уровень безопасности, а также степень корректности реализации средств защиты. Адекватность опирается на информацию о процессах проектирования, создания и эксплуатации ИТ-продукта. Требования адекватности регламентируют технологию и процесс создания ИТ-продукта, а также необходимость проведения анализа слабых мест защиты.
2.10.3.1 Функциональные требования.
Как и все остальные положения «Единых критериев», функциональные требования представлены в виде хорошо проработанной формальной структуры. Набор функциональных требований обобщает все существующие стандарты информационной безопасности и впечатляет своей всеобъемлющей полнотой и подробнейшей детализацией.
Функциональные требования разбиты на классы, которые, в свою очередь состоят из разделов. Структура функциональных требований приведена на рис. 2.14.
Рассмотрим назначение некоторых элементов структуры описания функциональных требований, необходимых для проведения их анализа:
Название и назначение раздела. Каждый раздел имеет свое уникальное название и шестибуквенный идентификатор. состоящий из префикса трехбуквенного идентификатора класса и трехбуквенного обозначения раздела. Используется для осуществления ссылок на раздел.
Ранжирование требований. «Единые критерии» развивают впервые предложенный в «Федеральных критериях» подход, связанный с отказом от единой шкалы ранжирования функциональных требований и введением множества частных шкал. Специфика «Единых критериев» состоит в том, что шкалы, по которым ранжируются требования, являются лишь частично упорядоченными. Это нововведение требует подробного рассмотрения, так как открывает новые возможности для пользователей и разработчиков при составлении набора требований профиля защиты и проекта защиты.
Согласно «Единым критериям», набор ранжированных требований представляет собой иерархическую структуру, а не является упорядоченным списком, в котором усиление требований происходит монотонно от низших уровней к высшим. Эта структура имеет вид направленного графа. Усиление требований происходит при движении по его ребрам. Таким образом, могут существовать несравнимые требования.
Рис. 2.14. Структура функциональных требований «Единых критериев».
Рис. 2.15. Пример иерархического ранжирования функциональных требований «Единых критериев»
Строго говоря, данный граф канонически индуцирует отношение частичного порядка на множестве требований. В качестве примера рассмотрим ранжирование требований защиты при передаче информации по внутренним каналам и уничтожения остаточной информации (рис. 2.15).
В данном примере реализация требований защиты информации при передаче по внутренним каналам может осуществляться в двух направлениях — обеспечение безопасности и мониторинг целостности информации. Для каждого направления существует две степени реализации требований, в зависимости от того, учитываются атрибуты безопасности передаваемой информации или нет. Требования, находящиеся на разных ветвях, —требования защиты и мониторинга — являются несравнимыми.
Иерархия требований уничтожения остаточной информации представляет собой более сложную структуру. Минимальный уровень соответствия этому требованию обеспечивается посредством уничтожения остаточной информации при создании определенных объектов. Далее, существуют два направления усиления этого требования – расширение области применения механизма уничтожения остаточной информации при создании объектов до полного множества объектов или осуществление уничтожения остаточной информации при удалении определенного подмножества объектов. Эти два требования находятся на разных ветвях иерархии и несопоставимы между собой. Самым радикальным методом решения проблемы уничтожения остаточной информации является ее уничтожение при удалении любого объекта в системе. Эта степень реализации требования представлена вершиной, в которой соединяются обе ветви, что означает превосходство данного метода как над уничтожением остаточной информации при создании любых объектов, так и над уничтожением остаточной информации при удалении определенного подмножества объектов.
Описание каждого требования строится по следующей схеме:
1. Название. Уникальное название требования, которое используется для ссылок на него из профиля и проекта защиты.
2. Содержание. Функциональный состав требования. «Единые критерии» разрешают использовать требования только целиком, что обеспечивает их стандартизацию.
3. Сопряженные требования. Необязательный пункт, содержащий список требований различных разделов и классов, выполнение которых рассматривается как необходимое предварительное условие для реализации данного требования.
Таксономия классов функциональных требований «Единых критериев» показана на рис. 2.16.
Рис. 2.16. Таксономия классов функциональных требовании «Единых критериев».
Набор классов функциональных требований «Единых критериев» отличается, других стандартов, во-первых, своей всеобъемлющей полнотой (76 требований), а, во-вторых, многоуровневым подходом к обеспечению безопасности. Впервые отдельные классы требований направлены на обеспечение безопасности самих средств защиты, контроль за эксплуатацией системы, обеспечение конфиденциальности сеансов доступа к системе и организацию обмена информацией. Таксономия функциональных требований для всех классов «Единых критериев» показана на рис. 2.17, 2.18 и 2.19.
Рис. 2.17. Таксономия функциональных требований классов защита информации и безопасность защиты «Единых критериев».
Рис. 2.18 Таксономия функциональных требований классов идентификации и аутентификации.
Рис. 2.19. Таксономия функциональных требований классов контроль за использованием ресурсов, обеспечение прямого взаимодействия, контроль доступа к системе, конфиденциальность доступа к системе и информационный обмен «Единых критериев».
Требования конфиденциальности, целостности и управления доступом объединены в один класс «защита информации», что выглядит вполне логичные и полностью соответствует их назначению. Следует отметить наличие, помимо политики управления доступом, дополняющей ее политики управления информационными потоками, а также отделение требований к политике безопасности от требований к средствам ее реализации.
Класс требований к безопасности самих средств защиты является самым объемным, что определяется высокой степенью детализации включенных в него требований к методам и средствам обеспечения нормального функционирования средств защиты.
Особое внимание уделяется контролю за доступом к системе и конфиденциальности сеансов работы с ней. Требования к организации информационного обмена ограничиваются невозможностью участников взаимодействия уклониться от ответственности.
Ранжирование функциональных требований представлено в Приложении III.
2.10.3.2. Требования адекватности
Как и функциональные требования, требования адекватности жестко структурированы и регламентируют все этапы проектирования, создания и эксплуатации ИТ-продукта очень детально и подробно.
Структура требований адекватности по своей форме очень похожа на структуру функциональных требований и включает в себя те же разделы. Таксономия требований адекватности представлена на рис. 2.20.
Ранжирование требований адекватности представлено в виде упорядоченных списков (Приложение III). Критерии адекватности используются в ходе квалификационного анализа ИТ-продукта для определения степени корректности реализации функциональных требований и назначения ИТ-продукту соответствующею уровня адекватности. Для этого «Единые критерии» предлагают семь стандартных уровней адекватности, каждый из которых определят степень соответствия ИТ-продукта каждому требованию адекватности (адекватность возрастает от первого уровня к седьмому). Названия уровней отражают возможности средств контроля и верификации, применяющихся в ходе разработки и анализа ИТ-продукта.
Уровень 1 Применение функциональною тестирования.
Уровень 2. Применение структурного тестирования.
Уровень 3. Применение методик тестирования и контроля
Уровень 4. Применение методик разработки, тестирования и анализа.
Уровень 5. Применение полуформальных методов разработки и тестирования
Уровень б. Применение полуформальных методов верификации в процессе разработки и тестирования.
Уровень 7. Применение формальных методов верификации в процессе разработки и тестирования.
Приложение III содержит таблицу, показывающую распределение требований адекватности по уровням.
Требования «Единых критериев» охватывают практически все аспекты безопасности ИТ-продуктов и служат весьма полезным исходным материалом для потребителей и разработчиков при формировании профилей и проектов защиты. Кроме того, «Единые критерии» являются всеобъемлющей энциклопедией информационной безопасности.
Рис. 2.20 Таксономия адекватности «Единых критериев».
2.10.4. Выводы
«Единые критерии безопасности информационных технологий» представляют собой результат обобщения всех достижений в области информационной безопасности. Впервые документ такого уровня содержит разделы, адресованные потребителям, производителям и экспертам по квалификации ИТ-продуктов.
Предложенные «Едиными критериями» механизмы профиля защиты и проекта защиты позволяю г потребителям и производителям в полной мере выразить свой взгляд на требования безопасности и задачи защиты, а с другой стороны дают возможность экспертам по квалификации проанализировать взаимное соответствие между требованиями, нуждами потребителей, задачами защиты и средствами защиты ИТ-продукта. В отличие от профиля защиты «Федеральных критериев», который ориентирован исключительно на среду применения ИТ-продукта, профиль защиты «Единых критериев» предназначен непосредственно для удовлетворения нужд потребителей.
Разработчики «Единых критериев» продолжили подход «Федеральных критериев», направленный на отказ от единой шкалы безопасности, и усилили гибкость этого решения путем введения частично упорядоченных шкал, благодаря чему потребители и производители получили дополнительные возможности по приспособлению требований к свои нуждам.
Этот документ ознаменовал собой новый уровень стандартизации информационных технологий, подняв его на межгосударственный уровень. За этим проглядывается перспектива создания единого информационного пространства, в котором сертификация безопасности систем обработки информации будет осуществляться на глобальном уровне, что предоставит возможности для интеграции национальных информационных систем, что в свою очередь откроет совершенно новые сферы применения информационных технологий. Остается только посетовать, что наша страна, как всегда, осталась в стороне этого процесса.
2.11. Анализ стандартов информационной безопасности
Как уже говорилось, главная задача стандартов информационной безопасности — согласовать позиции и запросы производителей, потребителей и аналитиков-классификаторов продуктов информационных технологий. Каждая из категорий специалистов оценивает стандарты и содержащиеся в них требования и критерии по своим собственным параметрам. Для потребителей наиболее значительную роль играет простота критериев и однозначность параметров выбора защищенной системы, а для наиболее квалифицированной части пользователей — гибкость требований и возможность их применения к специфическим ИТ-продуктам и средам эксплуатации. Производители требуют от стандартов максимальной конкретности и совместимости требований и критериев с современными архитектурами ВС и с распространенными ОС. Эксперты по квалификации мечтают о стандартах, детально регламентирующих процедуру квалификационного анализа, и о четких, простых, однозначных и легко применяемых критериях. Очевидно, что подобный идеал недостижим, и реальность требует от каждой стороны определенных компромиссов. Поэтому не будем проводить субъективный анализ стандартов с точки зрения каждого из участников процесса создания защищенных систем, а попытаемся ввести общие для всех «объективные» критерии сопоставления.
В качестве обобщенных показателей, характеризующих стандарты информационной безопасности и имеющих значение для всех трех групп, можно назвать универсальность, гибкость, гарантированность, реализуемость и актуальность.
Универсальность стандарта определяется множеством типов ВС и областей их применения, к которым могут быть корректно применены его положения. Эго очень важная характеристика стандарта, так как информационные технолог ни переживают период бурного развития, архитектура компьютерных систем постоянно совершенствуется, а сфера их применения постоянно расширяется. Стандарты информационной безопасности в своем развитии не должны отставать от информационных технологий, что может быть обеспечено только гибкостью предлагаемых ими требований и критериев.
Под гибкостью стандарта понимается возможность и удобство его применения к постоянно развивающимся информационным технологиям, а также время, в течение которого он сохраняет свою актуальность. Гибкость может быть достигнута исключительно через фундаментальность требований и критериев и их инвариантность по отношению к механизмам реализации и технологиям создания ИТ-продуктов. Однако очевидно, что чрезмерная абстрактность требований и оторванность их от практики снижает их реализуемость.
Гарантированность определяется мощностью предусмотренных стандартом методов и средств подтверждения надежности результатов квалификационного анализа. Вначале этому вопросу не уделялось много внимания, но анализ опыта применения первых стандартов информационной безопасное ги показал, что для достижения поставленных целей аналитики-классификаторы должны иметь возможность обосновывать свои заключения, а разработчики нуждаются в механизмах, с помощью которых они могли бы подтвердить корректность своих притязаний и предоставить потребителям определенные гарантии.
Реализуемость — это возможность адекватной реализации требований и критериев стандарта на практике, | с учетом за грат на этот процесс. Реализуемость во многом связана с универсальностью и гибкостью, но отражает чисто практические и технологические аспекты реализации положений стандарта.
Актуальность отражает соответствие требований и критериев стандарта постоянно развивающемуся множеству угроз безопасности и новейшим методам и средствам, используемым злоумышленниками. Эта характеристика, наряду с универсальностью, является одной из важнейших, так как способность противостоять угрозам и прогнозировать их развитие фактически определяет пригодность стандарта и является решающим фактором при определении его пригодности.
Таблица 2. 5. Сопоставление стандартов информационном безопасности
Стандарты безопасности
Показатели сопоставления стандартов информационной безопасности
Универсальность
Гибкость
Гарантирован-ность
Реализуемость
Актуальность
«Оранжевая книга» (1983г.)
Ограниченная
Ограниченная
Ограниченная
Высокая
(за исключением класса А)
Умеренная
«Европейские критерии» (1996г.)
Умеренная
Умеренная
Умеренная
Высокая
Умереннач
Документы ГТК (1992г.)
Ограннченная
Ограниченная
Огсутствует
Высокая
ограниченная
«Федеральные критерии» (1992г.)
Высокая
Отличная
Достаточная
Высокая
Высокая
«Канадские критерии» (1993г.)
Умеренная
Достаточная
достаточная
Достаточная
Средняя
«Единые кригерии» (1996г.)
Превосходная
превосходная
превосходная
Превосходная
превосходная
Классификация рассмотренных стандартов информационной безопасности по предложенным показателям приведена в таблице 2.5.
Степень соответствия стандартов предложенным показателям определяется по следующей качественной шкале:
· ограниченная — недостаточное соответствие, при применении стандарта возникают существенные трудности;
· умеренная — соответствие в минимальной степени, при применении стандарта в большинстве случаев существенных трудностей не возникает;
· достаточная — удовлетворительное соответствие, при применении стандарта в большинстве случаев не возникает никаких трудностей, однако эффективность предлагаемых решений не гарантируется;
· высокая — стандарт предлагает специальные механизмы и процедуры, направленные на улучшение данного показателя, применение которых позволяет получать достаточно эффективные решения;
· превосходная — улучшение данного показателя рассматривалось авторами стандарта в качестве одной из основных целей его разработки, что обеспечивает эффективность применения предложенных решений.
Рассмотрим, в какой степени стандарты информационной безопасности отвечают предложенным показателям, и проследим направления, по которым шло их развитие.
2.11.1. Универсальность
На этапе начального становления и развития стандартов информационной безопасности универсальности уделялось мало внимания, так как, во-первых, разработчикам стандартов казалось, что в обеспечении безопасности нуждается только ограниченный круг потребителей, находящихся в правительственных и военных сферах, а во-вторых, темпы информатизации тогда были относительно невелики. Поэтому первый стандарт безопасности — «Оранжевая книга» — предназначался для систем военного применения, основанных в те годы исключительно на мэйнфреймах, и его адаптация для распределенных систем и баз данных потребовала разработки дополнительных документов. С учетом этого опыта сфера применения вышедших несколькими годами позже «Европейских критериев» значительно расширена — уже на уровне базового документа в этот стандарт вошли распределенные системы, сети, системы телекоммуникаций и СУБД. Однако в этом документе по-прежнему явным образом оговаривается архитектора и назначение систем, к которым он может быть применен, и никак не регламентируется среда их эксплуатации. Документы Гостехкомиссии России имеют довольно ограниченную сферу применения — это персональные (видимо, это объясняется тотальным распространением PC в нашей стране) и многопользовательские системы, причем ориентация системы на обслуживание конечных пользователей является обязательным условием. «Федеральные критерии» подняли область применения стандартов на новый уровень, начав рассматривать в качестве объекта их применения любые продукты информационных технологий, независимо от их назначения, проводя различие только между характеристиками среды их эксплуатации. «Канадские критерии» рассматривают в качестве области своего применения все типы компьютерных систем. Наконец, «Единые критерии» увенчали процесс расширения сферы применения стандартов информационной безопасности, провозгласив себя неотъемлемым компонентом информационных технологий.
2.11.2. Гибкость
Гибкость положений стандарта определяет удобство ею использования потребителями и производителями систем обработки информации. Возможно, именно поэтому требования первого стандарта («Оранжевой книги») были достаточно гибкими, но чересчур абстрактными для непосредственного применения во многих случаях, что потребовало их комментирования, дополнения и расширения. «Европейские критерии» унаследовали этот стиль изложения требований и пошли по пути экстенсивного развития, предусмотрев специальные уровни и требования, рассчитанные на типовые системы (СУБД, телекоммуникации и т. д.). Руководящие документы ГТК по конкретности своих требований превзошли даже уровень «Оранжевой книги», так как подробно регламентируют реализацию функций защиты (например, это единственный стандарт, который в ультимативной форме требует применения криптографии), что значительно снижает удобство их использования, в конкретных ситуациях многие требования часто оказываются избыточными и ненужными. Более того, ограничение области применения данного стандарта классом систем, ориентированных на конечного пользователя, ставит отечественных разработчиков и экспертов по сертификации в затруднительное положение при применении эти документов, скажем, к программному обеспечению маршрутизатора или файэр-вола (у этих систем в принципе нет пользователей, являющихся физическими лицами). «Федеральные критерии» обеспечивают гибкость на качественно новом по сравнению с предшествующими стандартами уровне, впервые предложив механизм профилей защиты, с помощью которых можно создавать специальные наборы требований, соответствующие запросам потребителей конкретного продукта и угрозам среды его эксплуатации. «Канадские критерии» не рассматривают профиль защиты в качестве обязательного элемента безопасности информационных технологий, а также обладают определенной спецификой в своем подходе к основным понятиям безопасности, поэтому их гибкость можно оценить только как достаточную. Наконец, «Единые критерии» обладают практически совершенной гибкостью, так как позволяют потребителям выразить свои требования с помощью механизма профилей защиты, в форме инвариантной к механизмам реализации, а производителям — продемонстрировать с помощью проекта защиты, как эти требования преобразуются в задачи защиты и реализуются на практике. В этом случае процесс квалификации уровня безопасности ИТ-продукта представляет собой проверку взаимного соответствия профиля защиты, проекта защиты и реализованного ИТ-продукта, а также их соответствия «Единым критериям».
2.11.3. Гарантированность
Гарантированность обеспечиваемого уровня защиты сначала рассматривалась разработчиками стандартов только для высших уровней безопасности. Поэтому «Оранжевая книга» предусматривала обязательное применение формальных методов верификации только при создании систем высшего класса защищенности (класс А). Однако необходимость контроля корректности реализации и подтверждения эффективности средств защиты для систем всех уровней была осознана достаточно быстро. Уже в «Европейских критериях» появляется специальный раздел требований — требования адекватности, которые регламентируют технологию и среду разработки, а также контроль за этим процессом. К сожалению, документы ГТК практически полностью проигнорировали этот, на наш взгляд ключевой аспект безопасности информационных технологии и обошли данный вопрос молчанием. «Федеральные критерии» содержат два специальных раздела требований, посвященных решению этой проблемы: требования к технологии разработки и к процессу квалификационного анализа. «Канадские критерии» включают раздел требований адекватности, количественно и качественно ни в чем не уступающий разделу функциональных требований. «Единые критерии» обеспечивают адекватность задач защиты требованиям потребителей, проекта защиты «Единым критериям» и ИТ-продукта проекту защиты с помощью многоэтапного контроля.
2.11.4. Реализуемость
Плохие показатели реализуемости говорят о практической бесполезности стандарта, поэтому все рассмотренные документы отвечают этому показателю в достаточной или высокой степени. Реализация требований «Оранжевой книги», за исключением высшего класса (класса А), большой сложности не представляет. Это подтверждается большим числом систем, сертифицированных на соответствие классам В и С (около 30 систем). Авторам известна только две системы, сертифицированные на соответствие классу А, причем политика безопасности в одной из них реализована на аппаратном уровне с помощью контроля операндов каждой инструкции, т. е. разработчикам пришлось спроектировать и реализовать специальный процессор.
Остальные стандарты решали эту проблему за счет гибкости предлагаемых требований и критериев. О «Канадских критериях» стоит упомянуть особо — своим нетрадиционным толкованием понятий «объект» и «субъект» они осложняют разработчикам процесс реализации предложенных в них требований, что определяет уровень их соответствия данному показателю только как достаточный. «Единые критерии» и здесь оказались на практически недосягаемой для остальных стандартов высоте за счет потрясающей степени подробности функциональных требований (76 требований), фактически служащих исчерпывающем руководством для разработки средств защиты. Отметим, что это единственный показатель, по которому документы ГТК не отстают от остальных стандартов информационной безопасности.
2.11.5. Актуальность
Актуальность стандартов информационной безопасности возрастала с расширением сферы их применения и появлением опыта их использования. «Оранжевая книга», хотя и содержит предпосылки для противодействия всем основным видам угроз, содержит требования в основном направленные на противодействие угрозам конфиденциальности, что объясняется ее ориентированностью на системы военного назначения. «Европейские критерии» находятся примерно на том же уровне, хотя и уделяют угрозам целостности гораздо больше внимания. Документы ГТК с точки зрения этого показателя выглядят наиболее отсталыми — уже в самом их названии определена единственная рассматриваемая в них угроза — несанкционированный доступ. «Федеральные критерии» рассматривают все виды угроз достаточно подробно и предлагают механизм профилей защиты для описания угроз безопасности, присущих среде эксплуатации конкретного ИТ-продукта, что позволяет учитывать специфичные виды угроз. «Канадские критерии» ограничиваются типовым набором угроз безопасности. «Единые критерии» ставят во главу угла удовлетворение нужд пользователей и предлагают для этого соответствующие механизмы, что позволяет говорить о качественно новом подходе к проблеме безопасности информационных технологий.
В качестве основных тенденций развития стандартов информационной безопасности можно указан»:
1. Развитие стандартов позволяет проследить движение от единой шкалы ранжирования требований и критериев к множеству независимых частных показателей и введению частично упорядоченных шкал.
2. Неуклонное возрастание роли требований адекватности к реализации средств защиты и политики безопасности свидетельствует о преобладании «качества» обеспечения защиты над ее «количеством».
3. Определение ролей производителей, потребителей и экспертов по квалификации ИТ-продуктов и разделение их функций говорит о зрелости стандартов обеспечения безопасности информационных технологий.
4. Разделение ролей участников процесса создания и эксплуатации защищенных систем, применение соответствующих механизмов и технологий приводит к разумному распределению ответственности между всеми участниками этого процесса.
5. Интернационализация стандартов отражает современные тенденции к объединению и стремление к созданию безопасного всемирного информационного пространства.
2.12. Заключение
Итак, мы рассмотрели стандарты информационной безопасности, начиная от самых первых и заканчивая самым современным, вобравшим в себя весь опыт применения предшествующих ему документов. Что это дает для решения поставленной задачи — построения защищенной системы, кроме изучения накопившегося за четырнадцать лет опыта обеспечения безопасности?
Во-первых, мы прояснили задачи, которые должны быть решены в ходе создания защищенной системы (задачи защиты): эффективное противостояние угрозам безопасноести, действующим в среде ее эксплуатации, и корректная реализация пол тики безопасности.
Во-вторых, определился набор функциональных возможностей, которые должны (или могут) быть реализованы в защищенной системе. Он представлен в виде таксономии функциональных требований или критериев, приведенной для каждого стандарта.
В-третьих, впервые в отечественной литературе представлены наиболее существенные элементы современных технологий создания защищенных систем — механизмы профиля защиты и проекта защиты.
Представленный материал позволяет сформулировать задачи каждого из участников процесса создания защищенных систем (потребители, производители, эксперты по квалификации), которые должны быть решены для достижения поставленной цели. Наряду с исследованием причин нарушений безопасности (глава 3) и методикой корректной реализации моделей безопасности (глава 4, II тома), рассмотренный материал служит основой для технологии создания защищенных систем, которая будет представлена в пятой главе II тома.
Литература к главе 2
1. Гостехкомиссия России. Руководящий документ. Концепция защиты средств вычислительной техники от несанкционированного доступа к информации. Москва, 1992 г.
2. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. Москва, 1992 г.
3. Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Москва, 1992г.
4. Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от несанкционированного доступа в автоматизированных системах и средствах вычислительной техники. Москва, 1992 г.
5. Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. Москва, 1992 г.
6. Галатенко В. А. Информационная безопасность. «Открытые системы», NN4-6 1995г.
7. Trusted Computer System Evaluation Criteria. US Department of Defense 5200.28-STD, 1993.
8. Trusted Network Interpretation. National Computer Security Center. NCSC-TG-005 Version 1. July 1987.
9. Trusted Database Management System Interpretation. National Com puter 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. 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 I 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-001-95, January 1995.
16. Information Technology Security Evaluation Criteria. Harmonized Criteria of France-Germany-Netherlands-United Kingdom. – Department of Trade and Industry, London, 1991.
17. Federal Criteria for Information Technology Security. National Institute of Standards and Technology & National Security Agency. Version 1,0 December 1992.
18. Canadian Trusted Computer Product Evaluation Criteria. Canadian System Security Centre Communication Security Establishment, Government of Canada. Version З.Ое. January 1993.
19. Common Criteria for Information Technology Security Evaluation, rational Institute of Standards and Technology & National Security Agency (USA), Communication Security Establishment (Canada), UK IT Security and Certification Scheme (United Kingdom), Bundesamt fur Sichereit in der Informationstechnik (Germany), Service Central de la Securite des Systemes (France), National Communications Security Agency (Netherlands). Version 1.031.01.96.
20. Common Evaluation Methodology for Information Technology Security. National Institute of Standards and Technology & National Security Agency (USA), Communication Security Establishment (Canada), UK IT Security and Certification Scheme (United Kingdom), Bundesamt fur Sichereit in der Informationstechnik (Germany), Service Central de la Securite des Systemes (France), National Communications Security Agency (Netherlands). Version 0.6.11.01.97.
Глава 3
Исследование причин нарушений безопасности ВС
Sublata causa, tollitur morbus.
Устраните причину, тогда исчезнет и болезнь.
Гиппократ
В данной главе продолжается исследование понятия защищенной системы обработки информации, но в отличие от предыдущей главы, рассматривающей проблему с точки зрения норм и стандартов, безопасность ВС анализируется с практической точки зрения. Таким образом, если стандарты информационной безопасности (наравне с «моделями безопасности, см. главу 4 II тома) представляют собой попытку решить проблему сверху, то исследования нарушений безопасности и обусловливающих их причин являются прагматическим подходом к проблеме (как бы взглядом снизу), основанным на очевидной предпосылке: чтобы предотвратить появление нарушений безопасности, надо устранить их причину. Задача данной главы — выявить обстоятельства, которые приводят к успешной реализации угроз безопасности, и определить первопричины их появления.
3.1. Нарушения безопасности ВС и изъяны защиты
Знание истории нарушений безопасности вычислительных систем и понимание причин, по которым| они произошли, является одним из необходимых условий создания защищенных систем. Перспективным направлением исследований в этой области является анализ успешно осуществленных угроз безопасности (атак) с целью обобщения, классификации и выявления причин и закономерностей их появления и существования. Проведение такого анализа позволяет при разработке и создании защищенных систем сконцентрировать основные усилия именно на устранении этих причин путей исправления в механизмах защиты выявленных недостатков, что дает возможность эффективно противостоять угрозам безопасности. Очевидно, что основой данного подхода является глубокое исследование частных случаев нарушения безопасности и слабых сторон систем защиты, сделавших возможным осуществление угроз. Для этого необходимо провести анализ существующих Данных о нарушении безопасности ВС и разработать их классификацию. Эта задача являлась целью ряда зарубежных исследований [1, 4, 5, 6, 11, 12, 13, 16, 17,118]. Наибольший интерес представляет одно из новейших направлений исследований в данной области, предложенное в работе «Таксономия нарушений безопасности программного обеспечения, с примерами» [I]. Данная глава опирается на результаты этого исследования и представляет собой его обобщение и развитие с точки зрения объяснения причин нарушения безопасности и построения защищенных систем.
Любая атака на вычислительную систему (подразумеваются успешные атаки, в результате которых происходит нарушение информационной безопасности) опирается на определенные особенности построения и функционирования последней, иными словами — использует имеющиеся недостатки средств обеспечения безопасности. Для обозначения таких недостатков в [1] применяется английский термин «security flaw», определенный в [8]. Его можно трактовать следующим образом: «Ошибка в предоставлении полномочий (подразумевается как предоставление избыточных полномочий, так и их необоснованное лишение), ошибка в средствах контроля за использованием полномочий или другое упущение в средствах защиты, создавшее предпосылки нарушения информационной безопасности». В контексте изучения истории атак на вычислительные системы и построения таксономии причин нарушений информационной безопасности для наиболее точного отражения сущности термина «security flaw» представляется целесообразным ввести термин «изъян защиты» (ИЗ). Под ИЗ понимается совокупность причин, условий и обстоятельств, наличие которых в конечном итоге может привести к нарушению нормального функционирования ВС и нарушению безопасности (несанкционированный доступ, уничтожение или искажение данных). Как правило, под этим термином понимаются особенности построения входящих в состав ВС программных средств защиты, которые не в состоянии противостоять угрозам безопасности и обеспечивать безусловное выполнение возложенных на них задач.
Данная работа не преследует своей целью исчерпывающего описания всех известных случаев нарушения безопасности и детального изучения механизмов осуществления атак — этим вопросам посвящена отдельная книга сотрудников Центра защиты информации Санкт-Петербургского Технического Университета [21]. Для того чтобы подкрепить реальными фактами предлагаемую таксономию причин нарушения безопасности, в Приложении IV содержится список имевших место случаев нарушения безопасности, заимствованный из [I].
3.2. Исследования нарушений безопасности компьютерных систем
Наибольший интерес среди работ в области выявления, исследования и систематизации ИЗ представляют труды [2,12] и одна из последних публикаций в данной области [I]. Представляется целесообразным проанализировать результаты, полученные в работах [2,12,17], для того чтобы предоставить фактографическую основу, на которую опираются результаты последних научных исследований. Наиболее серьезные усилия по выявлению ИЗ в системах защиты с ^помощью экспериментов по их преодолению нашли свое отражение в разработанной в начале 70-х годов т.н. методологии гипотетического выявления ИЗ (Flaw Hypothesis Methodology) [12]. Данная методология предусматривает проведение исследований в три этапа. Первый этап состоит в изучении системы, причем особое внимание уделяется принципам функционирования механизмов защиты. На втором этапе происходит выдвижение предположений (гипотез) о потенциально уязвимых компонентах, которые затем тщательно проверяются на основании анализа документации, реальных особенностей ВС и деталей ее функционирования и с помощью проведения специальных тестов, призванных подтвердить или опровергнуть присутствие предполагаемого изъяна в системе защиты. Наконец, на третьем, заключительном этапе проводится обобщение полученных результатов и формируются списки (перечни) выявленных ИЗ и успешных атак. Хотя в [12] и присутствует перечень ИЗ исследованных систем, а также разработанных и успешно осуществленных атак, систематизация полученных данных проведена не была.
В середине 70-х годов подобные исследования проводились по проектам RISOS (Research in Secured Operating System — Исследования безопасности защищенных операционных систем) и PA (Protection Analysis — Анализ защиты). В обоих проектах были предприняты попытки формального описания и систематизации информации о ИЗ.
В заключительном отчете по проекту RISOS [2] приведено описание следующих категорий ИЗ в защищенных операционных системах:
1. Неполная проверка допустимости значений критичных параметров.
2. Противоречия в проверке допустимости значений критичных параметров.
3. Неявное совместное использование несколькими пользователями конфиденциальной информации.
4. Асинхронный контроль параметров или правильная последовательность действий.
5. Недостаточно надежная идентификация/аутентификация.
6. Возможность нарушения запретов и ограничений.
7. Использование ошибок в логике функционирования механизмов защиты.
В итоговом отчете по этому проекту описываются разработанные примеры атак для каждого типа ИЗ и содержится детальная информация по семнадцати реально выявленным ИЗ в трех операционных системах: IBM MVT, Univac 1100 и TENEX. Каждый из ИЗ четко соответствует одной из семи приведенных категорий.
Целью проекта РА был сбор информации и построение абстрактных моделей, которые в дальнейшем могли бы быть применены для автоматизированного поиска ИЗ. В результате исследования шести операционных систем (GCOS, Multics, Unix, IBM MVT, Univac 1100 и TENEX) было обнаружено более ста ИЗ, способных привести к несанкционированному проникновению в систему [4]. Для анализа обнаруженных ИЗ была разработана классификационная таблица, содержащая десять категорий ИЗ, среди которых можно выделить следующие группы:
1. Ошибки выделения областей (доменов), включающие незащищенное (в открытом виде) хранение и представление данных, неполное уничтожение объектов или их окружения.
2. Ошибки контроля и проверки, состоящие в некорректной проверке значений параметров и границ объектов.
3. Ошибки назначения имен, допускающие возможность использования нескольких имен для одного объекта и неполное запрещение доступа к уничтоженным объектам.
4. Ошибки в последовательности действий, влекущие за собой некорректное использование множественных ссылок (указателей) на объект и ошибки прерывания атомарных операций.
Предлагаемые в работе [5] методики поиска ошибок безопасности в операционных системах достаточно ограничены в практическом применении. Это можно объяснить предпринятой попыткой обеспечить универсальность методик, что отрицательно сказалось на возможности их развития и адаптации для новых ОС. С другой стороны, усилия исследователей слишком рано были перенаправлены от изучения ИЗ в сторону разработки универсальной технологии создания защищенных операционных систем, свободных от подобных ошибок.
Данная работа преследует более определенную и реальную цель: на основании опубликованной информации о ИЗ разработать их детальную классификацию и выявить причины их возникновения.
3.3. Таксономия ИЗ
Таксономия включает в себя комплексное исследование предметной области и создание модели множества изучаемых объектов, что позволяет определить признаки, которые могут быть положены в основу той или иной классификации.
С точки зрения технологии создания защищенных систем, наибольшее значение имеют следующие вопросы, на которые должна дать ответ таксономия ИЗ:
1. Каким образом ИЗ появляются в системе защиты? (Классификация ИЗ по источнику появления.)
2. На каком этапе они вносятся? (Классификация ИЗ по этапу возникновения.)
3. В каких компонентах системы защиты (или ВС в целом) они возникают и проявляются? (Классификация ИЗ по размещению в системе).
3.3.1. Классификация ИЗ по источнику появления
Как следует из определения ИЗ, источником их появления является ошибка или недоработка в системе безопасности. Исследованию ошибок, тем или иным образом связанных с безопасностью, всегда уделялось много внимания. В качестве примера можно привести работы [2,3,4,11,12,13,16,17]. Классификация ИЗ по источнику появления, приведенная в работе [I], представлена в таблице 3.1.
Данная таблица нуждается в комментариях. Под источником появления (в оригинале — genesis), в [1] понимается основа существования ИЗ, т. е. либо характеристики ВС, которые обусловливают его существование, либо принцип функционирования средств, использующих ИЗ для осуществления атаки. С точки зрения авторов, данный подход можно подвергнуть серьезной критике, так как он порождает некоторое противоречие между заявленным принципом классификации и полученными результатами. Действительно (см. таблицу 3.1), классификация преднамеренных ИЗ фактически представляет собой классификацию разрушающих программных средств (подробнее об РПС и методах анализа безопасности программ см. главу 2 в [20]) по принципам функционирования, а непреднамеренных — классификацию ошибок, возникающих в ходе программной реализации системы. Для решения практических задач наибольший интерес представляет классификация ИЗ по причинам возникновения, поэтому авторы провели собственное исследование, результаты которого будут представлены далее.
Таблица 3.1 Классификация ИЗ по источнику появления
Кол-во примеров
Индескы в Приложении IV*
Ошибки в системах защиты служащие источником появления ИЗ
Преднамеренные
С наличием деструктивных функций (активные)
Разрушающие программные средства (РПС)
Несамовоспроизводящиеся РПС «троянские кони»
3
PC1, PC 3, I8
Самовоспроязводящиеся РПС (вирусы)
7
U1, PC2, PC4, MA1, MA2, CA1 AT1
Черные ходы, люки, скрытые возможности проникновения в систему
2
U1, U10
Без деструктивных функций (пассивные)
Скрытые каналы утечки инф.
С использованием памяти
1
DT1
С использованием времени
2
I9, D2
Другие
5
I7, B1, U3, U6, U10
Непреднамеренные (случайные)
Ошибки контроля допустимых значений параметров
10
I4, I5, MT1, MU2, MU4, MC8, U7, U11, U12, U13
Ошибки определения областей (доменов)
7
I3, I6, MT2, MT3, MU3, UN1, D1
Ошибки последовательности действий и использование нескольких имен для одного объекта в том числе (TOCTTOU)
2
I1, I2
Ошибки идентификации/аутентификации
5
MU1, U2, U4, U5, U14
Ошибки проверки границ объектов
4
MT4, MU5 MU6, U9,
Другие ошибки в логике функционирования
4
MU7, MC9, U8, IN1
* Приложение IV содержит ряд типовых примеров нарушения безопасности ВС. Все примеры в этом Приложении отмечены уникальными идентификаторами, которые используются в тексте этой главы для ссылок .
Ошибки, служащие источником появления ИЗ, могут быть внесены в систему защиты специально (преднамеренно) либо возникнуть неумышленно (непреднамеренно). Для выявления таких непреднамеренных, случайных ошибок применяются различные стратегии и методики. Например, большинство случайных ошибок может быть выявлено и устранено при увеличении времени и глубины анализа и легирования кода систем защиты. Но в отношении наиболее серьезных преднамеренно внесенных (и, вероятнее всего, замаскированных) ошибок этот способ окажется малоэффективным. Для того чтобы сделать процесс поиска таких ошибок более продуктивным, необходимо проведение специальных испытаний, заключающихся в осуществлении попыток проникновения в ВС и проведении атак на систему защиты. Обобщение информации о ИЗ, позволяющее осуществить аргументированный выбор эффективной стратегии выявления ошибок в системах обеспечения безопасности путем проведения экспериментальных атак, является одной из задач данной работы.
Характеристика преднамеренности является в определенной мере относительной. В некоторых случаях определенные функции, сознательно добавленные в программное обеспечение, предопределяли внесение в систему защиты непреднамеренных ошибок. Например. возможность использования удаленной отладки или настройки системы может привести к появлению ИЗ.
Хотя определенные преднамеренные ошибки могут рассматриваться как случайные, трудно представить, скажем, случайно возникшую «троянскую» программу. В спорных случаях при классификации ошибок по их происхождению в работе [1] рекомендуется обратиться к другим классификационным признакам, например к этапу внесения ошибки. Как правило, случайные ошибки вносятся в систему при разработке требований к безопасности и спецификаций системы защиты (откуда они автоматически переносятся в реализующие их средства), а также в процессе сопровождения системы (обновления версии, поставки новых утилит и т.п.). Напротив, преднамеренные ошибки внедряются в систему именно на этапе ее применения (если, конечно, среди разработчиков системы не было лица, заинтересованного в них).
Преднамеренные ошибки являются достаточно труднообнаруживаемыми, потому что они специально скрыты, замаскированы именно с целью не быть обнаруженными. Они же являются самыми опасными: специально внесенные ошибки с деструктивными функциями могут серьезно нарушить функционирование системы. Случайные ошибки, безобидные сами по себе, также могут быть использованы для этих же целей специально написанными программами. Рассмотрим подробнее основные классы преднамеренно внесенных ИЗ.
3.3.1.1. Преднамеренно внедренные ИЗ с наличием деструктивных функций
Преднамеренно внесенные в систему защиты изъяны и связанные с ними каналы утечки информации по сути дела являются результатом функционирования предварительно внедренных специальных средств, о которых говорилось выше. Общей характерной чертой разрушающих программных средств (РПС) является активный характер их функционирования — противодействие системе обеспечения безопасности и обеспечение утечки информации. Как правило, они имеют жаргонные названия. подчеркивающие их суть, например, «троянский конь», «логическая бомба», «часовая мина». Более подробно авторы рассмотрели проблему РПС в [19]. «Логические бомбы» и «часовые мины» – это РПС, которые не выполняют никаких функций до наступления определенного события в системе, после чего «срабатывают», что, как правило, приводит к серьезным нарушениям работы системы, уничтожению информации и другим деструктивным последствиям. Особенностью проявления данного вида преднамеренно внедряемого кода является отсутствие каких-либо мер маскировки выполнения деструктивных функций. Последствия «срабатывания» чаще всего носят катастрофический характер и могут привести к полной потере работоспособности ВС и уничтожению хранящихся в ней данных. РПС являются одним из самых опасных и самым разрушительным видом ИЗ.
«Черным ходом» называется скрытая (замаскированная) возможность получения доступа к ресурсам в обход стандартных механизмов контроля. Например, разработчик программы проверки идентификатора может предусмотреть осуществление некоторых действий при совпадении контролируемого параметра с известной только ему константой, скажем, отменить контроль доступа для субъекта с этим идентификатором. В дальнейшем разработчик может использовать «черный ход» для бесконтрольного доступа к информации (по мнению авторов, использование «черного хода» не всегда связано с применением деструктивных функций).
3.3.1.2. Преднамеренно внедренные ИЗ без деструктивных функций
РПС могут осуществлять взаимодействие с атакующим систему злоумышленником через т.н. «скрытые каналы» утечки информации. Под скрытым каналом будем понимать любую возможность обмена информацией, не предусмотренную разработчиками средств защиты и, как следствие, ничем не контролируемую [10]. В силу отсутствия контроля за скрытыми каналами со стороны системы защиты они широко используются злоумышленниками. Для использования скрытых каналов требуется наличие двух процессов: один осуществляет сбор информации, интересующей злоумышленника, и помещает ее в скрытый канал, который не контролируется системой защиты. Другой процесс осуществляет прослушивание канала в ожидании начала передачи и при ее появлении выполняет необходимую обработку и сохранение собранной информации.
Скрытые каналы утечки, в зависимости от способа кодирования информации, передаваемой между этими процессами, подразделяются на два типа: с использованием памяти и с использованием времени.
В первом случае для кодирования передаваемой информации используется либо область памяти, не имеющая важного значения (например, установление характерных признаков в имени и атрибутах файла), либо вообще неиспользуемая область (например, зарезервированные поля в заголовке сетевого пакета).
Во втором случае, более сложном для реализации, информация кодируется определенной последовательностью и длительностью событий, происходящих в системе (например, с помощью модуляции интервалов обращения к устройствам, введения задержек между приемом и посылкой сетевых пакетов и т.д.).
Кроме скрытых каналов в системе могут присутствовать и другие преднамеренно внесенные ошибки, не влекущие за собой разрушительных последствий. К их появлению обычно приводит расхождение между требованиями безопасности и требованиями к функциональным возможностям ВС. В силу присущей скрытым каналам трудности выделения общих особенностей и их специфичности более подробная их классификация не проводилась, так как выходит за рамки данной работы.
3.3.1.3. Непреднамеренные ошибки и ИЗ
Непреднамеренные ИЗ могут возникнуть из-за ошибок, допущенных на этапе разработки требований, при создании спецификаций и на этапе реализации. Ошибки этого типа были подробно исследованы в работах [2,4]. Хотя большинство из них обнаруживается и устраняется в процессе тестирования, ряд ошибок может остаться незамеченным и вызвать определенные проблемы на этапе эксплуатации системы. Наиболее трудно выявляются такие ошибки в сложных системах, состоящих из многочисленных компонентов и разработанных при участии большого коллектива специалистов. Одна из неотъемлемых проблем таких систем — невозможность составления исчерпывающих спецификаций, т. е. невозможность качественного документирования. Недостатки проектной документации в процессе сопровождения и эксплуатации системы приводят к тому, что при попытке устранения одних ошибок в нее вносятся другие. И хотя наличие неумышленных ошибок не приводит к немедленному их использованию и нарушению безопасности системы, это является лишь вопросом времени.
Непреднамеренные ИЗ могут быть классифицированы в соответствии со следующими группами ошибок:
1. Ошибки контроля допустимых значений параметров.
2. Ошибки определения доменов.
3. Ошибки последовательности действий и использования нескольких имен для одного объекта.
4. Ошибки идентификации/аутентификации.
5. Ошибки проверки границ объектов.
6. Ошибки в логике функционирования.
Ошибки контроля допустимых значений параметров заключаются в принятии соответствующим механизмом неправильного заключения о соответствии проверяемого параметра допустимым значениям. Это касается числа. состава, типа, размера, статуса (передаваемые или принимаемые) параметров или ряда других их характеристик. Ошибки контроля можно рассматривать как неадекватную реакцию механизмов защиты на возникающие в системе события.
Ошибки определения доменов выражаются в наличии неконтролируемого способа доступа в защищенною область. Например, возможность получения доступа; к объекту файловой системы, непосредственный доступ к которому запрещен, посредством доступа к его физическому представлению на магнитных носителях. Другим примером является возможность доступа к остаточной информации в занимаемой объектом области памяти после его уничтожения.
Наличие ошибок последовательности действий предопределяется асинхронным функционированием компонентов системы, которое может быть использовано для нарушения безопасности. Выявить такие ошибки в системе достаточно трудно. Их суть заключается в том, что в силу невозможности представления каждой из функций системы единственной атомарной операцией многие из функций выполняются как некоторая асинхронная последовательность действий (операций), осуществляемых несколькими компонентами системы. Например, одной из одновременно выполняющихся операций может быть проверка идентификатора процесса, а второй — установка для него соответствующих полномочий; в общем случае — использование параметра и проверка его допустимости. Асинхронность может быть использована злоумышленником для обмана механизмов контроля путем подмены параметра на другой, запрещенный, после проверки, но перед использованием. Данная ошибка носит название TOCTTOU (time-of-check to time-of-use) [1б], (II в Приложении IV).
Ошибки идентификации/аутентификации приводят к тому, что неуполномоченный пользователь получает доступ к защищенным объектам с полномочиями другого пользователя. Эти ошибки в принципе можно рассматривать как ошибки контроля в том смысле, что происходит неправильная проверка параметров идентификации и подлинности пользователя и объекта. Однако, по причине значительного числа случаев нарушений безопасности из-за неправильной идентификации/аутентификации, целесообразно рассматривать данную категорию ошибок как отдельную.
Ошибки проверки границ объектов и связанные с ними каналы утечки обычно возникают из-за игнорирования контроля за пересечением объектом границ области памяти, отведенной для его хранения (контроль длины строки, размера массива, размера и положения файла и т.д.). Самый известный пример такого рода — программа finger в ОС Unix (U12 в Приложении IV).
Кроме того, существуют другие ошибки, не попадающие непосредственно ни в одну из перечисленных категорий. В целом их можно назвать ошибками логики функционирования системы и механизмов защиты, которые потенциально могут быть использованы злоумышленниками для проникновения в систему и нарушения безопасности.
3.3.2. Классификация ИЗ по этапу возникновения
В отличие от исследования вопроса об источниках возникновения ИЗ, анализу этапа появления ошибок уделяется недостаточное внимание. Результаты исследования данного вопроса подробно изложены в нескольких работах, наибольший интерес из которых представляет [2], в которой проблема выявления этапа возникновения ошибок рассматривается по отношению к жизненному циклу программного обеспечения.
Существует большое число моделей жизненного цикла программных систем и подходов к процессу разноработки программного обеспечения. Для выделения категорий ИЗ можно построить простую абстрактную схему, описывающую широкий спектр технологий разработки ПО.
На самом верхнем уровне представления жизненного цикла систем можно выделить три фазы:
· фазу разработки, которая охватывает весь период создания первой рабочей версии системы;
· фазу сопровождения, в ходе которой происходит модификация, совершенствование, развитие системы и появление ее очередных версий;
· фазу эксплуатации, т. е. непосредственного функционального применения конкретной версии системы.
Хотя на практике фазы сопровождения и эксплуатации перекрываются во времени, им присущи различные особенности, которые позволяют выделить соответствующие категории ИЗ. Классификация ИЗ по этапу возникновения, основанная на этих положениях, приведена в таблице 3.2.
Рассмотрим подробнее перечисленные этапы с точки зрения возможности появления ошибок, приводящих к возникновению ИЗ.
3.3.2.1. Возникновение ИЗ в процессе разработки системы
Процесс разработки любой программной системы включает в себя несколько этапов. Прежде всего формулируются требования к системе, затем, исходя из этих требований, разрабатываются спецификации. На основании спецификаций создаются исходные тексты программ, которые затем компилируются и превращаются в исполняемый код. И на каждом из этих этапов в создаваемую систему могут быть внесены ошибки, которые приводят к возникновению ИЗ.
3.3.2.1.1. Составление требований и спецификаций
Требования к программному обеспечению описывают что должна делать программа. Спецификации определяют то, каким образом эти действия должны выполняться. Требования н спецификации взаимосвязаны настолько тесно, что относить обусловленные ими ИЗ к разным категориям представляется нецелесообразным.
Маловероятно, что требования или спецификации могут содержать положения, явно обусловливающие преднамеренные ошибки и каналы утечки информации. И требования, и спецификации достаточно открыты, поддаются пониманию и анализу, что позволяет относительно легко выявить и устранить ошибки типа наличия «черного хода» и им подобные.
Более реально появление ошибок, обусловленных необходимостью одновременного выполнения как требований безопасности, так и общих требований к функциональным возможностям системы. Конкуренция этих требований и неизбежно возникающие противоречия требуют от разработчиков принятия компромиссных решений, в которых предпочтение может быть отдано функциональности системы в ущерб ее безопасности. В качестве примера можно привести выполнение пользователем программ в режиме супервизора с целью увеличения быстродействия или разрешение на модификацию кода прямо во время выполнения программ для осуществления отладки.
Таблица 3 2 Классификация ИЗ по этапу возникновения
Количество примеров
Индексы в Приложении IV
Этап внедрения ошибки и
возникновения ИЗ
На стадии разработки
Ошибки в требованиях и спецификациях
22
I1, I2, I3, I4, I5, I6
Ошибки в исходных текстах программ
15
MT1,MT4,MU1,MU2,
MU5,MU7,MU8, DT1,U2,U3,U4
Ошибки в исполняемом коде
1
Ul
В ходе сопровождения
3
D1,MU3,MU9
В ходе эксплуатации
9
I8, PC1, PC2, PC3, PC4, MA1, MA2, CA1, AT1
3.3.2.1.2. Создание исходных текстов программ
Создание исходных текстов программ обеспечивает воплощение требований и спецификаций и является логическим продолжением соответствующих этапов. Большинство ошибок (но не все) в исходных текстах, как случайных, так и внесенных преднамеренно, может быть обнаружено при тщательном их изучении.
Наиболее распространены случайные ошибки в исходных текстах программ. Чаще всего они возникают в результате неадекватной реализации определенных в требованиях интерфейсов либо просто из-за ошибок программистов.
Преднамеренные ошибки могут быть внесены в систему по целому ряду причин. Программист может внедрить в систему код, не предусмотренный ее спецификациями, но необходимый ему для отладки и тестирования разрабатываемой программы. Однако, если по завершению разработки этот код не будет удален из системы, он превратится в реальный канал утечки информации и может быть использован злоумышленником. Самый известный пример такого рода — программа sendmail, позволившая широко распространиться сетевому вирусу Морриса (U10 в Приложении IV).
3.3.2.1.3. Генерация исполняемого кода
Исполняемый код генерируется компиляторами на основе исходных текстов программ. Поскольку компиляторы предназначены только для формального преобразования исходных текстов в исполняемый код, они автоматически переносят ошибки из первых во второй.
Однако, если ошибки содержатся в самом компиляторе, они могут использоваться злоумышленниками для получения в компилируемых программах нужных им фрагментов кода (U1 в Приложении IV).
3.3.2.2. Возникновение ИЗ в процессе сопровождения и развития системы
Случайные ошибки, внесенные в систему во время ее сопровождения, чаще всего обусловлены неправильным представлением программистами каких-либо аспектов функционирования системы в целом. Любые изменения, вносимые ими в систему, потенциально}) могут превратиться в каналы утечки информации.! Поэтому каждое вносимое в ПО изменение должно сопровождаться тщательной проверкой всей системы так, как если бы это было испытанием абсолютно новой системы.
3.3.2.3. Возникновение ИЗ в процессе функционирования системы
Возникновение ошибок и сбоев, утечка информации и другие подобные явления в процессе функционирования системы в большинстве случаев происходят по причине воздействия на нее специально написанных программ (РПС).
Хорошо известные случаи вирусных атак являются наиболее ярким обоснованием необходимости постоянного контроля и анализа состояния системы и исполняемых файлов [19]. Основной задачей такого анализа в процессе функционирования системы является выявление несанкционированной модификации каких-либо фрагментов исполняемого кода. Очевидно,. что целью РПС является не просто модификация кода, а нарушение функционирования системы и, возможно, доступ к конфиденциальной информации, перехват паролей, создание скрытых каналов утечки и т.д.
3.3.3. Классификация ИЗ по размещению в системе
ИЗ можно классифицировав по их размещению в ВС в зависимости от того, в каких компонентах системы они находятся. Большинство ошибок, приводящих к возникновению ИЗ и нарушению требовании защиты, присутствует в программном обеспечении, хотя они могут встречаться и в аппаратуре В данной работе основное внимание уделено исследованию таксономии ИЗ в программном обеспечении вообще и в операционных системах в частности, однако функционирование программ всецело зависит от аппаратной платформы Следовательно, ИЗ может использовать ошибки аппаратуры. Это определяет необходимость внесения в классификацию соответствующих категорий, ошибки в программном обеспечении и ошибки аппаратных платформ (таблица 3.3).
Компоненты программного обеспечения, вне зависимости от их конкретного назначения, чрезвычайно сильно взаимозависимы. Поэтому предлагаемое разделение программ по категориям носит достаточно условный характер.
Среди всего комплекса программного обеспечения в отдельную категорию в первую очередь выделим операционную систему. В ней определена и реализована архитектура всей вычислительной системы, и наличие в ней ошибок, связанных с обеспечением безопасности, автоматически повлечет за собой серьезные последствия для всей ВС в целом.
Непосредственно с ОС связано сервисное программное обеспечение, обеспечивающее поддержку различных аспектов функционирования системы Кроме того, существует прикладное программное обеспечение, с которым непосредственно работают пользователи
Таблица 3.3 Классификация ИЗ по размещению в вычислительной системе
Кол-во примеров
Индексы в Приложении IV
Размещение вВС
Программное обеспечение
Операционная система
Инициализация (загрузка)
8
U5, U13, PC2, PC4, MA1, MA2, AT1, CA1
Управление выделением памяти
2
MT3, MU5
Управление процессами
10
I6, I9, MT1, MT2, MU2, MU3,
MU4, MU6, U7, UNl
Управление устройствами
3
I2, I3, I4
Управление файловой системой
6
I1, I5, MU8, U2, U3, U9
Средства идентификации и аутентификации
5
MU1, DT1, U6. U11, D1
Другие
1
MT4
Сервисные программы и утилиты
Привилегированные утилиты
10
I7, B1, U4, U7, U8, U10,
U12, U14, PC1, PC3
Непривилегированные утилиты
1
Ul
Прикладные программы
1
I8
Аппаратное обеспечение
3
MU9, D2, IN1
3.3.3.1. Системное программное обеспечение
Операционные системы обычно включают в себя функции управления процессами, устройствами, распределением памяти, файловой системой и т.д. Кроме того, они обеспечивают инициализацию вычислительной системы при загрузке и содержат основные механизмы обеспечения безопасности. Однако, поскольку состав этих механизмов не стандартизован и сильно меняется от системы к системе, в данной классификации выделен только механизм идентификации/аутентификации как один из важнейших и присущий всем системам без исключения.
Итак, положение ИЗ в операционной системе будем разделять по следующим категориям:
· инициализация (загрузка) системы;
· управление распределением памяти;
· управление устройствами;
· управление процессами;
· управление файловой системой;
· идентификация и аутентификация.
Для ошибок, не попадающих ни в одну из данных категорий, введем дополнительную категорию «другие».
Процесс инициализации системы имеет четко определенные функции, но все же достаточно сложен и весьма различен в разных системах. Ошибки на этапе инициализации могут возникнуть в результате неправильного взаимодействия с аппаратурой (например, если произошли изменения в составе аппаратных средств) или при задании неверных параметров конфигурации. Ошибки такого рода приводят, как правило, к неправильному назначению полномочий доступа к ресурсам системы.
Управление процессами и управление распределением памяти — основные задачи операционной системы, и ошибки в данных механизмах приводят к получению злоумышленником контроля над всей системой и свободному доступу к любой информации.
Управление устройствами подразумевает наличие комплекса программ ввода/вывода, обеспечивающих функционирование устройств параллельно и независимо от центрального процессора. Ошибки в таких программах, например ошибки приема/передачи управляющих параметров и команд устройствам, приводят либо к отказам и сбоям в работе устройств, либо позволяют злоумышленнику получить информацию, доступ к которой ему запрещен.
Файловая система использует значительное число функций операционной системы — управление процессами, устройствами, распределением памяти и т.д. Соответственно, ошибки в этих компонентах автоматически распространяются и на файловую систему. Кроме того, файловая система может содержать и собственные ошибки, касающиеся хранения данных и ограничения доступа к ним. Неверное представление данных влечет за собой неправильное функционирование механизмов контроля. Таким образом, средства обеспечения безопасности, принадлежащие операционной системе, оказываются непосредственно связанными с механизмами управления файловой системой. Наличие ошибок в механизмах управления файловой системой способна привести к нарушению функционирования и безопасности всей ВС в целом.
Идентификация и аутентификация являются отправными точками в функционировании любой системы защиты. Как правило, операционная система содержит специальные файлы, в которых хранятся имена и пароли, на основании которых и выполняются указанные процедуры. Чрезвычайно важно обеспечить не только корректную реализацию процедур идентификации и аутентификации, но и всестороннюю защиту этих файлов от несанкционированного доступа и изменения, иначе злоумышленник легко сможет выдать себя за легального пользователя и получить соответствующие полномочия.
3.3.3.2. Сервисное программное обеспечение
Термин «сервисное программное обеспечение» включает в себя компиляторы, отладчики, редакторы, библиотеки функций, системы управления базами данных и т.п. Операционная система при запуске таких программ обычно предоставляет им специальные привилегии, превышающие привилегии работающего с ними пользователя. Поэтому о сервисном программном обеспечении можно говорить как о множестве привилегированных утилит.
Привилегированные утилиты, как правило, являются сложными программами и часто обеспечивают выполнение функций, не предусмотренных операционной системой. Кроме того, они разрабатываются отдельно от последней и могут не поддерживать принятые в ней ограничения и требования безопасности даже при наличии собственной защиты. Это означает, что привилегированные утилиты являются потенциально опасными с точки зрения защиты ВС в целом.
Наличие ошибок в реализации защиты привилегированных утилит или каналов утечки информации в них может быть использовано злоумышленником, который в случае успеха получит возможности, соответствующие специальным привилегиям утилиты, с которой он работает. Наиболее известным примером подобного родя являются многочисленные ошибки в системных утилитах ОС UNIX с установленным битом SUID (U5 в Приложении IV).
3.3.3.3. Прикладное программное обеспечение
Нарушения в функционировании вычислительных систем, вызванные неумышленными ошибками в прикладном программном обеспечении, обычно ограничиваются только содержащим эту ошибку процессом, который либо некорректно функционирует либо останавливается или зацикливается. Однако это не означает, что все ошибки в прикладном программном обеспечении столь же безобидны. Преднамеренно внесенные программные закладки, вирусы, «троянские кони» и «логические бомбы» находятся именно на уровне прикладного программного обеспечения. Объектами их атак .потенциально могут стать любые компоненты вычислительной системы, и последствия такого воздействия могут быть очень серьезными — вплоть до выведения операционной системы из строя. В этом случае успех атаки зависит от того, насколько защищена конкретная ОС от разрушительных действий прикладных программ. Многопользовательские многозадачные ОС (такие, как Unix) сравнительно легко справляются с подобной проблемой, а широко распространенные DOS и Windows в этой ситуации оказываются практически бессильными.
3.3.4. Результаты исследования таксономии ИЗ и их практическое применение
Рассмотренная таксономия ИЗ, основанная на результатах исследования [I], дает достаточно полное представление о классификации ИЗ с точки зрения источника их появления, этапа возникновения и размещения в ВС. Эти результаты, несомненно, представляют собой самостоятельный интерес и имеют ценность для пассивного исследования и классификации ИЗ. С точки зрения поиска путей и способов противостояния угрозам безопасности этого недостаточно, так как отсутствует классификация причин нарушений безопасности. Поэтому представляется необходимым развить эти исследования и провести анализ случаев нарушения безопасности с точки зрения таксономии причин появления ИЗ, чтобы получить представление о первоисточниках данного явления. Такая таксономия будет служить основой для разработки принципиально новых технологий и средств защиты, устраняющих причины существования ИЗ, и, следовательно, обеспечивающих максимальную безопасность.
3.4. Исследование причин возникновения ИЗ
По мнений авторов, сложившаяся практика исследования случаев нарушения безопасности, уделяющая основное внимание методам и средствам преодоления защиты обладает существенным недостатком — отталкиваясь от действий злоумышленника, она фактически представляет собой анализ технологии преодоления средств защиты и не позволяет выявить недостатки средств обеспечения безопасности. Кроме того, подобный подход сразу разделяет все случаи нарушения безопасности на умышленные, классифицируемые но способам преодоления защиты, и неумышленные, обусловленные ошибкам программирования. Авторы придерживаются норматической точки зрения на этот вопрос — важен сам факт нарушения безопасности и те меры, которые необходимо предпринять для предотвращения подобных нарушений, а их преднамеренность не имеет значения. С этой точки зрения залог успешных действий злоумышленника, как и предпосылки случайных нарушений, предопределен свойствами самой ВС — ее архитектурой, реализацией и администрированием. Это означает что в основе каждого факта нарушения безопасности ВС лежит соответствующий изъян средств защиты обусловивший успешное осуществление атаки. Анализ случаев нарушения безопасности должен основываться не столько на исследовании методов, используемых нарушителем сколько на выявлении свойств системы позволивших ему осуществить свои действия.
Поэтому для решения задачи данной главы — определения обстоятельств, приводящих к успешной реализации угроз безопасности, их систематизации и выявления первопричин их появления предлагается разработанная авторами таксономия причин нарушений безопасности ВС, или причин возникновения ИЗ, которая связывает случаи нарушения безопасности с принципами организации защиты ВС, обусловившими их осуществимость. Таксономия причин возникновения ИЗ должна дать ответ на имеющий ключевое значение с практической точки зрения вопрос: что явилось причиной успешною осуществления нарушения безопасности в том или ином случае ? Для ответа на него необходимо выявить те свойства и особенности архитектуры ВС, которые привели к возможности успешного осуществления соответствующих атак. Только знание природы этих причин позволит оценить способность системы противостоять атакам, а также понять природу недостатков, присущих существующим средствам обеспечения безопасности, и построить защищенную систему, лишенную этих недостатков.
3.4.1. Таксономия причин возникновения ИЗ
Рассмотрим с этой точки зрения известные случаи нарушения безопасности ВС, используя в качестве примеров статистику из Приложения IV. Анализ показывает, что все случаи произошли по одной из следующих причин (рис. 3.1):
1. Выбор модели безопасности, не соответствующей назначению или архитектуре ВС. Модель безопасности (модели безопасности, их свойства и методы реализации рассмотрены в главе 4 II тома) должна соответствовать как требованиям безопасности, предъявляемым к ВС, так и принятой в ней концепции обработки информации, в основном определяемой архитектурой ОС. В настоящий момент наблюдается определенное несоответствие между моделями безопасности и архитектурой ОС. Фактически формальные модели безопасности существуют только в виде теории, а разработчики ОС вынуждены подвергать их интерпретации, чтобы приспособить к конкретной ОС. При этом приходится идти на определенные компромиссы, и может оказаться, что модель безопасности в ходе реализации подверглась существенным искажениям. Это означает, что при выборе модели безопасности нельзя не учитывать специфику архитектуры ВС; в противном случае, несмотря на все достоинства модели, гарантированного ею уровня безопасное ги достичь не удастся.
2. Неправильное внедрение модели безопасности. Несмотря на правильный выбор модели безопасности, ее реализация и применение к архитектуре конкретной ОС в силу свойств самой модели или ОС было проведено неудачно. Это означает, что в ходе реализации были потеряны теоретические достижения, полученные при формальном доказательстве безопасности модели. Это наиболее распространенная причина нарушения безопасности ВС. Обычно неправильное внедрение модели безопасности в систему выражается в недостаточном ограничснии доступа к наиболее важным для безопасности системы службам и объектам, а также во введении различных исключений из предусмотренных моделью правил разграничения доступа типа привилегированных процессов, утилит и т. д. В качестве примеров можно привести случаи I1, I4, I6, I7, MU3, Bl. UN1, U4, U5, U14 из Приложения IV.
3. Отсутствие идентификации и/или аутентификации субъектов и объектов. Во многих современных ОС (различные версии Unix, Novell NetWare, Windows) идентификация и аутентификация субъектов и объектов взаимодействия находятся на весьма примитивном уровне — субъект может сравнительно легко выдать себя за другого субъекта и воспользоваться его полномочиями доступа к информации. Кроме того, можно внедрить в систему «ложный» объект, который будет при взаимодействии выдавать себя за другой объект. Часто идентификация и аутентификация носят непоследовательный характер и не распространяются на все уровни взаимодействия; так, например, в ОС Novell NetWare предусмотрена аутентификация пользователя, но отсутствует аутентификация рабочей станции и сервера. В стандартной версии ОС Unix аутентификация пользователей находится на очень примитивном уровне: программы подбора пароля легко справляются со своей задачей при наличии у злоумышленника идентификатора пользователя и зашифрованного пароля. Ряд служб ОС Unix (в первую очередь сетевые службы, использующие стек протоколов TCP/IP) и всемирная информационная сеть Internet в силу сложившихся обстоятельств и необходимости соблюсти требования по совместимости в глобальном масштабе вообще не предусматривают аутентификации при сетевых взаимодействиях [21] (пример MU1 из Приложения IV).
4. Отсутствие контроля целостности средств обеспечения безопасности. Во многих ОС контролю целостности самих механизмов, реализующих функции защиты, уделяется слабое внимание, но, как уже говорилось, в условиях распространения РПС контроль целостности приобретает решающее значение. Многие системы допускают прозрачную для служб безопасности подмену компонентов. Например, ОС Unix традиционно построена таким образом, что для обеспечения ее функционирования многие процессы должны выполняться с уровнем полномочий, превышающим обычный пользовательский уровень (с помощью механизма замены прав пользователя на права владельца программы). Такие приложения являются потенциальной брешью в системе защиты, так как нуждаются в проверке на безопасность при установке в систему и постоянном контроле целостности в ходе эксплуатации. С точки зрения безопасности, такая ситуация является недопустимой, так как не соблюдается принцип минимальной достаточности при распределении полномочий процессов и пользователей. Список критичных приложений и пользователей, обладающих высоким уровнем привилегий, должен быть максимально ограничен. Этого можно достичь путем последовательного применения принципа локализации функций обеспечения безопасности и целостности в рамках ядра ОС (пример U1 Приложения IV).
5. Ошибки, допущенные в ходе программной реализации средств обеспечения безопасности. Эта группа причин нарушения безопасности будет существовать до тех пор, пока не появятся технологии программирования, гарантирующие производство безошибочных программ. По-видимому, такие технологии не появятся и ошибки такого рода будут возникать всегда. Исчерпывающее тестирование и верификация программных продуктов (особенно реализующих функции защиты) позволяют сократить вероятность появления подобных ошибок (примеры МТ1, MU2, DT1, Dl, U2, U3, U7, |U11, U 12 Приложения IV).
6. Наличие средств отладки и тестирования в конечных продуктах. Многие разработчики оставляют в коммерческих продуктах т. н. «люки», «дыры», отладочные возможности и т.д. Наиболее известные примеры — отладочная опция в программе sendmail и встроенный отладчик ОС Novell NetWare. Причины, по которым это происходит, вполне понятны — программные продукты становятся все сложнее, и отладить их в лабораторных условиях становится просто невозможно. Следовательно, для определения причин сбоев и ошибок уже в .процессе эксплуатации разработчикам приходится оставлять в своих продуктах возможности для отладки и диагностики в ходе эксплуатации. Очевидно, что для тех ситуаций, где безопасность имеет решающее значение, применение подобной практики недопустимо (пример U 10 Приложения IV).
7. Ошибки администрирования. Наличие самых современных и совершенных средств защиты не гарантирует от возможных нарушений безопасности, так как в безопасности любой системы присутствует человеческий фактор — администратор, управляющий средствами обеспечения безопасности, может совершить ошибку, и все усилия разработчиков будут сведены на нет. Ошибки администрирования являются достаточно распространенной причиной нарушений безопасности, но часто списываются на ошибки разработчиков средств защиты.
Предложенный подход к классификации причин нарушения безопасности в отличие от существующих подходов позволяет определить полное множество независимых первопричин нарушений безопасности, несводимых одна к другой. и образующих ортогональное пространство факторов, определяющих реальную степень безопасности системы.
Рис. 3.1 Таксономия прпичин нарушения безопасности ВС
3.4.2. Взаимосвязь таксономии причин нарушения безопасности и классификации ИЗ
Рассмотрим взаимосвязь между рассмотренной таксономией причин возникновения ИЗ и предложенной в работе [1] классификацией источников появления и этапов внедрения ИЗ.
Сопоставление предложенной таксономии причин нарушения безопасности и классификации источников появления ИЗ [I] показано на рис. 3.2.
Рисунок 3.2 демонстрирует, что источником появления наибольшего количества категорий ИЗ является неправильное внедрение модели безопасности и ошибки в ходе программной реализации. Это означает, что эти причины являются более значимыми и должны быть устранены в первую очередь.
На рис. 3.3 показано соответствие между причинами нарушений безопасности и классификацией ИЗ по этапу внесения [I].
Из рис 3.3 видно, что появление основных причин нарушения безопасности закладывается на этапе разработки, причем в основном на стадии задания спецификаций. Это вполне ожидаемый результат, так как именно этап составления спецификаций является одним из самых трудоемких, а последствия ошибок в спецификациях сказываются на всех дальнейших этапах разработки и распространяются на все взаимосвязанные компоненты системы.
Рис. 3.2 Сопоставление таксономии причин нарушения безопасности и классификации источников появления ИЗ.
Рис. 3.3 Сопоставление таксономии причин нарушения безопасности и классификации ИЗ по этапу внесения.
Поскольку большинство причин нарушения безопасности определяет появление ИЗ практически в любом компоненте ВС, сопоставление причин нарушения i безопасности с классификацией ИЗ по размещению в системе проводить нецелесообразно.
Перекрестный анализ таксономии причин нарушений безопасности и классификаций ИЗ по источнику появления и этапу внесения показывает, что наиболее значимые причины (неправильное внедрение модели безопасности и ошибки программной реализации) действуют в ходе процесса разработки и реализации. Следовательно, именно на этих этапах должны быть сосредоточены основные усилия при создании защищенных систем.
Приведенное сопоставление показывает, что предложенные причины нарушения безопасности полностью охватывают как все аспекты появления, так и этапы внесения ИЗ. Таким образом, предложенная таксономия причин нарушения безопасности полностью подтверждается существующими исследованиями ИЗ, однако носит более принципиальный характер и, следовательно, обладает более высокой степенью общности.
3.5 Заключение
Представленная таксономия причин нарушения безопасности позволяет определить значимость каждой из причин и выявить этапы разработки ВС, на которых они могут быть устранены. Как следует из проведенных исследований, наибольшее значение имеют принципы организации защиты и управление доступом, т. е. те составляющие безопасности ВС, которые закладываются на ранних стадиях определения требований, выбора модели безопасности и архитектуры средств защиты. Все эти действия можно объединить в один этап — выбор технологии защиты ВС.
Кроме того, данная таксономия имеет и самостоятельное значение — ее можно использовать как основу для анализа и экспериментального тестирования систем защиты, так как она позволяет выбрать направления и способы проведения тестовых атак на наиболее уязвимые компоненты систем защиты. На основании данного подхода в Центре защиты информации Санкт-Петербургского Технического Университета были проведены исследования безопасности распространенных ОС и компьютерных сетей, основные результаты которых приведены в работах [20, 21]. Эти результаты на практике подтверждают правильность предложенной таксономии и доказывают адекватность рассмотренных причин нарушения безопасности механизмам действия реальных средств нарушения безопасности.
Разработанная авторами таксономия причин нарушения безопасности является первым и необходимым этапом для решения задач построения защищенных систем обработки информации, поставленных в первой главе, и может служить отправной точкой для адекватной реализации требований безопасности, представленных во второй главе, и корректного воплощения моделей безопасности (этому вопросу будет посвящена четвертая глава II тома). Это позволяет говорить о создании качественно новой, научно обоснованной и подтвержденной существующей практикой нарушения безопасности ВС технологии построения защищенных систем, которая будет подробно рассмотрена в пятой главе II тома данной книги.
Литература к главе 3
1. Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S.Choi. Information Technology Division, Code 5542, Naval Research Laboratory, Washington, D.C. 20375-5337// A Taxonomy of Computer Security Flaws, with Examples.
2. Abbott R. P. Chin J. S., Donnelley J. E„ Konigsford \V. L„ Tokubo S. and Webb D. A. 1976 Security analysis and enhancements of computer operating system. NBS1R 76-1041. National Bureau of Standards, ICST. April 1976.
3. Andersen J. P. 1972. Computer security technology planning study. ESD-TR-73-51. Vols I and II, NTIS AD 758206,’ Hanscom Field. Bedford, MA (October 1972).
4. Bisbey II. R. and Hollingwoith, D. 1978. Protection analysis project report. ISI/RR-78-13, DT[C AD A056816. USC/Information Sciences Institute (May 1978).
5. Brehmer С. L. and Carl J. R. Hollingworth, 1993 Incorporating IEEE Standard 1044 into your anomaly tracking process. CrossTalk, J. Defense Software Engineering, 6 (Jan. 1993), 9-16.
6. Chillarege R., Bhandari I. S., Chaar J. K Halliday M. J., Moebus D. S., Ray B. K and Wong, M-Y. 1992. Orthogonal defect classification-a concept for in-process measurements. IEEE Trans. on Software Engineering, 18,11, (Nov. 1992), 943-956.
7. Cohen, F. 1984. Computer viruses: theory and experiments, 7th DoD/NBS Computer Security Conference, Gaithersburg. MD (Sept. 1984). 240-263.
8. Federal Criteria for Information Technology Security. USA National Institute of Standards and Technology & USA National Security Agency.
9. Florae W. A. 1992. Software Quality Measurement: A Framework for Counting Problems and Defects. CMU/SEI-92-TR-22, Software Engineering Institute, Pittsburgh, PA. (Sept.).
10. Lampson, B. W. 1973. A note on the confinement problem, Comm. ACM 16.10 (October), 613-615.
11. Leveson N. and Turner С. S. 1992. An investigation of the Therac-25 accidents. UCI TR92-108, Inf. and Comp. Sci. Dept, ofCal.-lrvinc. Irvinc, CA.
12. Linde R. R. 1975. Operating system penetration. AFIPS national computer Conference, 361—368.
13. McDermott J.P. 1988. A technique for removing fin important class of Trojan horses from high order languages, Proc.11th National Computer Security Conference NBS/NCSC, Gaithersburg, MD (October.). 114-117.
14. Pfleeger С. Р. 1989. Security in Computing. Prentice Hall, Engle-wood Cliffs, NJ.
15. Schoch J. F. and Hupp J. A. 1982. The “worm” programs-early experience with a distributed computation. Comm. ACM.25.3 (March) 172-180.
16. Sullivan M.R. and Chillarege R. 1992. A comparison of software defects in database management systems and operating systems. Proc.22nd Int. Sump. on Fault-Tolerant Computer Systems (FTCS-22), Boston, MA IEEE CS Press.
17. Weiss D. M. and Basili V. R. 1985. Evaluating software development by analysis of changes: some data from the Software Engineering Laboratory. IEEE Trans. Software Engineering SE-11,2 (February), 157-168.’
18. Use of A Taxonomy of Security Faults. COAST Laboratory, Purdue University, Technical Report TR-96-051.
19. Д. Зегжда, А. Мешков. П. Семьяпов. Д. Шведов. Как противостоять вирусной атаке. BHV — СПб, 1995. 318с.
20. Теория и практика обеспечения информационной безопасности /Под ред. П. Д. Зегжда. M.: изд-во Агентства «Яхтсмен», 1996.
21. Атака через Internet /Под ред. П. Д. Зегжда С-Пб. Мир и семья. 1997.
Приложение I
Ранжированные функциональные требования «Федеральных критериев безопасности информационных технологий»
Данное приложение представляет собой ранжированный перечень функциональных требований, содержащийся в соответствующем разделе «Федеральных критериев», отражает только принципиальную суть требований и не претендует на перевод стандарта как; руководящего документа.
Описание требований следует приведенным в разделе 2.8 требованиям в порядке возрастания уровня обеспечиваемой защиты. Описание каждого раздела требований начинается с его краткого описания и обзора Предусмотренных уровней ранжирования; идентификаторы уровней сохранены в том виде, в каком они присутствуют в первоисточнике. Описание требований на каждом уровне приводится в виде дополнений и изменений по сравнению с предыдущим уровнем.
1. Идентификация и аутентификация
Идентификация и аутентификация принадлежат к основным компонентам политики безопасности. Отсутствие или низкая надежность процедур идентификации и/или аутентификации не позволяет противостоять атакам неуполномоченных субъектов путем предотвращения их регистрации в системе и отказа в получении доступа к ее ресурсам. Надежность механизма идет идентификации/аутентификации напрямую влияет на уровень безопасности всей системы в целом. При необходимости эти процедуры могут быть усилены совместным применением нескольких механизмов идентификации и аутентификации.
Требования идентификации и аутентификации ранжируются на основании уровня предоставляемых возможностей. Уровень IA-1 включает только аутентификацию пользователей и предназначен для простейших систем, тина систем контроля доступа в помещения. В которых кроме идентификации и аутентификации реализована только функция pегистрации входа. На уровне IA-2 предполагается наличие специальных атрибутов (признаков), идентифицирующих конкретного субъекта и позволяющих выполнить его авторизацию (предоставить ему соответствующие права для работы в системе). Этот уровень наиболее широко используется в операционных системах, в которых существуют атрибуты, определяющие степень привилегированности субъектов и уровень конфиденциальности объектов. Данные возможности расширяются на уровне IA-3 путем регламентации принципов обработки результатов аутентификации, а также требованиями к хранению, защите и предоставлению информации о результатах идентификации и аутентификации пользователей. Этот уровень используется в системах с четко определенной политикой управления доступом. На уровне IA-4 происходит дальнейшее расширение требований, заключающееся в предоставлении возможностей установки специальных механизмов идентификации и аутентификации и их назначения для индивидуальною пользователя и/или группы пользователей. На уровне IA-5 требуется реализация Нескольких независимых механизмов аутентификации пользователей.
• Уровень IA-1. Минимальная идентификация и аутентификация
1. ТСВ должно обеспечивать возможность идентификации каждого пользователя до начала выполнения им любых действий. ТСВ должно устанавливать индивидуальные полномочия пользователя в соответствии с его уникальным идентификатором. ТСВ должно обеспечивать возможность установления соответствия каждого регистрируемого в системе события с идентификатором инициировавшего его пользователя.
2. ТСВ должно использовать механизм аутентификации но паролю для проверки подлинности соответствия пользователя и его идентификатора.
3. ТСВ должно обеспечивать защиту данных, используемых для идентификации и аутентификации, с целью предотвращения доступа к ним неуполномоченных пользователей.
• Уровень IA-2. Идентификация, аутентификация и авторизация
1. Без изменений.
2. Изменение. Используемые для аутентификации данные должны включать информацию, необходимую как для проверки подлинности пользователя (например, пароль), так и для реализации политики безопасности (атрибуты пользователей, имена групп и ролей, уровни привилегированности субъектов и конфиденциальности объектов, временные интервалы и т. д.). Эти данные должны использоваться ТСВ для контроля действий пользователя в соответствии с действующей в системе политикой безопасности.
3. Без изменений.
• Уровень IA-3. Идентификация и аутентификация с контролем исключительных ситуаций
1. Без изменений.
2. Без изменений.
3. Дополнение. ТСВ должно обеспечивать выполнение процедуры аутентификации вне зависимое от результата проведения процедуры идентификации (например, требовать пароль даже в случае ввода несуществующего имени пользователя). ТСВ должно прекращать выполнение процедуры входа в систему в случае последовательного неудачного проведения идентификации и/или аутентификации пользователя заданное администратором число раз. В этом случае ТСВ должно оповестить администратора, зафиксировать данное событие в системном журнале и приостановить дальнейшее выполнение процедуры входа в систему на время, определенное администратором, или отказать пользователям в доступе вообще.
4. ТСВ должно обеспечивать хранение, защиту и предоставление информации о статусе и атрибутах всех активных пользователей, зарегистрированных в системе, и о бюджетах всех пользователей, существующих в системе.
• Уровень IA-4. Назначение процедур идентификации и аутентификации
1. Дополнение. ТСВ должно обеспечивать возможность идентификации каждого привилегированного субъекта.
2. Дополнение. ТСВ должно обеспечивать возможность внедрения новых механизмов аутентификации (например, на основе электронных карт или биометрических характеристик), дополняющих уже существующие. ТСВ должно обеспечивать возможность назначения различных механизмов аутентификации каждому пользователю в зависимости от его атрибутов.
3. Без изменений.
4. Без изменений.
• Уровень IA-5. Комбинированное применение независимых механизмов идентификации и аутентификации
1. Без изменений.
2. Дополнение. К каждому пользователю должны применяться два или более независимых механизма аутентификации. Аутентификация считается успешной, если все назначенные пользователю механизмы аутентификации подтвердили подлинность его идентификатора. ТСВ должно обеспечивать возможность назначения пользователю механизмов аутентификации в соответствии с атрибутами политики безопасности.
3. Без изменений.
4. Без изменений.
2. Регистрация пользователя в системе
Управление регистрацией пользователя в системе позволяет соблюсти требования политики аудита с помощью учета места, времени, способа и режима подключения пользователя к системе. Кроме того, управление регистрацией обеспечивает гарантию того, что зарегистрированный пользователь будет нести ответственность за выполняемые действия.
Процесс регистрации пользователя в системе должен управляться и контролироваться ТСВ. Должны рыть четко определены условия, при которых возможно создание субъекта или субъектов, представляющих данного пользователя. Эти условия должны определяться на основании значений атрибутов пользователя, определяющих его статус, принадлежность к группе, возможные роли, степень полномочий, период разрешенного для работы времени, доступный ему сервис и ресурсы системы.
Требования к процедуре регистрации в системе ранжируются на основании обеспечиваемых возможностей защиты. Требования уровня SE-1 включают в себя только простейшие возможности по управлению регистрацией в системе в соответствии с принадлежностью пользователя к определенной группе или выполнения им конкретной роли, а также степени его привилегированности. Этот уровень может использоваться в большинстве систем, поддерживающих выделенную самостоятельную процедуру регистрации пользователя. Системы, не реализующие отдельно такой процедуры в явном виде, используют для этой цели механизмы идентификации и аутентификации (по сути, идентификация и аутентификация могут считаться начальными процедурами управления регистрацией пользователя в системе). Уровень SE-2 дополнен возможностями учета времени и места регистрации пользователя в системе. На уровне SE-3 у пользователя появляются возможности блокировать (приостанавливать) и возобновлять сеанс работы с системой.
• Уровень SE-1. Базовый механизм управления регистрацией пользователя в системе
1. Перед началом выполнения процедуры регистрации пользователя в системе (процедуры login) TCB должно соответствующим сообщением предупреждать пользователя о недопустимости попытки неавторизованного проникновения в систему и о возможных последствиях подобных действий.
2. Перед началом сеанса работы (до разрешения регистрации) TCB должно выполнить процедуры идентификации и аутентификации пользователя. Если в TCB предусмотрена поддержка одновременного подключения нескольких независимых сеансов работы пользователя, то должен быть реализован механизм контроля количества одновременных подключений, запрещающий превышение некоторого определенного числа.
3. TCB должно осуществлять регистрацию только соответствии с подтвержденными аутентификацией атрибутами пользователя. Условия предоставления доступа к системе определяются на основании атрибутов пользователя в рамках политики безопасности. Если эти условия не определены явным образом, используются условия, принятые по умолчанию (например, успешная аутентификация пользователя).
4. 4. TCB должно включать в себя защищенные механизмы, при помощи которых уполномоченный пользователь (администратор) может управлять атрибутами пользователей, используемыми при их регистрации в системе. Должны быть определены условия, при которых непривилегированный пользователь может ознакомиться с собственными атрибутами, но не изменить их.
5. После успешной регистрации пользователя в системе TCB должно предоставлять ему следующую информацию (без возможности ее модификации):
· место, время, режим, терминал или порт последней успешной регистрации пользователя;
· количество неуспешных попыток регистрации с использованием ею идентификатора, зафиксированное между последним и текущим сеансом работы.
6. TCB должно обеспечивать блокирование (приостановку) или прерывание и завершение сеанса работы пользователя по истечению устанавливаемого администратором интервала отсутствия активности со стороны пользователя.
• Уровень SE-2. Управление регистрацией в системе с учетом времени и места подключения
1. Без изменений.
2. Без изменений.
3. Дополнение. ТСВ должно реализовывать механизм разрешения/запрещения регистрации в системе на основании контроля допустимого периода времени регистрации. Условия контроля периода времени должны быть определены для времени суток, дней недели и отдельных календарных дат. ТСВ должно реализовывать механизм разрешения/запрещения регистрации в системе па основании контроля местоположения пользователя (используемых терминалов или портов). При необходимости должны быть также определены условия удаленного подключения пользователей по каналам связи.
4. Без изменений.
5. Без изменений.
6. Без изменений.
• Уровень SE-3. Блокировка и восстановление сеанса работы пользователя
1. Без изменений.
2. Без изменений.
3. Без изменений.
4. Без изменений.
5. Без изменений.
6. Дополнение. ТСВ должно поддерживать механизм блокировки и возобновления сеанса работы пользователя по его команде или по истечению заданного администратором интервала отсутствия активности со стороны пользователя. Этот механизм должен обеспечивать:
· очистку экрана терминала для предотвращения возможности считывания с него информации и блокировку клавиатуры и других средств ввода информации;
· запрет па любые действия в системе с использованием заблокированных средств ввода-вывода информации на время приостановки сеанса пользователя;
· выполнение процедур идентификации и аутентификации пользователя перед возобновлением сеанса работы.
3. Обеспечение прямого взаимодействия с ТСВ
Функциональные требования, обеспечивающие прямое взаимодействие с ТСВ, ранжируются в зависимости от допустимой сферы применения и обеспечиваемых возможностей защиты. Минимальный уровень tp-i предполагает наличие гарантированного канала взаимодействия пользователя с ТСВ, используемого для выполнения процедуры регистрации в системе. На уровне ТР-2 прямое взаимодействие с ТСВ обеспечивается не только для процесса регистрации, но и для других процессов, требующих обеспечения гарантированно достоверного канала взаимодействия между пользователем, выполняющим действия, критичные с точки зрения безопасности (например, администрирование атрибутов безопасности), и ТСВ. На уровне ТР-3 обеспечивается гарантирование достоверный канал взаимодействия между пользователем и доверенными приложениями, позволяющими ему работать с критичной информацией.
• Уровень ТР-1. Обеспечение прямого взаимодействия с ТСВ для процедуры регистрации в системе
ТСВ должно обеспечивать гарантированно достоверный канал взаимодействия с пользователем в ходе процесса его идентификации и аутентификации во время регистрации в системе. Инициация прямого взаимодействия с ТСВ должна осуществляться только со стороны пользователя.
• Уровень ТР-2. Обеспечение прямого взаимодействия пользователя с ТСВ
Дополнение. ТСВ должно обеспечивать гарантированно достоверный канал для всех видов взаимодействий с пользователем (регистрация в системе, изменение атрибутов защиты и т.д.). Данный канал должен предусматривать возможность инициации как со стороны пользователя, так н ТСВ, и должен быть изолирован от других аналогичных каналов и обладать уникальными характеристиками.
• Уровень ТР-3. Обеспечение прямого взаимодействия пользователя с доверенными приложениями
Дополнение. ТСВ должно обеспечивать гарантированно достоверный канал прямого взаимодействия пользователя с доверенными приложениями (например, для ввода или вывода критичной с точки зрения безопасности информации).
4. Регистрация и учет событий в системе (аудит)
Требования к регистрации и учету событий ранжируются в зависимости от предоставляемых возможностей отбора подлежащих регистрации событий, мощности средств анализа журнала событий и степени мониторинга действий пользователя. Требования к аудиту подразделяются на четыре группы:
· защита и управление доступом к системному журналу событий;
· определение множества подлежащих регистрации событий:
· фиксация и хранение зарегистрированных Событий в журнале;
· анализ журнала событий и формирование отчетов.
Уровень AD-1 включает минимальные требования к аудиту, которым должны следовать все системы в той мере. в какой они реализуют соответствующие функции защиты. На уровне AD-2 эти требования усиливаются как за счет расширения множества типов регистрируемых событий, так и за счет добавления новых функций по управлению процессом регистрации и учета. На уровне AD-3 появляются требования к наличию доверенных средств аудита, предоставляющих возможности выборочного анализа определенных типов событий, упрощающих взаимодействие с оператором за счет использования графического представления данных и т.п. Уровень AD-4 характеризуется введением требования выявления критичных с точки зрения безопасности событий и объявления тревоги в случае их обнаружения. На уровне AD-5 требуется обеспечить такой же контроль в режиме реального времени (осуществлять в режиме реального времени обнаружение попыток нарушений безопасности).
• Уровень AD-1. Минимальный аудит
1. ТСВ должно обеспечивать возможность создания, хранения, ведения журнала аудита, содержащего регистрацию обращений к защищенным объектам. ТСВ должно обеспечивать защиту журнала от несанкционированного доступа, изменения или уничтожения. ТСВ должно предоставлять доступ к журналу только уполномоченным пользователям.
2. ТСВ должно обеспечивать регистрацию в журнале аудита следующих типов событий:
· использование средств идентификации и аутентификации;
· создание и удаление объектов;
· доступ к объектам, помещение объектов в доступную пользователю область, запуск программ;
· действия, предпринятые операторами и администраторами, ответственными за безопасность.
Для поддержки в системе политики обеспечения работоспособности и контроля за распределением ресурсов должны регистрироваться попытки несанкционированных запросов на выделение ресурсов и попытки получения доступа к ресурсам, предоставленным другим субъектам.
При поддержке в системе нормативного управления доступом ТСВ должно иметь возможность осуществлять регистрацию и учет изменений меток, классифицирующих уровень информации. Если нормативное управление доступом применяется для контроля потоков информации между субъектами, ТСВ должно иметь возможность регистрировать в журнале аудита события, которые потенциально могут использоваться для организации скрытых каналов передачи информации.
3. Для каждого регистрируемого события в журнал аудита заносятся:
· дата, время и тип события;
· идентификатор пользователя, инициировавшего событие;
· результат выполнения действия, соответствующего событию (успешное завершение или отказ).
При запросах на доступ к объектам или их удаление должны также регистрироваться имя и атрибуты объекта.
4. Администратор должен иметь возможность выбора регистрируемых событий и действий для каждого пользователя или объекта на основании соответствующих атрибутов политики безопасности.
• Уровень AD-2. Базовые требования к аудиту
1. Без изменений.
2. Изменение. ТСВ должно иметь возможность регистрировать следующие типы событий:
· использование механизмов идентификации, аутентификации и регистрации пользователя в системе;
· события, связанные с управлением доступом, относящиеся к определенному пользователю, субъекту, объекту или их атрибутам политики безопасности;
· создание, удаление субъектов и объектов, осуществление доступа, передача и отзыв прав доступа, изменение атрибутов политики безопасности, назначение и отзыв привилегий;
· действия, выполняемые операторами и администраторами, ответственными за безопасность, привилегированные операции, такие, как модификация элементов ТСВ, настройка ТСВ, изменение параметров ТСВ и системных привилегий, изменение атрибутов пользователей, изменение состава и типов регистрируемых в журнале аудита событий.
Должен быть определен минимальный неизменяемый состав регистрируемых событий и их параметров. ТСВ должно содержать средства защиты и управления множеством регистрируемых событий и их параметров и предоставлять доступ к ним только администратору.
3. Без изменений.
4. Дополнение. В ТСВ должны присутствовать защищенные средства запуска и остановки процесса аудита. Доступ к этим средствам, равно как и к средствам просмотра журнала аудита, должен быть разрешен только администратору.
ТСВ также должно включать средства управления аудитом, доступные только для администратора которые позволяют осуществлять:
· создание и удаление журнала аудита, контроль и изменение его размеров:
· форматирование и упаковку записей журнала аудита:
· обеспечение целостности журнала аудита при сбоях и отказах системы.
• Уровень AD-3. Развитые средства аудита
1. Без изменений.
2. Без изменений.
3. Без изменений.
4. Дополнение. В ТСВ должны присутствовать специально разработанные средства контроля целостности журнала аудита, а также средства контроля целостности заданного множества регистрируемых событий.
5. Средства просмотра журнала аудита должны предоставлять авторизованному пользователю возможность ознакомления с данными аудита и их проверки. Данные средства должны быть защищены от несанкционированного доступа.
ТСВ также должно иметь средства обработки журнала аудита, позволяющие осуществлять выборочный анализ:
· действий одного или нескольких пользователей:
· действий над одним или несколькими объектами или ресурсами:
· всех или подмножества исключительных ситуаций:
· действий, ассоциированных с заданными атрибутами политики безопасности субъектов и объектов.
Средства просмотра журнала аудита должны предусматривать возможность работы параллельно со штатным функционированием системы.
• Уровень AD-4. Обнаружение попыток нарушения безопасности
1. Без изменений.
2. Дополнение. ТСВ должно содержать средства мониторинга событий, возникновение которых может означать угрозу нарушения безопасности. Эти средства должны незамедлительно оповещать администратора системы и останавливать (прекращать) выполнение вызвавшего это событие процесса или всей системы.
3. Без изменений.
4. Без изменений.
5. Без изменений.
• Уровень AD-5. Выявление попыток нарушения безопасности в режиме реального времени
1. Без изменений.
2. Без изменений.
3. Без изменений.
4. Без изменений.
5. Дополнение. ТСВ должно обеспечивать возможность регистрации событий и выявления попыток нарушения безопасности в режиме реального времени и оповещать о них администратора. Эта возможность должна реализовываться специальным механизмом мониторинга событий, критичных с точки зрения политики безопасности.
5. Политика управления доступом (произвольное и нормативное управление доступом)
Требования к реализации политики произвольного управления доступом могут быть ранжированы в зависимости от области применения политики (ко всем субъектам и объектам системы, к выбранным подмножествам субъектов и объектов, в зависимости от атрибутов безопасности субъектов и объектов) и предоставляемых средств управления доступом (возможность управлять передачей прав доступа, возможность организации контроля доступа к объектам пользователей только с их разрешения). Кроме того, эти требования можно ранжировать в зависимости от уровня абстракции, на котором рассматриваются субъекты (пользователь, группа, роль) и объекты (область памяти, файл, запись в файле).
Для ранжирования требований нормативного управления доступом могут использоваться те же самые критерии, однако описание уровня рассмотрения субъектов и объектов в этом случае должно производиться более точно. Поскольку нормативное управление доступом основано на контроле информационных потоков, должны контролироваться соответствующие атрибуты субъектов (например, состояние процесса) и объектов (размер, режим доступа и т. д.).
Требования к управлению доступом ранжированы по четырем уровням. На уровне АС-1 устанавливаются минимальные требования к реализации политики управления доступом и допускается осуществление управлением доступа только по отношению к некоторому подмножеству субъектов и объектов, а также ограниченные возможности управления атрибутами безопасности. На уровне АС-2 требования к политике безопасности расширяются в сторону возможности одновременного применения нескольких политик управления доступом и средств управления экспортом и импортом объектом. На уровне АС-3 управление доступом должно поддерживаться для всех субъектов и объектов. Если реализована политика нормативного управления доступом, она должна использовать все атрибуты безопасности объектов и субъектов. На данном уровне также требуется проводить назначение прав доступа к объектам на основании их типа. На следующем уровне АС-4 управление доступом расширяется путем добавления атрибутов времени и местоположения. Появляется возможность Задания прав пользователей в зависимости от их принадлежности к определенной группе или выполнения ими определенной роли. В дополнение к требованиям контроля создания и уничтожения объектов вводится контроль за ресурсами и наследованием атрибутов. Предполагается, что этот уровень будет использоваться в системах, где требуется точно определенное управление доступом.
• Уровень АС-1. Минимальное управление доступом
1. Задание множества атрибутов безопасности объектов и субъектов. ТСВ должно задавать и поддерживать атрибуты безопасности субъектов и объектов. Атрибуты субъекта должны включать индивидуальный и групповой идентификаторы пользователя, представленного этим субъектом. Атрибуты объекта должны включать набор возможных прав доступа к этому объекту (чтение, запись, выполнение).
2. Управление атрибутами безопасности объектов и субъектов. ТСВ должно определять правила назначения и изменения атрибутов безопасности субъектов и объектов и обеспечивать их безусловное выполнение. Эти правила должны быть основаны на следующих положениях:
· субъект может разрешать доступ к объекту для другого субъекта только в том случае, если он сам обладает этим правом доступа:
· пользователи должны иметь возможность устанавливать режим совместного использования объектов и управлять им на основе индивидуальных и групповых атрибутов субъектов:
· пользователи должны обладать средствами для контроля за процессом передачи прав доступа и иметь возможность ограничивать его.
Если для разных подмножеств субъектов и объектов определены различные правила управления атрибутами безопасности, то их реализация должна быть согласованной и не противоречить политике безопасности.
3. Управление доступом субъектов к объектам. ТСВ должно определять правила назначения полномочии с целью управления доступом субъектов к объектам и обеспечивать их соблюдение. Эти правила должны быть основаны на атрибутах субъектов и объектов и обеспечивать защиту объектов от несанкционированного доступа. Правила назначения полномочий должны охватывать четко определенное подмножество субъектов и объектов, а также принадлежащих им атрибутов безопасности. Должна быть обеспечена возможность применения различных правил назначения полномочий для различных групп субъектов и объектов, в этом случае реализация этих правил должна быть согласованной и не противоречить политике безопасности.
4. Контроль за созданием и уничтожением объектов и субъектов. ТСВ должно контролировав создание и уничтожение субъектов и объектов, а также повторное использование объектов. Все полномочия на доступ к объекту должны быть отозваны перед его уничтожением и предоставлением занимаемых им ресурсов в распоряжение системы. Вся содержащаяся в нем информация, в том числе и зашифрованная, должна быть уничтожена.
5. Инкапсуляция объектов. Если в ТСВ поддерживается механизм инкапсуляции объектов, он должен обеспечивать:
· авторизацию доступа к инкапсулированным объектам:
· возможность создания пользователем инкапсулированных объектов и подсистем:
· средства доступа к инкапсулированным объектам.
• Уровень АС-2. Базовые механизмы управления доступом
1. Дополнение. Если одновременно поддерживается несколько политик управления доступом, атрибуты безопасное ги субъектов и объектов для каждой политики должны быть определены отдельно. Атрибуты субъектов и объектов должны точно отражать уровень их конфиденциальности и целостности.
2. Дополнение. Правила управления атрибутами безопасности субъектов и объектов должны регламентировать назначение атрибутов в ходе импорта и экспорта объектов, в том числе управлять импортом в системе неклассифицированной информации, не имеющей атрибутов безопасности, и экспортом из системы информации, обладающей атрибутами безопасности.
3. Дополнение. Если одновременно поддерживается несколько политик управления доступом, правила назначения полномочий доступа должны быть определены отдельно для каждой политики. ТСВ должно обеспечивать корректность совместного применения политик безопасности, в том числе совместное применение правил авторизации каждой политики.
4. Без изменений.
5. Без изменений.
• Уровень АС-3. Расширенное управления доступом
1. Дополнение. ТСВ должно незамедлительно сообщать пользователю о любых изменениях атрибутов ассоциированных с ним субъектов, повлекших за собой изменение уровня привилегированности пользователя. Пользователю должна быть предоставлена возможность запросить у ТСВ текущие значения атрибутов безопасности ассоциированных с ним субъектов. ТСВ должно поддерживать назначение атрибутов безопасности всем подключенным к системе физическим устройствам (например, максимальные и минимальные уровни конфиденциальности). Эти атрибуты должны использоваться ТСВ для отражения особенностей функционирования данных устройств, обусловленных их физическими параметрами.
2. Без изменений.
3. Изменение. Правила назначения полномочий доступа должны быть определены для всех субъектов и объектов, которые прямо или косвенно доступны субъектам. Если применяется нормативное управление доступом, то правила назначения полномочий доступа должны учитывать все атрибуты субъектов и объектов.
4. Без изменений.
5. Без изменений.
• Уровень АС-4. Точно определенная политика управления доступом
1. Дополнение. В состав атрибутов безопасности субъектов должны входить показатели времени и местоположения, позволяющие дополнительно аутентифицировать ассоциированного с данным субъектом пользователя.
2. Дополнение. Правила управления атрибутами безопасности субъектов и объектов должны обеспечивать задание для каждого объекта списка индивидуальных субъектов и групп субъектов с указанием их прав доступа к данному объекту. Кроме того, правила управления атрибутами безопасности субъектов и объектов должны обеспечивать задание для каждого объекта списка индивидуальных субъектов и групп субъектов, не имеющих прав доступа к данному объекту. Эти правила также должны обеспечивать возможность управления атрибутами в зависимости от времени и места — предоставление или отзыв прав доступа могут быть осуществлены в определенный момент времени и продлиться заданный период, а также зависеть от местоположения объектов и субъектов.
3. Дополнение. Правила назначения полномочий доступа должны включать возможность использования атрибутов времени и места осуществления доступа.
4. Изменение. ТСВ должно определять и поддерживать правила контроля за созданием и уничтожением субъектов и объектов, позволяющие указать для каждого субъекта и объекта:
· полномочия, требуемые для их создания и уничтожения;
· процедуру повторного использования объекта;
· ресурсы, требуемые для их создания и размещения;
· устанавливаемые по умолчанию значения атрибутов созданных субъектов и объектов и, если требуется, правила наследования атрибутов.
Правила создания и уничтожения субъектов и объектов должны определяться на основании их типов. Если для различных типов субъектов и объектов определены разные правила их создания и уничтожения, то должно быть показано, что их совокупность реализует политику безопасное ги, принятую в системе. Если одновременно используется несколько политик безопасности, правила создания и уничтожения субъектов и объектов должны быть определены для каждой политики.
5. Без изменений.
6. Контроль скрытых каналов
Для осуществления контроля за скрытыми каналами требуется присутствие в ТСВ программных, аппаратных и специальных средств, позволяющих обнаруживать скрытые каналы и ограничивать возможности их использования путем их полной ликвидации или минимизации пропускной способности. Ранжирование данной группы требований проводится на основе типов контролируемых скрытых каналов и предоставляемых возможностей контроля (аудит, минимизация пропускной способности, ликвидация).
Скрытые каналы в зависимости от способа кодирования информации подразделяются на два типа: с использованием памяти и с использованием времени. В первом случае для кодирования передаваемой информации используется область памяти (например, установление характерных признаков в имени и атрибутах файла или зарезервированные поля в заголовке сетевого пакета). Во втором случае информация кодируется определенной последовательностью и длительностью событий, происходящих в системе (например, с помощью модуляции интервалов обращения к устройствам, введения задержек между приемом и посылкой сетевых пакетов и т.д.).
Уровень ССН-1 затрагивает только скрытые каналы, использующие память, и ограничивается контролем их использования. На уровне ССН-2 добавляются требования минимизации пропускной способности и исключения возможностей использования скрытых каналов для штатного режима эксплуатации» системы. Уровень ССН-3 требует полного подавления всех типов скрытых каналов.
• Уровень ССН-1. Контроль скрытых каналов, использующих память
1. ТСВ и привилегированные приложения должны содержать функции контроля использования скрытых каналов, использующих память. Эти функции должны позволять идентифицировать источник и приемник скрытою обмена информацией и способ использования скрытого канала.
2. Функции ТСВ и привилегированных приложений, осуществляющие контроль скрытых каналов, должны быть определены для каждого скрытого канала и присутствовать в типовой конфигурации системы. Если для некоторых скрытых каналов функции контроля отсутствуют, должно быть проведено доказательство невозможности их использования для нарушения безопасности.
• Уровень ССН-2. Контроль и ограничение пропускной способности скрытых каналов, использующих память
1. Дополнение. Должно обеспечиваться ограничение пропускной способности или полное подавление скрытых каналов, использующих память. Пропускная способность каждого скрытого канала должна контролироваться администратором.
2. Дополнение. Функции ТСВ и привилегированных положений, обеспечивающие ограничение пропускной способности или полное подавление скрытых каналов, должны присутствовать в типовой конфигурации системы. Если для некоторых скрытых каналов функции ограничения пропускной способности или полного подавления отсутствуют, должно быть проведено доказательство невозможности их использования для нарушения безопасности.
• Уровень ССН-3. Контроль и ограничение пропускной способности скрытых каналов, использующих время
1. Без изменений.
2. Дополнение. Функции контроля, ограничения пропускной способности и подавления скрытых каналов должны в полной мере распространяться и на скрытые каналы, использующие время.
7. Контроль за распределением ресурсов
Данные требования являются частью политики обеспечения работоспособности системы и позволяют контролировать использование ресурсов системы. Ранжирование проводится по отношению к множеству управляемых ресурсов (т.е. подмножества ресурсов с ограниченным распределением) и функциональным возможностям средств управления.
Уровень AR-1 определяет базовые требования к контролю за предоставлением ресурсов в терминах ограниченного подмножества системных ресурсов, субъектов и объектов. Уровень AR-2 расширяет область применения средств контроля за предоставлением ресурсов до множества всех системных ресурсов с одновременным введением контроля за попытками монопольного захвата ресурсов и их доступностью для всех субъектов. На уровне AR-3 к этим требованиям добавляется управление распределением ресурсов на основании приоритета субъекта и введение фиксированных квантов, которыми распределяются ресурсы.
• Уровень AR-1. Ограничение при распределении ресурсов
ТСВ должно обеспечивать возможность ограничения множества субъектов и объектов, доступных пользователю одновременно. ТСВ должно контролировать распределение определенного подмножества системных ресурсов таким образом, чтобы ни один пользователь не мог нарушить работу другого пользователя путем захвата такого количества ресурсов системы, при котором другие пользователи не могут осуществлять доступ к объектам и субъектам. Для всех субъектов, объектов и ресурсов должны быть определены ограничения на время и количество использования, а для ресурсов — атрибуты, обозначающие их количество.
• Уровень AR-2. Полный контроль за распределением ресурсов
Дополнение. ТСВ должно контролировать распределение системных ресурсов таким образом, чтобы ни один пользователь не мог сделать любой системный ресурс недоступным для других пользователей, или ограничить возможности ТСВ по обслуживанию других пользователей путем захвата ресурсов или осуществления манипуляций с ТСВ.
• Уровень AR-3. Распределение ресурсов на основании приоритетов
Дополнение. ТСВ должно обеспечивать возможность распределения ресурсов на основании специально выделенных атрибутов, поставленных в соответствие каждому субъекту. ТСВ должно осуществлять распределение ресурсов в первую очередь субъектам, обладающим более высоким приоритетом. Все ресурсы должны выделяться блоками определенного размера (квантами).
8. Политика управления безопасностью
Ранжирование требований к средствам управления безопасностью основано на множестве управляемых параметров и уровне предоставляемых возможностей. Уровень SM-1 содержит минимальные требования по управлению безопасностью. Уровень SM-2 является базовым и предназначен для применения в большинстве систем. На уровне SM-3 надежность механизма управления обеспечивается за счет разделения ролей администратора и оператора системы и применения более широкого набора средств управления безопасностью. На уровне SM-4 требуется наличие доверенных средств управления безопасностью и введение контроля за администрированием системы.
• Уровень SM-1. Минимальное управление безопасностью
1. ТСВ должно содержать доверенные средства установки и настройки собственных конфигурационных параметров и инициализации критических внутренних структур данных перед заданием атрибутов безопасности пользователей и администраторов.
2. ТСВ должно поддерживать доверенные средства просмотра и редактирования параметров политики безопасности.
3. ТСВ должно включать доверенные средства просмотра, редактирования и удаления параметров регистрации пользователей и их бюджетов. Эти параметры должны включать уникальный идентификатор пользователя, его имя и служебное положение. Данные средства должны позволять администратору приостанавливать и возобновлять действие идентификаторов пользователей и их бюджетов.
4. ТСВ должно содержать доверенные средства контроля функционирования системы и состояния системных ресурсов. Эти средства должны обеспечивать подключение и отключение внешних устройств, съемных носителей информации, резервное копирование и восстановление объектов, эксплуатацию и тестирование программных и аппаратных компонентов ТСВ, запуск и остановку системы.
5. Средства управления безопасностью должны быть доступны только для администратора системы.
• Уровень SM-2. Базовые механизмы управления безопасностью
1. Дополнение. Средства управления безопасностью должны учитывать различие между режимами штатного функционирования и технического обслуживания системы и поддерживать управление безопасностью и в том и в другом режиме. Режим технического обслуживания системы должен позволять проводить восстановление после сбоев и запуск системы.
2. Дополнение. В состав параметров политики безопасности должны входить параметры идентификации, аутентификации, регистрации в системе и параметры управления доступом как для системы в целом, так и для каждого отдельного пользователя. ТСВ должно позволять администратору определять политику идентификации и аутентификации для всех пользователей системы (период смены паролей, их длину и сложность). Средства управления параметрами политики безопасности должны позволять ограничивать:
· максимальный период отсутствия активности со стороны пользователя;
· максимальное время работы пользователя в системе:
· максимальное число последовательно осуществленных безуспешных попыток регистрации в системе.
Если в системе обеспечивается поддержка политики обеспечения работоспособности, ТСВ должно поддерживать механизм управления доступностью системных ресурсов посредством введения квот и ограничений на объем потребляемых ресурсов.
3. Дополнение. ТСВ должно содержать средства для однозначной идентификации каждого параметра политики безопасности. Кроме того, должна быть предусмотрена возможность получения списка атрибутов безопасности для каждого пользователя и списка пользователей, ассоциированных с каждым атрибутом безопасности. Должна обеспечиваться возможность управления атрибутами политики безопасности субъектов, включая привилегии, атрибуты произвольного и нормативного управления доступом, а также централизованного контроля, назначения и снятия атрибутов политики безопасности.
4. Без изменений.
5. Без изменений.
• Уровень SM-3. Управление безопасностью в соответствии с политикой безопасности
1. Дополнение. Режим технического обслуживания системы должен включать средства инициализации параметров идентификации, аутентификации, регистрации в системе и назначения полномочий администратора системы.
2. Дополнение. В случае совместного использования нескольких методов аутентификации ТСВ должно предоставлять администратору возможность определять методы аутентификации пользователей в зависимости от соответствующих атрибутов политики безопасности. Если ТСВ поддерживает одновременно несколько сеансов для одного пользователя, администратор должен иметь возможность ограничить число одновременных регистрации для каждого пользователя в зависимости от его атрибутов безопасности. ТСВ должно позволять администратору ограничивать регистрацию для пользователя с определенным идентификатором или с определенного терминала после заданного количества неуспешных попыток регистрации с помощью этого идентификатора или терминала.
3. Дополнение. ТСВ должно автоматически приостанавливать полномочия пользователей в случае, если они не использовались в течение заданного администратором периода времени. ТСВ также должно обеспечивать автоматическое возобновление приостановленных полномочий по истечении указанного администратором времени.
4. Дополнение. ТСВ должно поддерживать разделение функций оператора и администратора. Функции оператора должны ограничиваться управлением внешними устройствами.
5. Без изменений.
• Уровень SM-4. Расширенное управление безопасностью
1. Без изменений.
2. Без изменений.
3. Дополнение. ТСВ должно содержать доверенные средства администрирования системы, осуществляющие контроль:
· конфигурации системы и регистрации пользователей;
· корректности и инсталляции системы;
· отсутствия в ТСВ посторонних программ и данных.
ТСВ должно включать средства контроля безопасности начального состояния ТСВ после инициализации или восстановления.
ТСВ должно включать средства контроля соответствия между пользователями, субъектами, представляющими их в системе, и назначенным им атрибутом безопасности.
4. Дополнение. Средства контроля функционирования системы должны поддерживать разделение ролей администратора безопасности и аудитора, контролирующего администрирование. ТСВ должно выполнять заданные администратором действия только после их регистрации в журнале аудита. Не влияющие на безопасность системы действия администратора должны быть строго ограничены для обеспечения эффективного управления безопасностью.
5. Без изменений.
9. Мониторинг взаимодействий
Ранжирование требований к мониторингу взаимодействий производится по отношению к области применения мониторинга и степени детализации взаимодействий. На уровне RM-1 мониторинг взаимодействий ограничивается только заданными подмножествами субъектов и объектов, обращения к которым контролируются политикой управления доступом. На уровне RM-2 мониторинг взаимодействий должен применяться для всех субъектов и объектов. Уровень RM-3 увеличивает степень легализации с помощью мониторинга атрибутов безопасности и статуса объектов, субъектов и ресурсов Уровень RM-4, предназначенный для использования в системах, где действуют привилегированные процессы, предусматривает поддержку модели мониторинга взаимодействий привилегированных процессов.
• Уровень RM-1. Мониторинг взаимодействий для заданных подмножеств субъектов и объектов
1. ТСВ должно осуществлять мониторинг всех взаимодействий, в которых участвуют субъекты, объект и ресурсы, включенные в спецификацию ТСВ Мониторинг должен обеспечивать контроль взаимодействий в соответствии с политикой безопасности
2. Мониторинг взаимодействий должен осуществляться для заданного подмножества субъектов, объектов и ресурсов, находящихся под контролем политики безопасности системы, а также для обращений к их атрибутам безопасности (правам доступа, уровням конфиденциальности, ролям, квотам и т.д. ).
3. Мониторинг взаимодействий привилегированных субъектов должен осуществляться в соответствии с атрибутами безопасности этих субъектов
• Уровень RM-2. Мониторинг взаимодействий для всех субъектов и объектов
1. Без изменений.
2. Дополнение. Мониторинг взаимодействий должен осуществляться для всех объектов, субъектов и ресурсов и их атрибутов безопасности
3. Без изменений.
• Уровень RM-3. Мониторинг взаимодействий и контроль атрибутов безопасности
1. Без изменений.
1. Дополнение. Требования мониторинга взаимодействий обращений к атрибутам субъектов, объектов и ресурсов распространяются на полное множество атрибутов (состояние, размер, режим использования).
2. Без изменений.
• Уровень RM-4 Мониторинг взаимодействий привилегированных субъектов
1. Без изменений.
2. Без изменении.
3. Дополнение. Мониторинг взаимодействий привилегированных субъектов должен осуществляться на основе модели безопасности и мониторинга, определенней для этих субъектов.
10. Логическая защита ТСВ
Ранжирование требований логической защиты ТСВ проводится на основе их возможностей по обеспечению безопасности ТСВ. Уровень LP-1 содержит основные требования к изоляции ТСВ. На уровне LP-2 эти требования расширяются за счет введения средств контроля целостности структур данных ТСВ и исключения влияния на состояние ТСВ со стороны непривилегированных пользователей. Эти требования призваны сделать невозможным применение злоумышленником средств проникновения в ТСВ. На уровне LP-3 вводится требование синхронности контроля целостности ТСВ.
• Уровень LP-1. Базовые средства изоляции ТСВ
ТСВ должно функционировать внутри собственного домена, изолированного от; остальных компонентов системы. Изоляция домена ТСВ должна обеспечивать защиту от внешних воздействий, модификации программ или данных ТСВ.
1. Изоляция компонентов ТСВ должна включать:
· изоляцию адресного пространства ТСВ от адресного пространства непривилегированных субъектов таким образом, чтобы они не могли получить доступ по чтению и записи к программам и данным ТСВ:
· взаимодействие между доменом ТСВ и остальными компонентами системы должно осуществляться таким образом, чтобы неконтролируемый обмен информацией с ТСВ был невозможен;
· параметры, передаваемые в ТСВ, должны контролироваться на допустимость их значений или принадлежность к адресному пространству ТСВ.
2. Для обеспечения надежности изоляции ТСВ права доступа к объектам, переданным в ТСВ в качестве параметров, должны проверяться на соответствие тре6yeмым, а обращения к объектам ТСВ со стороны средств, обеспечивающих изоляцию, контролироваться монитором пересылок.
• Уровень LP-2. Изоляция и контроль целостности ТСВ
1. Без изменений.
2. Дополнение. Средства защиты ТСВ также должны осуществляв контроль целостности структур данных ТСВ и предотвращать влияние на них со стороны непривилегированных пользователей.
3. Контроль целостности структур данных ТСВ с помощью вычисления функции-инварианта, определенной на множестве переменных, объектов и функций, должен осуществляться до и после любого обращения к ТСВ.
4. Для предотвращения влияния на ТСВ со стороны непривилегированных пользователей необходимо обеспечить, чтобы любое обращение пользователя к ТСВ не приводило к нарушениям в обработке запросов остальных пользователей.
• Уровень LP-3. Изоляция и синхронный контроль целостности ТСВ
1. Без изменений.
2. Без изменений.
3. Без изменений.
4. Дополнение. Защита ТСВ должна обеспечивать синхронность функций контроля целостности.
5. Синхронность функций контроля целостности означает, что действия, основанные на результатах проверки целостности, осуществляются непосредственно после завершения процесса проверки и между этими событиями состояние ТСВ измениться не может.
11. Физическая защита ТСВ
Ранжирование требований физической защиты ТСВ производится на основе обеспечиваемого уровня защиты, т. е. возможности предвидеть, обнаруживать и предотвращать атаки на систему на физическом уровне.
На уровне РР-1 от средств обеспечения физической защиты требуется применение административных мер и контроля среды функционирования. На уровне РР-2 выдвигается требование к устройствам распознавать попытки физического вмешательств в их работу. Уровень РР-3 требует наличия средств противодействия атакам на конфиденциальность и целостность системы, а также изменениям в среде функционирования.
• Уровень РР-1. Административные меры и контроль среды функционирования
1. Должны быть определены административные меры и параметры физическою контроля среды функционирования. необходимые для обеспечения защиты ТСВ.
2. Должны иметься и надлежащим образом применяйся средства и устройства, необходимые для осуществления физического контроля за компонентами ТСВ.
• Уровень РР-2. Обнаружение атак на физическом уровне
1. Без изменений.
2. Дополнение. Средства и устройства, осуществляющие физический контроль. должны обеспечивать однозначное обнаружение физического воздействия на ТСВ. Эти устройства должны быть надежны и устойчивы к непосредственному физическому воздействию.
• Уровень РР-3. Противодействие атакам на физическом уровне и неблагоприятным изменениям в среде функционирования
1. Без изменений.
2. Дополнение. Должны иметься средства противодействия атакам на физическом уровне, их характеристики должны соответствовать требованиям политики безопасности. Для обеспечения конфиденциальности эти устройства должны противостоять попыткам кражи и исследования компонентов ТСВ с помощью физического воздействия, подслушивания, перехвата и анализа излучений. Для обеспечения целостности эти устройства должны противодействовать несанкционированному изменению состава аппаратного обеспечения, нарушению ею функционирования, а также воздействиям на хранящуюся в системе информацию механическими или электромагнитными методами. Для обеспечения работоспособности системы эти устройства должны противодействовать возникновению ситуаций, затрудняющих обслуживание пользователей (вибрации, вода, огонь и другие формы физических воздействий).
12. Самоконтроль ТСВ
Требования самоконтроля ТСВ ранжируются на основе перечня контролируемых элементов (аппаратное, программное и специальное обеспечение) и возможностей механизмов проверки (периодичность, длительность, глубина проверки)
На уровне SC-1 представлены минимальные требования к самоконтролю ТСВ, предполагается, что их выполнения будет достаточно для большинства коммерческих приложений. Уровень SC-2 содержит расширенные требования, включающие в себя тестирование при включении питания, загрузке системы, а также управляемые оператором средства тестирования, применяемые для периодического контроля функционирования элементов ТСВ. На уровне SC-3 появляются требования к тестированию программных компонентов ТСВ. На уровне SC-4 требуется, чтобы тестирование осуществлялось регулярно па протяжении всею периода функционирования системы.
• Уровень SC-1. Минимальный самоконтроль
ТСВ должно включать аппаратные и/или программные средства периодического контроля целостности и корректности функционирования собственных аппаратных и специальных компонентов.
• Уровень SC-2. Базовые механизмы самоконтроля
Дополнение. В состав средств контроля должны входить: [тестирование при включении питания, тестирование в ходе загрузки системы и средства легирования, управляемые опера горем.
Тесты при включении питания должны осуществлять проверку всех аппаратных и специальных компонентов ТСВ, включая оперативную память, шины, соединения, разъемы, управляющие контроллеры, процессор, адаптеры дисковых накопителей и других устройств, коммуникационные порты, консоль и клавиатуру. Эти тесты также должны осуществлять проверку всех компонентов, используемых для выполнения гестов при загрузке системы, и тестов, управляемых оператором.
Тесты при загрузке системы должны включать в себя проверку компонентов центрального процессора (арифметические и логические устройства, математический сопроцессор, устройство декодирования инструкций, контроллер прерываний, кэш, буфер трансляции адресов, внутренние и внешние шины), а также системной шины, контроллеров оперативной памяти и устройств, используемых в ходе тестов, управляемых оператором, и при удаленном тестировании системы.
Выполняемые оператором тесты должны обеспечивать однократное или многократное тестирование компонентов ТСВ и системы в целом, регистрацию результатов тестирования и. в случае выявления неисправности, выполнять специальные процедуры локализации неисправностей и уведомлять оператора.
• Уровень SC-3. Тестирование программных средств
Дополнение. Должны иметься управляемые и конфигурируемые программные или специальные средства тестирования целостности и корректности программных компонентов ТСВ — программ, данных и носителей информации. Эти средства должны включать проверку контрольных сумм и другие механизмы контроля.
• Уровень SC-4. Регулярное тестирование программных средств
Дополнение. Тесты контроля целостности и корректности функционирования программных компонентов ТСВ должны выполняться при каждом изменении содержания или структурных компонентов, возникающих при сбоях и отказах, произошедших из-за действий непривилегированных субъектов.
13. Инициализация и восстановление ТСВ
Требования инициализации и восстановления безопасного состояния ТСВ ранжируются по отношению к уровню предоставляемых возможностей: ручное восстановление (уровни TR-1 и TR-2), автоматическое (уровень TR-3), обнаружение потерь объектов пользователей (уровень TR-4), минимизация потерь объектов (уровень TR-5).
• Уровень TR-1. Минимальные требования восстановления и инициализации
1. ТСВ должно содержать механизмы, обеспечивающие гарантированное восстановление безопасного состояния ТСВ после сбоев без нарушения функций защиты.
• Уровень TR-2. Базовые средства восстановления и инициализации ТСВ
1. Без изменений.
2. В случае невозможности автоматического восстановления и «реинициализации» безопасного состояния ТСВ должно переходить в особое состояние, в котором доступ может осуществляться только с помощью специальных административных процедур, с помощью которых можно осуществить восстановление ТСВ вручную без нарушений функций защиты.
• Уровень TR-3. Автоматическое восстановление и инициализация ТСВ
1. Без изменений
2. Изменение. ТСВ должно включать средства автоматического восстановления безопасного состояния ТСВ после ошибок и сбоев. Эти средства должны по возможности исключать потерю системных и пользовательских объектов. Должны быть определены требования, или правила, политики безопасности, позволяющие подтвердить безопасность ТСВ после восстановления.
• Уровень TR-4. Обнаружение потерь объектов
1. Без изменений.
2. Дополнение. ТСВ должно включать специальную контрольную функцию восстановления, способную обнаруживать повреждение или разрушение объектов в результате сбоев, и предупреждать об этом пользователей.
• Уровень TR-5. Минимизация потерь объектов
1. Без изменений.
2. Дополнение. Все вызываемые извне функции и операции ТСВ должны быть атомарными, т. е. либо завершаться полным выполнением указанных действий, либо, при возникновении сбоев, сохранять исходное состояние используемых объектов, субъектов и ресурсов. Применение атомарных функций позволяет минимизировать искажения и потери объектов при сбоях системы.
14. Ограничение привилегий при работе с ТСВ
Требования ограничения привилегий при работе с ТСВ ранжируются на основе детализации описания привилегий. ассоциированных с отдельными функциями или группами функций ТСВ (уровень РО-1), с отдельными компонентами (модулями) ТСВ и административными ролями (РО-2), с отдельными операциями (РО-3) и динамически изменяющимися в ходе выполнения операций (РО-4).
• Уровень РО-1. Назначение привилегий для выполнения функций ТСВ
1. Должны быть определены привилегии, необходимые для выполнения отдельных функций ТСВ или их групп. Также должны быть определены привилегированные функции и объекты ТСВ, такие, как файлы регистрации пользователей, файлы паролей, файлы, содержащие уровни безопасности пользователей и объектов, списки ролей пользователей, файлы журнала аудита.
2. Должен быть назначен минимальный уровень привилегий, необходимый и достаточный для осуществления доступа к установленным привилегированным функциям и объектам ТСВ.
• Уровень РО-2. Назначение привилегий доступа к компонентам ТСВ
1. Дополнение. Должна обеспечиваться возможность назначения необходимых привилегий действиям, выполняемым в ТСВ привилегированными пользователями (администраторами).
2. Изменение. Всем функциям и компонентам (модулям) ТСВ должен быть поставлен в соответствие минимальный уровень привилегий, необходимый и достаточный для их доступа к ним.
3. Должна быть обеспечена поддержка реализации привилегий модулей ТСВ с помощью низкоуровневых процедур и механизмов.
• Уровень РО-3. Назначение привилегий для выполнения отдельных операций
1. Без изменений.
2. Дополнение. Должны быть определены привилегии, необходимые для выполнения отдельных операций ТСВ. Для каждой операции должен быть назначен минимальный уровень привилегий, необходимый и достаточный для ее выполнения.
3. Изменение. Должна быть обеспечена поддержка реализации привилегий для отдельных операций ТСВ с помощью низкоуровневых процедур и механизмов.
• Уровень РО-4. Динамическое назначение привилегий для выполнения отдельных операций
1. Без изменений.
2. Дополнение. Установленное привилегии должны использоваться всеми функциональными компонентами ТСВ для контроля и ограничения распространения ошибок в работе механизмов защиты и предоставления полномочий, которые могут повлечь за собой нарушение политики безопасности. Должны быть определены функции ТСВ, позволяющие при необходимости динамически повышать привилегии отдельных операций ТСВ (но не выше заданной границы) и автоматически их понижать по завершению выполнения соответствующих операций. Эти меры должны ограничивать использование высокопривилегированных операций ТСВ, потенциально предоставляющих пользователю возможности использования этих привилегий для нарушения политики безопасности.
3. Без изменений.
15. Простота использования ТСВ
Ранжирование требований данной группы отражает имеющиеся возможности управления конфигурацией ТСВ. На уровне EU-1 сформулированы общие требования, отражающие необходимость наличия развитых средств управления безопасностью системы вместо использования обычных редакторов для модификации параметров безопасности или содержимого файлов регистрации пользователей. Требования к функциональности средств администрирования расширяются на уровне EU-2 посредством введения возможности установки атрибутов безопасности по умолчанию для некоторых субъектов и объектов и наличия средств, позволяющих приложениям обеспечить собственную защиту и защиту своих объектов от несанкционированного использования. На уровнях EU-3 и EU-4 требования усиливаются и расширяются за счет увеличения множества субъектов и объектов, на которые они распространяются для стандартной и полной конфигурации системы.
• Уровень EU-1. Простота управления безопасностью
1. ТСВ должно обеспечивать поддержку функций администрирования. Должна быть предусмотрена возможность задания значений параметров безопасности по умолчанию для средств администрирования.
• Уровень EU-2. Простота разработки приложений
1. Дополнение. ТСВ должно обеспечивать автоматическую установку атрибутов безопасности по умолчанию для определенных субъектов и объектов и возможность модификации этих атрибутов.
2. ТСВ должно предусматривать четко определенный программный интерфейс взаимодействия со всеми принятыми в системе политиками безопасности для поддержки приложений, которые могут обеспечить поддержку этих политик безопасности на прикладном уровне. ТСВ должно предоставлять пользователю возможность понижения полномочий используемых приложений.
• Уровень EU-З. Простота использования стандартной конфигурации системы
1. Изменение. ТСВ должно обеспечивать автоматическую установку атрибутов безопасности по умолчанию для определенных субъектов, объектов и служб, присутствующих в стандартной конфигурации системы, а также возможность модификации этих атрибутов.
2. Без изменений.
• Уровень EU-4. Простота использования полной конфигурации системы
1. Изменение. ТСВ должно обеспечивать автоматическую установку атрибутов безопасности по умолчанию для всех субъектов, объектов и служб системы, а также возможность модификации их атрибутов.
2. Без изменений.
Приложение II
Ранжированные требования «Канадских критериев безопасности компьютерных систем»
В настоящем приложении содержится перечень функциональных требований и требований к адекватности реализации «Канадских критериев безопасности компьютерных систем». Данное изложение отражает только принципиальную суть требований и не претендует на перевод стандарта как руководящего документа.
Описание каждого раздела требований начинается с его краткого описания и обзора предусмотренных уровней ранжирования. Идентификаторы уровней сохранены в том виде, в каком они присутствуют в первоисточнике. Специальный нулевой уровень зарезервирован для систем, реализующих данные требования в степени недостаточной для соответствия какому-либо уровню. Некоторые уровни функциональных критериев зависят от Других, и для того, чтобы удовлетворить требованиям этих уровней, необходимо соблюсти не только приведенные в них требования, но и требования сопряженных разделов функциональных критериев и критериев адекватности реализации в рамках указанных уровней. Для таких уровней после текста требований указываются идентификаторы уровней, сопряженных с ними.
1. Критерии конфиденциальности
Критерии конфиденциальное и регламентируют защиту ресурсов компьютерной системы от несанкционированного доступа. В качестве средств обеспечения конфиденциальности рассматриваются контроль скрытых каналов, произвольное и нормативное управление доступом и контроль за повторным использованием ресурсов.
1.1. Контроль скрытых каналов
Контроль скрытых каналов позволяет выявить присутствие в системе потоков информации, которые не могут контролироваться другими средствами защиты. Ранжирование требований производится по четырем уровням в зависимости от степени анализа наличия скрытых каналов и возможностей по контролю и подавлению.
•Уровень СС-0. Недостаточный контроль скрытых каналов
Данный уровень зарезервирован для систем с примитивными возможностями контроля скрытых каналов, которые не удовлетворяют требованиям более высоких уровней.
•Уровень С01. Анализ скрытых каналов
Должно быть проведено исследование наличия в компьютерной системе скрытых каналов. Каждый обнаруженный в аппаратных, программных или специальных средствах системы скрытый капал утечки информации должен быть документирован.
Максимальная пропускная способность каждого скрытого канала должна быть указана в документации. Кроме того, для скрытых каналов, которые могут быть использованы совместно, должна быть указана максимальная пропускная способность их совокупности.
Сопряженные уровни: ТЗ.
• Уровень СС-2. Контроль скрытых каналов
Дополнение. ТСВ должно позволять осуществлять контроль за использованием заданного множества скрытых каналов.
Сопряженные уровни: ТЗ, WA-1.
•Уровень СС-3. Подавление скрытых каналов
Изменение. Каждый выявленный скрытый канал должен быть ликвидирован.
Сопряженные уровни: ТЗ.
1.2. Произвольное управление доступом
Произвольное управление доступом позволяет администраторам и авторизованным пользователям управлять потоками информации от объектов системы к пользователям. Ранжирование требований проводится на основании возможностей механизма контроля и степени его детализации.
•Уровень CD-0. Недостаточное произвольное управление доступом
Уровень зарезервирован для систем с наличием отдельных элементов произвольного управления доступом, но не удовлетворяющих требованиям более высоких уровней.
•Уровень CD-1. Минимальные требования к произвольному управлению доступом
ТСВ должно обеспечивать реализацию политики произвольного управления доступом по отношению к заданному подмножеству объектов компьютерной системы.
Предоставление доступа к объекту должно производиться на основании значений тегов объекта и процесса, опросившего доступ.
Управление параметрами доступа должно выполнятся средствами ТСВ на основании тега пользователя.
Теги защищенных объектов должны назначаться при их создании или инициализации.
Правила назначения тегов при экспорте-импорте объектов должны являться составной частью политики произвольного управления доступом.
Сопряженные уровни. CR-1,WI-1
•Уровень CD-2. Базовая политика произвольного управления доступом
Изменение. Предоставление доступа к объекту должно производиться на основании значении тегов объекта и пользователя, ассоциированного с процессом, запросившим доступ.
Дополнение. Политика произвольного управления доступом должна предусматривать наличие частично определенной матрицы доступа для тегов всех пользователей и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
•Уровень CD-3. Гибкая политика произвольного управления доступом
Изменение. Политика произвольного управления доступом должна предусматривать наличие полностью определенной матрицы доступа для тегов всех пользователей и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
•Уровень CD-4. Расширенная политика произвольного управления доступом
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта, процесса, запросившего доступ, и пользователя, ассоциированного с этим процессом.
Изменение. Политика произвольного управления доступом должна предусматривать наличие полностью определенной матрицы доступа для тегов всех пользователей и процессов и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
1.3. Нормативное управление доступом
Нормативное управление доступом. так же как и произвольное управление доступом, позволяет администраторам и авторизованным пользователям управлять потоками информации от объектов системы к пользователям. Ранжирование требований проводится на основании степени их детализации, множества защищаемых объектов и представляемых возможностей по управлению доступом.
•Уровень СМ-0. Недостаточное нормативное управление доступом
Уровень резервирован для систем с примитивными возможностями нормативного управления доступом. Не удовлетворяющих требованиям более высоких уровней.
•Уровень СМ-1. Минимальные требования к нормативному управлению доступом
ТСВ должно обеспечивать реализацию политики нормативною управления доступом по отношению к заданному подмножеству объектов компьютерной системы.
Предоставление доступа к объекту должно производиться на основании значений тегов объекта и процесса, запросившего доступ.
Управление параметрами доступа должно осуществляться средствами ТСВ только администратором и уполномоченными пользователями.
Теги защищенных объектов должны назначаться при их создании или инициализации.
Правила назначения тегов при экспорте-импорте объектов должны являться составной частью политики нормативного управления доступом.
Сопряженные уровни: CR-1, IS-1.
•Уровень СМ-2. Базовая политика нормативного управления доступом
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта и пользователя, ассоциированного с процессом, запросившим доступ.
Сопряженные уровни: CR-1, IS-1, WI-1.
•Уровень СМ-3. Гибкая политика нормативного управления доступом.
Изменение. Политика нормативного управления доступом должна применяться ко всем объектам компьютерной системы.
Сопряженные уровни: CR-1, IS-1, WI-1.
•Уровень СМ-4. Расширенная политика нормативного управления доступом
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта, процесса, запросившего доступ, и пользователя, ассоциированного с этим процессом.
Сопряженные уровни: CR-1, IS-1, WI-1.
1.4. Повторное использование объектов
Контроль за повторным использованием объектов позволяет обеспечить безопасное использование разделяемых объектов, одновременно или последовательно доступных нескольким процессам. Контроль должен предотвращать сохранение в разделяемых объектах остаточной информации после завершения их использования одним процессом и перед предоставлением доступа к ним другому процессу.
•Уровень CR-0. Недостаточное нормативное управление доступом
Уровень зарезервирован для систем с примитивными возможностями контроля за повторным использованием объектов.
•Уровень CR-1. Безопасное повторное использование объектов
ТСВ должно обеспечивать политику безопасного повторного использования объектов. Эта политика должна применяться ко всем объектам, допускающим совместное использование.
Все полномочия доступа к разделяемому объекту должны быть отозваны перед предоставлением его в повторное использование.
Вся информация, содержащаяся в разделяемом объекте, должна быть уничтожена перед предоставлением его в повторное использование.
2. Критерии целостности
Критерии целостности определяют возможности компьютерной системы по обеспечению собственной целостности и целостности обрабатываемой и хранимой в ней информации. Критерии целостности предусматривают поддержку доменов целостности, произвольного и нормативного управления целостностью, разделения ролей, обеспечение физической целостности компонентов компьютерной системы, а также средств отката и самотестирования.
2.1. Домены целостности
Поддержка доменов целостности позволяет ТСВ осуществлять защиту собственных компонентов и контролировать целостность и осуществлять управление защищенными объектами.
•Уровень IB-0. Недостаточная поддержка доменов целостности
Зарезервирован для систем, осуществляющих поддержку доменов целостности в недостаточной степени и не удовлетворяющих требованиям более высоких уровней.
• Уровень IB-1. Домены целостности ТСВ
ТСВ должно поддерживать политику обеспечения целостности доменов, предусматривающую идентификацию доменов (как доменов ТСВ, так и остальных) и средства их изоляции.
ТСВ должно обеспечивать защиту co6cтвенных доменов от внешних воздействий.
• Уровень IB-2. Полный контроль доступа
Дополнение. Архитектура ТСВ должна гарантировать, что доступ к сервису средств безопасности и к защищенным объектам возможен только посредством ТСВ.
2.2. Произвольное управление целостностью
Произвольное управление целостностью позволяет администраторам и авторизованным пользователям управлять потоками информации от пользователей к объектам системы. Ранжирование требований проводится на основании возможностей механизма контроля и степени его детализации.
• Уровень ID-0. Недостаточное произвольное управление целостностью
Уровень зарезервирован для систем с наличием отдельных элементов произвольного управления целостностью, но не удовлетворяющих требованиям более высоких уровней.
• Уровень ID-1. Минимальные требования к произвольному управлению целостностью
ТСВ должно обеспечивать реализацию политики произвольного управления целостностью по отношению к заданному подмножеству объектов компьютерной системы.
Предоставление доступа к объекту должно производиться на основании значений тегов объекта и пользователя.
Управление параметрами доступа должно выполняться средствами ТСВ на основании тега пользователя.
Теги защищенных объектов должны назначаться при их создании или инициализации. Правила назначения тегов при экспорте-импорте объектов должны являться составной частью политики произвольного управления целостностью.
Сопряженные уровни: CR-1, WI-1.
• Уровень ID-2. Базовая политика произвольного управления целостностью
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта и процесса, запросившего доступ.
Дополнение. Политика произвольного управления Целостностью должна предусматривать наличие частично определенной матрицы доступа для тегов всех процессов и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
• Уровень ID-3. Гибкая политика произвольного управления целостностью
Изменение. Политика произвольного управления целостностью должна предусматривать наличие полностью определенной матрицы доступа для тегов всех процессов и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
• Уровень ID-4. Расширенная политика произвольною управления целостностью
Изменение. Предоставление доступа к объекту должно производиться на основании значении тегов объекта, процесса, запросившего доступ, и пользователя, ассоциированною с этим процессом.
Изменение. Политика произвольного управления целостностью должна предусматривать наличие полностью определенной матрицы доступа для тегов всех пользователей и процессов и тегов защищенных объектов.
Сопряженные уровни: CR-1, WI-1.
2.3. Нормативное управление целостностью
Нормативное управление целостностью, так же как и произвольное управление целостностью, позволят администраторам и уполномоченным пользователям управлять потоками информации от пользователей к объектам системы. Ранжирование требований проводится на основании степени их детализации, множества защищаемых объектов и предоставляемых возможностей по управлению доступом.
• Уровень 1М-0. Недостаточное нормативное управление целостностью
Уровень зарезервирован для систем с примитивными возможностями нормативного управления целостностью, не удовлетворяющих требованиям более высоких уровней.
• Уровень IM-1. Минимальные требования по нормативному управлению целостностью
ТСВ должно обеспечивать реализацию политики нормативного управления целостностью по отношению к заданному подмножеству объектов компьютерной системы.
Предоставление доступа к объекту должно производится на основании значений тегов объекта и пользователя.
Управление параметрами доступа должно осуществляться средствами ТСВ только администратором и авторизованными пользователями.
Теги защищенных объектов должны назначаться при их создании или инициализации.
Правила назначения тегов при экспорте-импорте объектов должны являться составной частью политики нормативного управления целостностью.
Сопряженные уровни: CR-1, IS-1, WI-1.
• Уровень IM-2. Базовая политика нормативного управления целостностью
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта и процесса, запросившего доступ.
Сопряженные уровни: CR-1, IS-1.
• Уровень IM-3. Гибкая политика нормативного управления целостностью
Изменение. Политика нормативного управления целостностью должна применяться ко всем объектам компьютерной системы.
Сопряженные уровни: CR-1, IS-1
•Уровень IM-4. Расширенная политика нормативного управления целостностью
Изменение. Предоставление доступа к объекту должно производиться на основании значений тегов объекта, процесса, запросившего доступ, и пользователя, ассоциированного с этим процессом.
Сопряженные уровни: CR-1,1 S-1, WI-1.
2.4. Физическая целостность
Критерии физической целостности определяют периметр ТСВ, регламентируют возможности средств физической защиты ТСВ. Задачей средств обеспечения физической целостности является выявление, ограничение и предотвращение несанкционированного физического доступа к внутренним элементам компьютерной системы, предотвращение несанкционированного использования, модификации или подмены ее физических компонентов. Требования к средствам физической защиты ранжируются в зависимости от типа обеспечиваемой защиты и средств, которые необходимо потратить злоумышленнику на ее преодоление.
• Уровень IP-0. Недостаточная физическая целостность
Зарезервирован для систем с минимальными возможностями обеспечения физической целостности, не удовлетворяющих требованиям более высоких уровней.
• Уровень IP-1. Базовые требования по обеспечению физической целостности
ТСВ должно поддерживать политику обеспечения (физической целостности, определяющую периметр физической защиты ТСВ и множество компонентов компьютерной системы, к которым данная политика применяется.
Периметр физической защиты ТСВ должен быть защищен с помощью специальных средств, позволяющих обнаруживать несанкционированное использование, физический доступ, модификацию или подмену защищенных компонентов.
• Уровень IP-2. Регулярная физическая целостность
Дополнение. ТСВ должно включать средства обнаружения или противодействия попыткам проникновения через все входы, расположенные па периметре физической защиты ТСВ.
Дополнение. В случае преодоления заграждений периметра безопасности ТСВ должно выполнить действия, предотвращающие нарушение политики безопасности, принятой и компьютерной системе.
• Уровень IP-3. Расширенная физическая целостность
Дополнение. Экстремальные ситуации, возникающие вследствие стихийных явлений, не должны приводить 1к разрушению защищенных компонентов компьютерной системы или должны вызывать предусмотренную реакцию ТСВ, направленную на предотвращение нарушения политики безопасности системы.
• Уровень IP-4. Полная физическая целостность
Дополнение. Все компоненты компьютерной системы должны быть защищены механизмами обнаружения и противодействия попыткам несанкционированного использования, физического доступа, изменения или подмены таким образом, чтобы физическое вмешательство в их работу было невозможным или вызывало предусмотренную реакцию ТСВ, направленную на предотвращение нарушений политики безопасности.
2.5. Возможность осуществления отката
Откат обеспечивает возможность отмены последовательности осуществленных действий и возвращение объектов компьютерной системы к исходному состоянию. Ранжирование критериев этого раздела, производится в зависимости от уровня конкретизации объектов и множества операций, которые могут быть отменены.
• Уровень IR-0. Недостаточные возможности осуществления отката
Зарезервирован для систем с примитивными возможностями отката, не удовлетворяющих требованиям более высоких уровней.
• Уровень IR-1. Ограниченные возможности осуществления отката
ТСВ должно поддерживать политику осуществления отката — возврата к предыдущему состоянию для определенного множества объектов.
Политика осуществления отката должна обеспечиваться автоматическими средствами, представляющими администратору и уполномоченным пользователям возможность отмены действий заданного множества операций над защищенными объектами за определенный период времени и возврата этих объектов в состояние, в котором они находились до выполнения этих операций.
Сопряженные уровни: WI-1.
• Уровень IR-2. Расширенные возможности осуществления отката
Изменение. Автоматические средства обеспечения отката должны позволять отменять действия всех операций с защищенными объектами.
Сопряженные уровни: WI-1.
2.6. Разделение ролей
Разделение ролей позволяет распределить ответственность за действия в системе, ограничить возможный ущерб безопасности системы в случае злоупотребления предоставленными правами и установить максимально допустимый предел полномочий пользователей и администратора. Требования ранжируются в зависимости от степени детализации.
• Уровень IS-0. Недостаточное разделение ролей
Зарезервирован для систем с примитивными возможностями разделения ролей, не удовлетворяющих требованиям более высоких уровней.
• Уровень IS-1. Базовые требования по разделению ролей
ТСВ должно поддерживать политику разделения ролей, регламентирующую административные и неадминистративные роли пользователей и соответствующие им действия и функции.
ТСВ должно обеспечивать разделение административных и неадминистративных функций.
Пользователи должны получать возможность выполнения административных действий только находясь в роли администратора.
Сопряженные уровни: WI-1.
• Уровень IS-2. Административное разделение ролей.
Дополнение. Политика разделения ролей должна предусматривать наличие как минимум двух отдельных административных ролей: администратор безопасности системы и администратор системы, не имеющий возможностей по управлению безопасностью.
Дополнение. Действия, доступные для выполнения в конкретной роли, должны быть минимизированы по своему составу и включать только те, которые необходимы для реализации функций, соответствующих данной роли.
Изменение. Пользователи должны иметь возможность выполнения функций любой роли (а не только административной) лишь находясь в этой роли.
Дополнение. ТСВ должно гарантировать, что пользователю, находящемуся в определенной роли, доступны те, и только те функции и действия, которые предусмотрены этой ролью.
Сопряженные уровни: WI-1.
• Уровень IS-3. Разделение ролей на основе привилегии пользователей
Дополнение. Политика разделения ролей должна предусматривать наличие множества различных ролей пользователей, различающихся уровнями привилегий.
Сопряженные уровни: WI-1.
2.7. Самотестирование
Самотестирование ТСВ обеспечивает корректность выполнения операций и надежное функционирование элементов компьютерной системы. Требования ранжируются в зависимости от возможностей механизмов самоконтроля своевременно обнаруживать некорректное функционирование компонентов компьютерной системы.
• Уровень IT-0. Недостаточное самотестирование
Зарезервирован для систем с примитивными возможностями самотестирования, не удовлетворяющих требованиям более высоких уровней.
• Уровень 1Т-1. Базовое самотестирование
ТСВ должно поддерживать политику самотестирования, определяющую возможности системы по периодическому контролю корректности функционирования ТСВ.
Состав тегов и методика проведения тестирования должны быть описаны в руководстве но управлению безопасностью системы.
• Уровень IT-2. Самотестирование при загрузке или запуске.
Дополнение. ТСВ должно выполнять набор контролирующих тестов в процессе запуска или загрузки системы для проверки правильности функционирования критичных компонентов.
• Уровень IT-3. Самотестирование в процессе работы
Изменение. ТСВ должно обеспечивать выполнение кот роля правильности функционирования критичных компонентов не только при запуске или загрузке, но и периодически в процессе функционирования компьютерной системы.
3. Критерии работоспособности
Критерии работоспособности регламентируют работу средств, обеспечивающих доступность компьютерной системы и ее ресурсов для авторизованных пользователей. В качестве мер обеспечения работоспособности рассматриваются контроль за распределением ресурсов системы, обеспечение устойчивости системы к отказам и сбоям, обеспечение живучести и восстановления системы в условиях выхода из строя ее компонентов.
3.1. Контроль за распределением ресурсов
Контроль за распределением ресурсов позволяет ТСВ управлять использованием компьютерной системы. Требования ранжируются в зависимости от контролируемых ресурсов и предоставляемых возможностей.
•Уровень АС-0. Недостаточный контроль за распределением ресурсов
Зарезервирован для систем с примитивными возможностями контроля за распределением ресурсов, не удовлетворяющих требованиям более высоких уровней.
• Уровень АС-1. Нормированное распределение ресурсов
ТСВ должно поддерживать политику управления распределением ресурсов компьютерной системы, позволяющую установить нормы (квоты) на предоставление пользователям заданного подмножества ресурсов системы
Изменение квот на выделение ресурсов может производиться только администраторами и уполномоченными пользователями посредством ТСВ.
Сопряженные уровни: IS-1.
• Уровень АС-2. Предотвращение отказов в обслуживании
Изменение. Полшика управления распределением ресурсов должна охватывать все ресурсы компьютерной системы.
Дополнение. Нормы и квоты на потребление ресурсов должны быть заданы таким образом, чтобы ни один пользователь не мог захватить все ресурсы системы и сделать невозможным доступ остальных пользователей к сервису ТСВ и защищенным объектам.
Сопряженные уровни: IS-1.
• Уровень АС-3. Разграничение ресурсов
Изменение. Политика управления распределением ресурсов должна позволять устанавливать ограничения на потребление ресурсов как для отдельных пользователей, так и для групп пользователей.
Изменение. Соответственно, нормы и квоты на потребление ресурсов должны быть заданы таким образом, чтобы не только один пользователь, но и группа пользователей не могла захватить все ресурсы системы и сделать невозможным доступ остальных пользователей к сервису ТСВ и защищенным объектам.
Сопряженные уровни: IS-/.
3.2. Устойчивость к отказам и сбоям
Устойчивость к ошибкам и сбоям позволяет обеспечивать работоспособность системы и доступность ее ресурсов при выходе из строя отдельных компонентов. Требования ранжируются в зависимости от обеспечиваемых возможностей замены компонентов без нарушения функционирования.
• Уровень AF-0. Недостаточная устойчивость к отказам и сбоям
Зарезервирован для систем с примитивными возможностями обеспечения устойчивости к отказам, не удовлетворяющих требованиям более высоких уровней.
• Уровень AF-1. Замена отдельных компонентов в ходе функционирования
ТСВ должно поддерживать политику обеспечения устойчивости к сбоям и отказам для заданного множества компонентов, замена которых не требует прерывания функционирования системы.
Администратор или уполномоченные пользователи должны иметь возможность осуществления замены защищенных компонентов.
Сопряженные уровни: IS-1, AR-1.
• Уровень AF-2. Полная замена компонентов системы
Изменение. Политика обеспечения устойчивости к отказам и сбоям должна охватывать все компоненты компьютерной системы и обеспечивать их замену без прерывания функционирования.
Сопряженные уровни: IS-1, AR-1.
3.3. Живучесть
Живучесть (robustness) системы характеризует ее возможности сохранять работоспособность и доступность ресурсов системы после отказа некоторых из ее компонентов. Фактически свойство живучести определяет возможность системы выполнять свои функции при наличии неисправных компонентов. Требования ранжируются в зависимости количества неисправностей, при наличии которых сохраняется работоспособность системы, и от множества ресурсов, доступных в условиях выхода из строя компонентов системы.
• Уровень AR-О. Недостаточная живучесть
Зарезервирован для систем с примитивными возможностями обеспечения живучести, не удовлетворяющих требованиям более высоких уровней.
• Уровень AR-1. Надежность системы при выходе из строя ограниченного множества компонентов
ТСВ должно поддерживав поли гику обеспечения живучести, определяющую набор защищенных компонентов системы и множество неисправностей этих компонентов, при возникновении которых система сохраняет работоспособность и продолжает функционировать.
Выход из строя отдельного защищенного компонента не должен нарушать доступность ресурсов системы, но в худшем случае может привести к деградации ее функциональных возможностей.
Должны быть четко определены неисправности, сбои и отказы, возникновение которых приводит к деградации функциональных возможностей системы или к отказам в обслуживании.
Система должна иметь средства оповещения администратора о выходе из строя защищенных компонентов.
Сопряженные уровни: IS-1.
• Уровень AR-2. Надежность системы при выходе из строя любых компонентов системы с деградацией функциональных возможностей
Изменение. Политика обеспечения живучести должна применяться ко всем компонентам системы, а не только к их заданному набору.
Сопряженные уровни: IS-1.
• Уровень AR-3. Надежность системы без нарушений ее функционирования
Изменение. Выход из строя отдельного защищенного компонента не должен нарушать доступность ресурсов системы или приводить к деградации ее функциональных возможностей.
Сопряженные уровни: IS-1.
3.4. Восстановление
Средства восстановления позволяют вернуть ТСВ в безопасное состояние после отказов или сбоев. Требования ранжируются в зависимости от степени автоматизации процесса восстановления.
• Уровень AY-0. Недостаточное восстановление
Зарезервирован для систем с примитивными возможностями восстановления, не удовлетворяющих требованиям более высоких уровней.
• Уровень AY-1. Ручное восстановление
ТСВ должно поддерживать политику восстановления безопасного состояния, определяющую множество нарушений функционирования системы, после возникновения которых возможно восстановление состояния системы без нарушений политики безопасности.
После нарушения функционирования системы ТСВ должна обеспечить переход системы в специальное состояние временного останова, в котором только администратор и соответствующим образом уполномоченные пользователи могут выполнить действия по восстановлению нормального функционирования системы.
Должна быть регламентирована процедура ручного восстановления нормального функционирования системы без нарушения принятой политики безопасности.
Должны быть определены нарушения в работе системы, в случае возникновения которых необходима полная переустановка системы.
Сопряженные уровни: IS-1.
• Уровень AY-2. Автоматическое восстановление
Дополнение После нарушения функционирования системы ТСВ должно определить, какие автоматические процедуры могут быть использованы для восстановления нормальною функционирования системы.
Дополнение. Если это возможно, ТСВ должно выполнить автоматические процедуры и восстановить нормальное функционирование системы.
Изменение Если автоматическое восстановление невозможно, ТСВ должно обеспечить переход системы в специальное состояние временного останова, в котором только администратор и соответствующим образом уполномоченные пользователи могут выполнить действия по восстановлению нормального функционирования системы.
Сопряженные уровни IS-1
• Уровень AY-3. Селективное автоматическое восстановление
Изменение В случае, когда после нарушения функционирования системы не требуется ее полная переустановка, ТСВ должно осуществить автоматическое восстановление без потери доступности системных ресурсов; в худшем случае допускается деградация функциональных возможностей системы.
Сопряженные уровни IS-1
4. Критерии аудита
Критерии аудита регламентируют работу средств, позволяющих установить ответственность пользователей за события в системе. Аудит обеспечивается средствами регистрации и учета, идентификации и аутентификации, а также прямого взаимодействия с ТСВ.
4.1. Регистрация и учет событий в системе
Регистрация и учет событий в системе позволяют выявить потенциально опасные действия пользователей. Требования ранжируются в зависимости от степени их Легализации, сложности процесса анализа событий и возможности выявлять потенциальные угрозы безопасности.
• Уровень WA-0. Недостаточная регистрация и учет событий в системе
Зарезервирован для систем с примитивными возможностями регистрации и учета, не удовлетворяющих требованиям более высоких уровней.
• Уровень WA-1. Регистрация и учет событий в системе
ТСВ должно поддерживать политику регистрации и учета событий в системе, определяющую множество событий, подлежащих регистрации в журнале аудита.
ТСВ должно осуществлять минимальный контроль событий, влияющих на безопасность системы, и предоставлять журнал аудита посредством специального защищенного механизма для других компонентов компьютерной системы.
Журнал аудита должен содержать информацию о дате, времени, месте, типе и результате каждого регистрируемого события.
Журнал аудита должен содержать информацию, позволяющую идентифицировать пользователей, процессы и объекты, участвовавшие в зарегистрированных событиях.
Сопряженные уровни. WI-1
• Уровень WA-2. Регистрация и учет событий в системе и защита журнала аудита
Изменение. ТСВ должно осуществлять минимальный контроль событий, влияющих на безопасность системы, поддерживать журнал аудита и обеспечивать его защиту от несанкционированного доступа, модификации и уничтожения.
Дополнение. Средства просмотра журнала аудита должны быть доступны администрaтору и уполномоченным пользователям и обеспечивать поддержку проверки зарегистрированных событий.
Сопряженные уровни: IS-1, WI-1.
• Уровень WA-3. Регистрация и учет событии в системе, защита журнала аудита и оповещение администратора
Дополнение. ТСВ должно осуществлять мониторинг событий или их совокупности, возникновение которых является признаком возможного нарушения политики безопасное in.
Дополнение. ТСВ должно обеспечить возможность незамедлительного оповещения администратора в случае возникновения угроз безопасности, а при постоянном их появлении прекратить выполнение операции, вызвавшей это событие, с минимальными последствиями для функционирования системы.
Сопряженные уровни: IS-1, WI-1.
• Уровень WA-4. Детальная регистрация и учет событии в системе.
Изменение. ТСВ должно осуществлять детальный контроль событий, влияющих на безопасность системы, поддерживать журнал аудита и обеспечивать его защиту от несанкционированною доступа, модификации и уничтожения.
Изменение. Средства анализа журнала аудита должны быть доступны администратору и авторизованным пользователям и обеспечивать поддержку анализа зарегистрированных событий.
Сопряженные уровни: IS-1, WI-1.
• Уровень WA-5. Выявление вторжений
Дополнение. ТСВ должно осуществлять контроль попыток нарушения безопасности вторжения в систему в режиме реального времени в соответствии с принятой в системе политикой безопасности.
Сопряженные уровни: IS-1, WI-1.
4.2. Идентификация и аутентификация
Идентификация и аутентификация позволяют ТСВ проверить подлинность пользователей, пытающихся получить доступ к системе и ее ресурсам. Ранжирование требований выполняется в зависимости от функциональности возможное! си механизмов идентификации и аутентификации.
• Уровень WI-0. Недостаточная идентификация и аутентификация
Зарезервирован для систем с примитивными возможностями идентификации и аутентификации, не удовлетворяющих требованиям более высоких уровней.
• Уровень WI-1. Внешняя идентификация и аутентификация
ТСВ должно поддерживать политику идентификации и аутентификации, определяющую набор атрибутов, ассоциированных с пользователем, и соответствующие механизмы контроля и управления этими атрибутами.
Каждый пользователь должен иметь уникальный идентификатор.
ТСВ должно содержать защищенный механизм, позволяющий получить идентификатор пользователя и осуществить его аутентификацию с помощью внешних средств, перед предоставлением ему возможности выполнения любых действий в системе.
• Уровень WI-2. Индивидуальная идентификация и
аутентификации
Изменение. ТСВ должно содержать защищенный механизм, позволяющий получить идентификатор пользователя и осуществить его аутентификацию с помощью собственных средств ТСВ перед предоставлением пользователю возможности выполнения любых действий в системе.
Дано тонне. ТСВ должно обеспечивать защиту информации, применяемой для аутентификации, от несанкционированною доступа, модификации и уничтожения.
• Уровень WI-3. Множественная идентификация и аутентификация
Изменение. ТСВ должно содержав два и более защищенных механизма, позволяющих получить идентификатор пользователя и осуществить его аутентификацию с помощью собственных средств ТСВ перед предоставлением пользователю возможности выполнения любых действий в системе.
4.3. Прямое взаимодействие с ТСВ
Прямое взаимодействие с ТСВ (Trusted Path) обеспечивает возможность непосредственного конфиденциального взаимодействия между пользователем и ТСВ. Требования ранжируются в зависимости от гибкости механизмов, обеспечивающих прямое взаимодействие с ТСВ, и возможное! и пользователя инициирован:, взаимодействие с ТСВ.
• Уровень WT-0. Недостаточное прямое взаимодействие с ТСВ.
Зарезервирован для систем с примитивными возможностями прямого взаимодействия с ТСВ, не удовлетворяющих требованиям более высоких уровней.
• Уровень WT-1. Базовые механизмы прямого взаимо-деис1вия с ТСВ
ТСВ должно поддерживать политику обеспечения прямого взаимодействия с ТСВ, предусматривающую наличие соответствующих средств создания защищенных каналов взаимодействия пользователя с ТСВ.
Прямое взаимодействие с ТСВ должно использоваться для начальной идентификации и аутентификации пользователя.
Взаимодействие с ТСВ может быть инициировано только со стороны пользователя.
Сопряженные уровни: WI-2.
• Уровень WT-2. Усовершенствованные средства прямою взаимодействия с ТСВ
Изменение Прямое взаимодействие с ТСВ должно» использоваться для начальной идентификации и аутентификации пользователя, а также всегда инициироваться пользователем при необходимости передачи информации от пользователя к ТСВ или от ТСВ к пользователю.
Изменение. Прямое взаимодействие с ТСВ может быть инициировано как со стороны пользователя, так и ТСВ. Инициация прямого взаимодействия с пользователем со стороны ТСВ должна однозначно идентифицироваться пользователем и требовать Подтверждения с его стороны.
Сопряженные уровни: WI-2.
• Уровень WT-3. Полное обеспечения прямого взаимодействия с ТСВ
Изменение. Прямое взаимодействие с ТСВ должно использоваться для начальной идентификации и аутентификации пользователя, а также всегда инициироваться пользователем или ТСВ при необходимости передачи информации от пользователя к ТСВ или от ТСВ к пользователю.
Сопряженные уровни: WI-2
5. Критерии адекватности реализации
Критерии адекватности реализации регламентируют требования к процессу разработки и реализации компьютерной системы, позволяющие определить адекватность реализации политики безопасности и, в конечном счете отражают степень доверия к системе. Критерии адекватности охватывают все стадии и аспекты создания и эксплуатации системы и включают разделы, относящиеся к архитектуре системы, среде разработки (процесс разработки и управление конфигурацией), контролю процесса разработки (разработка спецификаций, архитектуры, создание рабочею проекта и реализация), поставке и сопровождению, документации (руководство по безопасности для пользователя и руководство администратора безопасности) и тестированию безопасности. Предусмотрено восемь уровней адекватности реализации (ТО-Т7). С ростом номера уровня происходит конкретизация, дополнение и усиление требований без изменения их структуры. Критерии адекватности реализации политики безопасности представляют собой наиболее объемную и детально проработанную часть «Канадских критериев».
•Уровень Т-0. Недостаточная адекватность реализации.
Зарезервирован для систем с недостаточным уровнем обеспечения адекватности, не удовлетворяющих требованиям более высоких уровней.
• Уровень Т-1.
1. Архитектура
ТСВ должна обеспечивать поддержку принят он в компьютерной системе политики безопасности.
2. Среда разработки
Процесс разработки.
Разработчик компьютерной системы должен применять четко определенную технологию разработки и строго придерживаться ее принципов.
Управление конфигурацией в процессе разработки
В ходе создания системы разработчик должен использовать средства управления конфигурацией.
Средства управления конфигурацией должны контролировать вес изменения, вносимые в ходе разработки в аппаратное и специальное обеспечение, в исходные тексты и объектный код программ, а также в документацию.
Средства управления конфигурацией должны обеспечивать полное соответствие между комплектом документации и текущей версией ТСВ.
3. Контроль процесса разработки
Разработка спецификаций.
Разработчик обязан описать все функциональные возможности компьютерной системы в виде функциональных спецификаций.
Функциональные спецификации должны содержать неформальное описание реализуемой политики безопасности включающее описание всех функций защиты, реализованных в ТСВ.
Разработка архитектуры
Разработчик обязан составить неформальное описание архитектуру компьютерной системы.
Описание архитектуры компьютерной системы должно включать описание всех компонентов ТСВ.
Описание архитектуры должно включать интерфейс взаимодействия ТСВ с остальными компонентами компьютерной системы.
Описание архитектуры должно включать описание всех функций защиты, реализованных аппаратными, программными и специальными компонентами ТСВ.
Разработчик должен обеспечить полное соответствие между архитектурой системы и политикой безопасности.
Создание рабочего проекта.
Разработчик обязан составить неформальное описание рабочего проекта ТСВ.
Рабочий проект должен содержать описание всех компонентов ТСВ и подробно описывать механизмы функционирования всех функций, критичных с точки зрения безопасности.
Должны быть описаны назначение и параметры интерфейсов компонентов ТСВ, критичных с точки зрения безопасности.
Реализация.
Для данного уровня требования этою раздела не предъявляются.
4. Поставка и сопровождение
Разработчик в комплекте с системой должен предоставлять средства ее инсталляции, генерации и запуска.
Разработчик должен определить и документировать все параметры компьютерной системы, используемые для ее настройки системы в ходе инсталляции, генерации и запуска.
5. Документация
Руководство по безопасности для пользованная.
Разработчик должен включить в состав документации на компьютерную систему руководство по безопасности для пользователя в виде обзора или раздела в общей документации либо отдельного руководства. Руководство по безопасности для пользователя должно содержать описание возможностей компьютерной системы по обеспечению безопасности и принципов работы рядового пользователя со средствами защиты.
В руководстве пользователя также должно быть описано взаимодействие между отдельными подсистемами обеспечения безопасности.
Руководство администратора безопасности.
Разработчик должен включить в состав документации на компьютерную систему руководство администратора безопасности в виде обзора или раздела в общей документации либо отдельного руководства. Руководство администратора безопасности должно содержать описание возможное! ей администрирования средств защиты.
Руководство администратора безопасности должно содержать описание взаимодействия отдельных средств защиты с точки зрения их администрирования.
Руководство администратора безопасности должно содержать описание процесса инсталляции, генерации и запуска системы с точки зрения обеспечения безопасности.
Руководство администратора безопасности должно содержать описание всех параметров компьютерной системы, используемых для ее настройки в ходе инсталляции, генерации и запуска, с точки зрения обеспечения безопасности.
6. Тестирование безопасности
Разработчик должен предоставить методику тестирования безопасности системы, сценарий проведения испытаний и средства тестирования. Полно га набора тестов безопасности системы должна быть обоснована.
Разработчик должен представить доказательства проведения тестирования безопасности системы в виде подробного описания результатов проведенных тестов в соответствии с методикой тестирования.
• Уровень Т-2.
1. Архитектура
Без изменений
2. Среда разработки
Процесс разработки. Без изменений.
Управление конфигурацией в процессе разработки. Без изменений.
3. Контроль процесса разработки
Разработка спецификации.
Дополнение. Функциональные спецификации должны включать неформальное описание модели безопасности.
Дополнение. Разработчик должен обеспечить полное соответствие между моделью безопасности и реализованной политикой безопасности и показать, что модель безопасности полностью обеспечивает политику безопасности
Разработка архитектуры.
Изменение. Разработчик должен обеспечить полное соответствие между архитектурой системы и моделью безопасности.
Создание рабочего проекта.
Изменение. Рабочий проект должен содержать описание всех компонентов ТСВ и подробно описывать механизмы функционирования всех функций ТСВ.
Изменение. Должны быть описаны назначение и параметры интерфейсов всех компонентов ТСВ.
Дополнение. Разработчик должен обеспечить полное соответствие между архитектурой системы и рабочим проектом. Реализация. Для данного уровня требования этого раздела не предъявляются.
4. Поставка и сопровождение
Без изменений.
5. Документация
Руководство но безопасности для пользователя. Без изменений.
Руководство администратора безопасности. Без изменений.
6. Тестирование безопасности
Дополнение. Разработчик должен исправить или нейтрализовать все обнаруженные в ходе тестирования ошибки, после чего провести повторное тестирование ТСВ для подтверждения того, что обнаруженные ошибки ликвидированы и при этом не внесены новые.
•Уровень Т-3.
1. Архитектура
Дополнение. ТСВ должна быть структурирована в виде набора независимых компонентов.
2. Среда разработки
Процесс разработки.
Дополнение. Разработчик должен указать использованные в ходе разработки стандарты программирования и показать, что исходные тексты программного обеспечения соответствуют этим стандартам.
Дополнение. Разработчик должен указать использованные в ходе разработки языки программирования, и внести в документацию все зависимости программного обеспечения от реализации языков программирования и используемых компиляторов.
Управление конфигурацией в процессе разработки.
Изменение. Средства управления конфигурацией должны контролирован» вес изменения, вносимые в ходе разработки в аппаратное и специальное обеспечение, в исходные тексты и объектный код программ, а также в документацию и в компиляторы, используемые для трансляции исходных текстов.
3. Контроль процесса разработки
Разработка спецификаций.
Изменение. Функциональные спецификации должны включать полуформальное описание модели безопасности.
Разработка архитектуры.
Изменение. Разработчик обязан составить полуформальное описание архитектуры компьютерной системы.
Создание рабочего проекта. Без изменений.
Реализация.
Разработчик обязан предоставить исходные тексты заданного подмножества компонентов ТСВ.
Разработчик должен обеспечить полное соответствие между рабочим проектом и реализацией ТСВ.
4. Поставка и сопровождение
Дополнение. Должны быть использованы технические, физические и организационные меры для контроля
адекватности поставляемой потребителю копии ТСВ дистрибутив.
5. Документация
Руководство но безопасности для пользователя. Без изменений.
Руководство администратора безопасности.
Без изменений.
6. Тестирование безопасности
Без изменений.
•Уровень Т-4.
1. Архитектура
Дополнение. Компоненты ТСВ, критичные с точки зрения безопасности, должны быть защищены от воздействия со стороны незащищенных компонентов с помощью средств защиты, реализованных аппаратной платформой компьютерной системы.
2. Среда разработки
Процесс разработки.
Дополнение. Должны быть описаны все физические, организационные и другие меры, используемые для защиты компьютерной системы и документации в ходе их разработки.
Управление конфигурацией в процессе разработки.
Изменение. Должны использоваться автоматизированные средства управления конфигурацией, контролирующие все изменения, вносимые в ходе разработки в аппаратное и специальное обеспечение, в исходные тексты и объектный код программ, а также в документацию и в конфигурацию компиляторов, используемых для трансляции исходных текстов.
Дополнение. Средства управления конфигурацией должны обеспечивать трансляцию и сборку исходных текстов ТСВ и осуществлять сравнение версий ТСВ для подтверждения внесенных изменений.
Дополнение. Средства управления конфигурацией должны обнаруживать несоответствия между версиями различных компонентов ТСВ и автоматически разрешать эти проблемы.
3. Контроль процесса разработки
Разработка с нотификации
Изменение. Функциональные спецификации должны включать формальное описание модели безопасности.
Изменение. Разработчик должен обеспечить и продемонстрировать полное соответствие между моделью безопасности и реализованной политикой безопасности и продемонстрировать, что модель безопасности полностью обеспечивает политику безопасности.
Разработка архитектуры.
Изменение. Описание архитектуры должно включать интерфейс взаимодействия ТСВ с остальными компонентами компьютерной системы с указанием исключительных ситуаций и сообщений об ошибках.
Создание рабочего проекта.
Изменение. Разработчик обязан составить полуформальное описание рабочего проекта ТСВ.
Реализация. Без изменений.
4. Поставка и сопровождение
Без изменений.
5. Документация
Руководство но безопасности для пользователя. Без изменений.
Руководство администратора безопасности. Без изменений.
6. Тестирование безопасности.
Изменение. Разработчик должен исправить все обнаруженные в ходе тестирования ошибки, после чего проверит повторное тестирование ТСВ для подтверждения того, что обнаруженные ошибки ликвидированы и притом не внесены новые.
Дополнение. Разработчик должен провести тестирование в виде попыток несанкционированного проникновения в систему и доказать, что система относительно успешно противостоит атакам.
•Уровень Т-5.
1. Архитектура
Дополнение. Разработчик должен, по возможности, исключить из ТСВ не критичные с точки зрения безопасности компоненты и обосновать свой выбор.
Дополнение. При проектировании ТСВ разработчик должен применять технологии, позволяющие минимизировать се сложность. В основе структуры ТСВ должен лежать законченный концептуально простой механизм защиты с четко определенной семантикой. Этот механизм должен играть основную роль в обеспечении внутренней структуры ТСВ и всей системы. Архитектура ТСВ должна использовать принципы модульности, абстракции и инкапсуляции внутренних объектов. Каждый компонент должен быть спроектирован с использованием принципа наименьших привилегий.
2. Среда разработки
Процесс разработки. Без изменений.
Управление конфигурацией в процессе разработки. Без изменений.
3. Контроль процесса разработки
Разработка спецификаций. Без изменений.
Разработка архитектуры.
Изменение. Разработчик должен продемонстрировать полное соответствие между архитектурой системы и моделью безопасности.
Создание рабочего проекта. Без изменений.
Реализация.
Изменение. Разработчик обязан предоставить все исходные тексты ТСВ.
4. Поставка и сопровождение
Без изменений.
5. Документация
Руководство по безопасности для пользователя. Без изменений.
Руководство администратора безопасности. Без изменений.
6. Тестирование безопасности
Изменение. Разработчик должен провести тестирование в виде попыток несанкционированного проникновения в систему и доказать, что система успешно противостоит атакам.
• Уровень Т-6.
1. Архитектура
Без изменений.
2. Среда разработки
Процесс разработки.
Изменение. Должны быть описаны все физические, организационные и другие меры, используемые для защиты компьютерной системы и документации в ходе их разработки и применяемых в процессе разработки инструментальных средств.
Управление конфигурацией в процессе разработки.
Изменение. Должны использоваться автоматизированные средства управления конфигурацией, контролирующие все изменения, вносимые в ходе разработки в аппаратное и специальное обеспечение, в исходные тексты|и объектный код программ, а также в документацию, в конфигурацию компиляторов, используемых для трансляции исходных текстов и инструментальных средств разработки.
Дополнение. Должны быть использованы технические, физические и организационные меры для защиты от несанкционированной модификации или уничтожения дистрибутивной копии ТСВ или дистрибутивных копий всех материалов, используемых для построения ТСВ.
3. Контроль процесса разработки
Разработки спецификаций. Без изменений.
Разработка архитектуры.
Изменение. Разработчик обязан составить формальное описание архитектуры компьютерной системы.
Изменение. Разработчик должен доказать полное соответствие между архитектурой системы и моделью безопасности.
Создание рабочего проекта.
Изменение. Разработчик должен продемонстрировать полное соответствие между архитектурой системы и рабочим проектом.
Реализация. Без изменений.
4. Поставка и сопровождение
Дополнение. Процесс дистрибуции компонентов компьютерной системы должен быть защищен с помощью соответствующих средств, обеспечивающие адекватность поставляемой потребителю копии ТСВ дистрибутив.
5. Документация
Руководство но безопасности для пользователя. Без изменений.
Руководство администратора безопасности. Без изменений.
6. Тестирование безопасности
Без изменений.
• Уровень Т-7
1. Архитектура
Без изменений.
2. Среда разработки
Процесс разработки. Без изменений.
Управление конфигурацией в процессе разработка
Без изменений.
3. Контроль процесса разработки
Разработка спецификаций. Без изменений.
Разработка архитектуры. Без изменений.
Создание рабочего проекта.
Изменение. Разработчик обязан составить формальное описание рабочего проекта ТСВ.
Изменение. Разработчик должен доказать полное Соответствие между архитектурой системы и рабочим проектом.
Реализация.
Изменение. Разработчик должен продемонстрировать полное соответствие между рабочим проектом и реализацией ТСВ.
4. Поставка и сопровождение
Без изменений.
5. Документация
Руководство по безопасности для пользователя. Без изменений.
Руководство администратора безопасности. Без изменений.
6. Тестирование безопасности
Без изменений
Приложение III.
Ранжированные требования «Единых критериев безопасности информационных технологий»
Это приложение содержит ранжированный перечень функциональных требований и требований адекватности, содержащихся в «Единых критериях». Данное изложение отражает только суть требований и не претендует на перевод стандарта как нормативного документа.
Для того чтобы отобразить иерархическое ранжирование требований, присущее «Единым критериям», будем представлять их в виде таблиц, в которых сравнимые требования образуют столбцы, а несравнимые — строки.
Рассмотрим соответствие таблиц и иерархии требований на следующем примере:
Графическое представление иерархии:
соответствует следующей таблице:
Требования
1
5
2
3
4
6
В этой таблице каждое из несопоставимых между собой требований 2, 3 и 4 обеспечивает больший уровень безопасности, чем требование 1. Ни одно из них несопоставимо с требованиями 5 и 6, образующими параллельную шкалу.
Функциональные требования
1. Аудит
Автоматическое реагирование на вторжение в систему поднятия тревоги
1. поднятие тревоги
2. Автоматическое реагирование
3. Конфигурируемое автоматическое реагирование
Регистрация и учет событий
1. регистрация и учет указанной информации и событий
2. Регистрация и учет событии и идентификация инициировавших их пользователей
Управление аудитом
I. Управление протоколом аудита
2. Контроль заполнения протокола аудита
3. Управление пределами заполнения протокола аудита
4. Управление заполнением протокола аудита в ходе работы
Выявление отклонении от штатного режима работы
1. Выявление отклонении от штатною режима работы
2. Динамическое управление параметрами контроля
Распознавание вторжении в систему
1. Распознавание на основе простых эвристик
3. Динамический контроль за параметрами распознавания в ходе функционирования
2. Распознавание на основе сложных эвристик
Предобработка протокола аудита
1. Преобразование в форму. доступную для человека
2. Преобразование в форму, удобную для автоматической обработки
3. Преобразование в форму, допускающую последующие преобразования
Зашита протокола аудита
1. Ограниченная зашита протокола аудита
2. Расширенная защита протокола аудита
Постобработка протокола аудита
1. Преобразование в форму доступную для человека
2. Преобразование в форму, удобную для автоматической обработки
3. Преобразование в форму, допускающую последующие преобразования
Анализ протокола аудита
1. Анализ надвигающихся угроз на основе статических правил
2. Анализ надвигающихся угроз на основе динамических правил
Контроль доступа к протоколу аудита
1. Ограниченный контроль доступа к протоколу аудита
3. Избирательный контроль доступа к протоколу аудита
2. Расширенный контроль доступа к протоколу аудита
Отбор событий для регистрации н учета
1. Избирательный аудит
2. Выбор событий аудита в процессе работы
3. Выбор событии аудита в процессе работы администратором
4. Выбор событии аудита в процессе работы уполномоченными пользователями
Выделение ресурса под протокол аудита
1. Выделение постоянного ресурса под протокол аудита
2. Учет потерянных данных протокола аудита
3. Предотвращение потерь данных протокола аудита
4. Управление предотвращением потерь данных протокола аудита
2. Информационный обмен
Невозможность для источника отречься от факта передачи информации
1. Принудительное доказательство передачи информации
2. Избирательное доказательство передачи информации
Невозможность для приемника отречься от факта получения информации
1. Принудительное доказательство приема информации
2. Избирательное доказательство приема информации
3. Защита информации
Политика управления доступом
I. Управление доступом для ограниченного множества объектов и субъектов
2. Управление доступом для полного множества объектов и субъектов
Средства управления доступом
1. Управление доступом с помощью единственного атрибута безопасности
3. Средства предоставления прав доступа
5. Фиксированное распределение прав доступа
2. Управление доступом с помощью нескольких атрибутов безопасности
4. Средства предоставления и отмены прав доступа
Инициализация атрибутов безопасности объектов
1. Статическая инициализация атрибутов безопасности
2. Определяемая администратором инициализация атрибутов безопасности
4. Управление инициализацией атрибутов безопасности на основе специальных правил
3. Определяемая пользователем инициализация атрибутов безопасности
5. Управление инициализацией и модификацией атрибутов безопасности на основе специальных правил
Экспорт информации
Экспорт информации без сохранения атрибутов безопасности
Экспорт информации с сохранением атрибутов безопасности
Политика управления информационными потоками
Частичное управление информационными потоками
Полное управление информационными потоками
Средства управления информационными потоками
1. Управление информационными потоками на основании атрибутов безопасности информации и ее приемника
3. Контроль нежелательных информационных потоков
6. Мониторинг нежелательных информационных потоков
2. Управление информационными потоками на основании иерархии атрибутов безопасности, образующих решетку
4. Частичный запрет нежелательных информационных потоков
5. Полный запрет нежелательных информационных потоков
Импорт информации
Импорт информации без атрибутов безопасности
Импорт информации с атрибутами безопасности
Защита информации в процессе передачи между компонентами по внутренним каналам
1. Базовые средства защиты передаваемой информации
3. Мониторинг целостности передаваемой информации
2. Разграничение каналов передачи информации на основании атрибутов безопасности
4. Мониторинг целостности передаваемой информации на основе атрибутов безопасности
Уничтожение остаточной информации
1. Уничтожение остаточной информации при создании определенного подмножества объектов
2 Уничтожение остаточной информации при удалении определенного подмножества объектов
3. Уничтожение остаточной информации при создании любых объектов
4. Уничтожение остаточной информации при создании любых объектов
Откат
1. Ограниченные возможности осуществления отката
3. Управление возможностью осуществления отката
2. Расширенные возможности осуществления отката
Правила модификации атрибутов безопасности
I. Модификация атрибутов безопасности администратором
3. Безопасная модификация атрибутов
2. Модификация атрибутов безопасности
уполномоченными пользователями
Доступ к атрибутам безопасности
1. Доступность атрибутов безопасности только для администратора
2. Доступность атрибутов безопасности для уполномоченных пользователей
Целостность информации в процессе хранения
1. Контроль целостности информации в процессе хранения.
2. Контроль целостности информации при хранении с учетом ее атрибутов безопасности.
Защита информации при передаче по внешним каналам
Базовая защита информации при передаче по внешним каналам
Целостность информации при передаче по внешним каналам
1. Обнаружение нарушений целостности при передаче информации
2. Восстановление информации получателем
3. Повторная передача информации
4. Идентификация и аутентификация
Управление параметрами аутентификации пользователей
1. Инициализация параметров аутентификации пользователей
2. Базовое управление параметрами аутентификации пользователей
3. Расширенное управление параметрами аутентификации пользователей
Защита параметров аутентификации пользователей
1. Базовая защита параметров аутентификации пользователей
2. Расширенная защита параметров аутентификации пользователей
Реакция на неудачные попытки аутентификации
1. Базовая обработка неудачных попыток аутентификации
2. Управление реакцией на неудачные попытки аутентификации
Управление атрибутами безопасности пользователей
1. Инициализация атрибутов безопасности пользователей
2. Базовое управление атрибутами безопасности пользователей
3. Расширенное управление атрибутами безопасности пользователей
Набор атрибутов безопасности пользователей
Индивидуальные и групповые атрибуты безопасности пользователей
Уникальные индивидуальные атрибуты безопасности пользователей
Генерация и проверка ключей и паролей
1. Выбор и проверка ключей и паролей
2. Генерация и проверка ключей и паролей
Аутентификация пользователей
аутенти
работы
1. Базовые механизмы аутентификации пользователей
5. Применение различных механизмов в соответствии с политикой аутентификации
7. Аутентификация по за
просу
8. Отложенная
аутентификация
9. Возможность изменения
состава
средств
аутентификации в
процессе
работы
2.Одноразовые механизмы
аутентификации ключи
3. Аутентификация с
контролем
целостности
параметров
аутентификации
4. Применение
нескольких
механизмов
аутентификаций
6. Настраиваемые механизмы
аутентификации
Идентификация пользователей
1. Базовые механизмы идентификации пользователей
3. Отложенная идентификация пользователей
2. Обеспечение уникальности идентификаторов пользователей
Соответствие атрибутов безопасности пользователей и субъектов, представляющих их в системе
1. Поддержка соответствия между атрибутами безопасности пользователей и субъектов, представляющих их в системе
5. Конфиденциальность доступа к системе
Анонимность сеансов работы с системой
Анонимность сеансов пользователей
2. Анонимность пользователей при взаимодействии со средствами защиты
Использование псевдонимов
1. Использование псевдонимов для учета действий анонимных пользователей
2. Поддержка возможностей для средств защиты восстановления по псевдониму личности пользователя
3. Использование определенных правил образования псевдонимов
Невыводимость характеристик пользователя
Невозможность, определения пользователя, предпринимающего теили иные действия
Ненаблюдаемосгь сеансов работы с системой
1. Невозможность определения использования объекта или ресурса
2. Возможность определения использования объекта или ресурса только авторизованным администратором
6. Безопасность защиты
Тестирование аппаратно-программной платформы
1. Наличие средств тестирования аппаратно-программной платформы
2. Проведение тестирования аппаратно-программной платформы во время загрузки
3. Тестирование аппаратно-программной платформы в процессе работы
Защита от сбоев
1. Сохранение безопасного состояния в случае возникновения сбоев
Обеспечение взаимодействия средств защиты
1. Обеспечение заданного уровня готовности средств защиты к взаимодействию
Обеспечение конфиденциальности при взаимодействии средств защиты
Обеспечение конфиденциальности при передачи информации между среда вами защиты
Обеспечение целостности при взаимодействии средств защиты
1. Обнаружение модификации передаваемой информации при взаимодействии средств защиты
2 Обнаружение модификации передаваемой информации при взаимодействии средств защиты и ее восстановление
Защита информационного обмена между средствами защиты
1 Базовые средства защиты информационного обмена между средствами защиты
2 Защита информационного обмена между средствами защиты на основании атрибутов передаваемой информации
3. Контроль целостности информации при взаимодействии средств защиты
Физическая защита
1. Пассивное обнаружение атак на физическом уровне
2. Уведомление администратора об атаках на физическом уровне
3. Противодействие атакам на физическом уровне
Безопасное восстановление после сбоев
1. Ручное восстановление после сбоев
4 Восстановление после сбоев с возможностью отката
2 Автоматическое восстановление после сбоев
3. Автоматическое восстановление после сбоев с минимизацией потерь информации
Отзыв атрибутов безопасности
1. Базовые средства отзыва атрибутов безопасности
2. Обеспечение немедленного отзыва атрибутов безопасности
Распознавание повторных передач информации и имитации событий
1. Распознавание повторных передач информации и имитации событий
Мониторинг взаимодействии
1. Тотальный мониторинг взаимодействия
Старение атрибутов безопасности
1. Отмена полномочии по истечении определенного периода времени
Разделение доменов
1. Выделение отдельного домена для средств защиты
2. Выделение отдельных доменов для процедур, осуществляющих мониторинг взаимодействий
3 Выделение необходимого числа доменов в соответствии с политикой безопасности
Обеспечение синхронизации
1. Одностороннее подтверждение о приеме информации
2. Взаимное подтверждение обмена информацией
Отсчет времени
1. Точный отсчет времени
Модификация ПО средств защиты
1. Защита целостность и исполняемого кода средств защиты
Разделение информации
1. Корректность использования информации средствами защиты
Репликация информации
1. Согласованность копий
Управление безопасностью
1. Базовые средства управления безопасностью
2. Выделение роли администратора безопасности
3. Выделение нескольких ролен администраторов безопасности с определенным кругом обязанностей
4. Точно определенные роли администраторов и их обязанности
Руководство Безопасностью
1. Механизмы руководства безопасностью
Самотестирование
1. Самотестирование по запросу
2 Самотестирование во время загрузки
3 Самотестирование в процессе функционирования
Защита средств управления безопасностью
Наличие методики управления безопасностью
2 Средства управления безопасностью, ограничивающие функции администратора безопасности
3. Гибкие средств управления безопасностью позволяющие администратору безопасности управлять ограничениями своих функций
7. Контроль за использованием ресурсов
Отказоустойчивость
1. Обеспечение отказоустойчивости с возможной деградацией функции системы
2. Обеспечение отказоустойчивости без деградации функции системы
Обслуживание на основе приоритетов
1. Поддержка приоритетного обслуживания для ограниченного подмножества ресурсов системы
3. Управление приоритетным обслуживанием
2. Поддержка приоритетного обслуживания для всех ресурсов системы
Распределение ресурсов
1. Поддержка квот ограничивающих потребление ресурсов системы
3. Управление квотами для индивидуальных пользователей и групп
2. Поддержка квот ограничивающих потребление ресурсов системы и резервирующих для каждого пользователя гарантированный минимум ресурсов
8. Контроль доступа к системе
Ограничения на использование пользователями атрибутов и субъектов
1. Ограничения на использование атрибутов и субъектов
Ограничение числа одновременных сеансов
1. Базовые средства ограничения числа одновременных сеансов
2 Ограничение числа одновременных сеансов в зависимости от атрибутов пользователя
Блокировка сеанса работы
1. Автоматическая блокировка сеанса работы
2. Блокирование сеанса пользователем.
3 Автоматическое завершение сеанса работы
Объявления, предупреждения, приглашения и подскажи
1. Объявления, предупреждения, приглашения и подсказки установленных по умолчанию
2. Модифицируемые объявления, предупреждения, приглашения и подсказки
Протокол сеансов работы пользователей
1. Протоколирование сеансов работы пользователей
Управление параметрами сеансов
1. Базовые средства управления параметрами сеансов
Ограничения на сеансы работы
1. Конфигурирование сеансов работы
9. Обеспечение прямого взаимодействия
Прямое взаимодействие между компонентами ИТ-продукта
1. Обеспечение прямого взаимодействия между компонентами ИТ-продукта
Прямое взаимодействие с пользователями
1 Обеспечение прямого взаимодействия с пользователями
Требования адекватности
1. Управление конфигурацией
Автоматизация управления конфигурацией
1. Частичная автоматизация управления конфигурацией
2 Полная автоматизация управления конфигурацией
Возможности управления конфигурацией
1 Ограниченные возможности управления конфигурацией
2 Применение авторизации при управлении конфигурацией
3. Генерация версий и процедура их приемки
4. Расширенные возможности управления конфигурацией
Область управления конфигурацией
1. Ограниченное применение управления конфигурацией
2. Отслеживание изъянов в средствах безопасности
3 Управление конфигурацией инструментальных средств разработки
2. Дистрибуция
Поставка
1. Регламентированная процедура поставки
2. Обнаружение искажений в процессе поставки
3. Защита от искажении в процессе поставки
Установка, настройка, запуск
1. Регламентированные процедуры установки, настройки, запуска
2. Поддержка протокола генерации
3. Адекватность реализации
Общие функциональные спецификации
Соответствие общих функциональных спецификации политике безопасности
2 Реализация общими функциональными спецификациями неформальные модели политики безопасности
3. Реализация общими функциональными спецификациями полуформальной модели политики безопасности
4. Реализация общими функциональными спецификациями формальной моле т политики безопасности
5. Описание интерпретации модели безопасности общими функциональными спецификациями
6 Формальная верификация адекватности реализации модели безопасности общими функциональными спецификациями
Архитектура защиты
1. Описание архитектуры защиты
2. Соответствие архитектуре защиты политике безопасности
3. Полуформальное определение архитектуры защиты
4. Полуформальное разъяснение архитектуры защиты
5. Формальное определение архитектуры защиты
Форма реализации
1. Предоставление описании реализации ограниченного подмножества средств защиты
2. Представление описании реализации всех средств защиты
3. Структурированное представление описании реализации средств защиты
Внутренняя структура средств защиты
1. Модульность
2 Иерархичность
3. Минимизация сложности
Частые спецификации функции защиты
1. Неформальные частые спецификации функции защиты
2. Полуформальные частые спецификации функции защиты
3. Формальные частые спецификации функции защиты
Соответствие спецификации и архитектуры требованиям безопасности
1. Неформальное доказагельство соответствия
2. Полуформальное доказательство соответствия
3. Формальное доказательство соответствия
4. Документация
Руководство администратора
1. Руководство администратора
Руководства пользователя
1. Руководства пользователя
5. Процесс разработки
Безопасность среды разработки
1. Применение мер безопасности в ходе разработки
2. Подтверждение мер безопасности, применяемых в ходе разработка
Исправление ошибок и ликвидация изъянов
1. Базовые средства учета ошибок и изъянов
2. Процедуры и средства обнаружения ошибок и изъянов
3. Применение средств ус гранения ошибок и изъянов
4. Регулярное применение средств устранения ошибок и изъянов
Технология разработки
1 Определенная разработчиком технология разработки
2 Использование стандартизованной технологии разработки
3. Использование политики разработки, поддающейся анализу и оценке
Средства разработки
1. Использование заданного набора средств разработки
2 Соответствие ограниченного подмножества средств разработки определенному стандарту
3 Соответствие всех средств разработки определенному стандарту
Полнота тестирования
1 Неформально подтвержденная полнота тестирования
2. Строго подтвержденная полнота тестирования
3. Всеобъемлющее тестирование
Глубина тестирования
1. Тестирование функциональных спецификаций
2. Тестирование архитектуры
3. Тестирование спецификаций средств защиты
4 Тестирование реализации средств защиты
Методика тестирования
1. Функциональные тесты
Независимое тестирование
1. Подготовка продукта к независимому тестированию
2. Избирательное независимое тестирование
3. Полное независимое тестирование
7. Оценка уязвимости
Анализ скрытых каналов
1. Анализ скрытых каналов
2. Систематический анализ скрытых каналов
3. Исчерпывающий анализ скрытых каналов
Анализ возможностей неправильного использования средств защиты
1. Анализ очевидных возможностей неправильного использования средств зашиты
2. Независимый анализ возможностей неправильною использования средств защиты
Анализ возможностей преодоления средств защиты
1. Оценка стойкости средств защиты
Анализ продукта на наличие изъянов защиты
1. Проведение анализа продукта на наличие изъянов защиты разработчиком
2. Независимый анализ продукта на наличие изъянов защиты
3. Относительная сопротивляемость продукта внешним воздействиям
4. Высокая сопротивляемость продукта внешним воздействиям
Для представления результатов классификационного анализа «Единые критерии» содержат семь стандартизованных уровней адекватности (п. 2.10.4.2). Распределение требований адекватности по уровням представлено в таблице, в ячейках которой указаны номера категорий требований адекватности, которым должен удовлетворять продукт для присвоения ему соответствующего уровня адекватности.
Требования адекватности
Номера уровней адекватности
1
2
3
4
5
6
7
1. Управление конфигурацией
Автоматизация управления конфигурацией
1
1
2
2
Возможности управления конфигурацией
1
1
2
3
3
4
4
Область применения управления конфигурацией
1
2
3
3
3
2. Дне грибу цня
Поставка
Установка. Настройка. запуск
1
1
1
1
1
1
3. Адекватность реализации
Общие функциональные спецификации
1
1
1
2
4
5
6
Архитектура защиты
1
2
2
3
4
5
Форма реализации
1
2
3
3
Внутренняя структура средств защиты
1
2
3
Частые спецификации средств защиты
1
1
2
2
Соответствие спецификаций и архитектуры требованиям безопасности
1
1
1
1
2
2
3
4. Документация
Руководства администратора
1
1
1
1
1
1
1
Руководства пользователя
1
1
1
1
1
1
1
5. Процесс разработки
Безопасность среды разработки
1
1
1
2
2
Исправление ошибок и ликвидация изъянов
Технология разработки
1
2
2
3
Средства разработки
1
2
3
3
6. Тестирование
Полнота тестирования
1
2
2
2
3
3
Глубина тестирования
1
2
2
3
3
4
Методика тестирования
1
1
1
1
1
1
Независимое тестирование
1
1
2
2
2
2
3
7. Оценка уязвимости
Анализ скрытых каналов
1
2
2
Анализ возможностей неправильного использования средств защиты
1
2
2
2
2
Анализ возможностей преодоления средств защиты
1
1
1
1
1
1
Анализ продукта на наличие изъянов защиты
1
1
2
3
4
4
Приложение IV
Статистика нарушений безопасности компьютерных систем
(заимствовано из Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S. Choi.
A Taxonomy of Computer Security Flaws, with Examples)
Данная подборка материалов ни в коей мере не может претендовать на исчерпывающее описание всех известных нарушений безопасности ВС и приведена здесь исключительно для иллюстрации таксономии причин возникновения ИЗ и ее обеспечения практическими примерами. Приведенные данные охватывают широкий спектр как различных типов вычислительных систем, так и различных видов нарушений безопасности, что необходимо для выявления основных закономерностей возникновения и проявления ИЗ.
Все эти примеры отражают реально имевшие место нарушения безопасности и реализованные атаки на вычислительные системы. В каждом примере указывается тип вычислительной системы, в которой имело место нарушение безопасности, кратко описываются ее особенности и слабые стороны, использованные для осуществления атаки, суть нарушения безопасности и его последствия. Примеры расположены в хронологическом порядке. Группам примеров, относящихся к одной вычислительной системе, предшествует краткое описание ее структуры и принципов функционирования, позволяющее понять реализованную в ней концепцию зашиты.
Индексы примеров соответствуют системе обозначений, принятой в [1] (см. литературу к главе 3). В начале обозначения присутствует префикс, определяющий тип ВС, за которым следует порядковый номер примера для данной системы. В приложение вошли не все приведенные в [1] случаи, а только наиболее характерные представители различных классов, в связи с чем некоторое номера пропущены. В главе 3 отражены результаты, полученные при анализе всей доступной информации, в том числе и не включенной в данное Приложение.
Система IBM 360/370
В архитектуре систем IBM 360/370 существуют два состояния процессора — режим выполнения прикладной программы, в котором запрещено выполнение подмножества привилегированных команд (загрузка PSW, инициализация ввода/вывода и т.п.), и режим супервизора, в котором возможно выполнение любых команд. Попытка выполнения прикладным процессом привилегированной команды вызывает прерывание, вызов привилегированных команд из прикладных (непривилегированных) процессов осуществляются посредством специального вызова — Supervisor Call (SVC).
Оперативная память разделена на страницы, каждая из которых ассоциирована с четырехбитным ключом доступа. Обычно для отведенных пользователю страниц памяти значение ключа доступа равно 8, в то время как значение ключей для областей памяти, используемых самой системой, лежит в интервале от 0 до 7. Процесс, выполняющийся в области памяти с ненулевым значением ключа, имеет неограниченный доступ к другим областям памяти с тем же (ключом доступа. Кроме того, процесс может читать области памяти с другими значениями ключей, если только они не помечены как защищенные. Попытка записи в область памяти с другим значением ключа приводит к возникновению прерывания. Процессы операционной системы выполняются в областях памяти со значением ключа, равным 0. Такие процессы имеют неограниченный доступ ко всем областям памяти вне зависимости от их ключей и статуса защищенности.
Подсистема ввода/вывода состоит из т. н. каналов, которые по сути представляют собой специализированные программируемые микрокомпьютеры, осуществляющие обмен данными между памятью и внешними устройствами. С каналом ввода/вывода может быть связана специальная программа, которая выполняется процессором ввода/вывода и осуществляет управление обменом данными между оперативной памятью и внешним устройством. Такие программы после их инициализации функционируют независимо от основного процессора и имеют неограниченный доступ к оперативной памяти. Таким образом, управление процессом ввода/вывода и контроль доступа возлагается на программу, управляющую каналом ввода/вывода.
В многозадачной системе MVS имеется опция разделения времени Time Sharing Option (TSO), которая позволяет одновременно нескольким пользователям выполнять команды с интерактивных терминалов. В MVS существует категория привилегированных процессов, объединенных понятием авторизованные программы (Authorized Program Facility — APF). Эти программы занимают области памяти с ключом доступа, равным 7. Им предоставлены возможности, недоступные остальным прикладным процессам, в частности перевод процессора в режим супервизора. Данные процессы рассматриваются как расширение операционной системы и считаются гарантированно безопасными (trustworthy).
Система IBM 370 является развитием системы 360 и представляет собой монитор виртуальных машин. На ее основе министерством обороны США разработана система KVM/370, обеспечивающая более высокий уровень защиты информации. Университетом штата Мичиган разработана система MTS (Michigan Terminal System), специально предназначенная для работы как в пакетном, так и в интерактивном режиме.
Индекс: I1. Система: IBM 360
Источник информации: A. S. Tanenbaum. Operating System Design and Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.
В системе IBM 360 имеется возможность нарушения контроля доступа к файлам. В этой системе для обращения к некоторым файлам требуется ввести соответствующий пароль, причем процедура проверки правильности пароля организована следующим образом: в систему вводится имя файла и пароль, а затем, в случае корректности пароля, осуществляется открытие файла. Однако существует возможность подмены имени файла между проверкой подлинности пароля и открытием файла. Для этого можно использовать фоновый процесс, который имеет возможность записи в системные области памяти, например процесс обмена с накопителями на магнитной ленте. Пользователь выдает запрос на доступ к файлу, пароль которого ему известен. Система проверяет га-роль и разрешает доступ. Однако после проверки, но до открытия файла, фоновый процесс может заменить имя файла, что приведет к получению доступа не к тому файлу, для которого проверялся пароль, а к другому, несмотря на то что пароля для него пользователь не знает.
Индекс: 14. Система: IBM VM/370
Источник информации: С. R. Attanasio, P. W. Markstein, R. J. Phillips «Penetrating at Operating System: a study of VM/370 integrity», IBM System Journal, 1976, PP.102—116.
При программировании каналов ввода/вывода на этапе трансляции управляющая программа подвергается статическому анализу на допустимость используемых инструкций и обращений к областям памяти, однако при этом предполагается, что каждая команда имеет фиксированную длину и выровнена по границе слова. Фактически такие программы могут включать в себя команды переменной длины, не обязательно выровненные по границе слова, что при наличии команды перехода на произвольный адрес позволяет организовать передачу управления «в середину» команды. Этот трюк приводит к выполнению других команд, состоящих из фрагментов исходных и не подвергавшиеся трансляции и проверке. Соответствующим образом составив подобную программу, пользователь может запустить параллельный основным вычислениям процесс (как было отмечено выше, программы ввода/вывода имеют доступ к любым областям памяти) и осуществить неконтролируемый доступ к информации.
Индекс: 16. Система: IBM MVS (TSO)
Источник информации: R. Paans, G. Bones. «Surreptitious security violation in the MVS operating system», Security, IFIP/Sec, Holland, 1983, pp. 95—101.
Существует возможность использования TSO для запуска привилегированного процесса. Для этого необходимо запустить из TSO фоновый процесс и вызвать любую программу, входящую в APF. Фоновый пользовательский процесс сможет обнаружить факт начала выполнения APF-процесса по изменению значения ключа общей области памяти (для привилегированных процессов оно меньше 8). С этого момента пользовательский фоновый процесс является привилегированным, так как обе программы будут выполняться в одном и том же адресном пространстве. После этого он может остановись APF-процесс и получить все привилегии и возможности управления системой.
Индекс: 17. Система: IBM MVS
Источник информации: R. Paans, G. Bones. «Surreptitious security violation in the MVS operating system», Security, IFIP/Sec , Holland, 1983, pp. 101—105.
Коммерческие приложения, такие, как СУБД, часто должны устанавливаться в систему как APF и выполняться как привилегированные. Считается, что такие приложения являются доверенными и не используют предоставленные привилегии для нарушения защиты и игнорирования установленных требований безопасности. Однако в ряде случаев (в первоисточнике приведен ряд примеров) доверенные приложения предоставляют пользователю возможность использования предоставленных им привилегий, что дает ему возможность нарушать безопасность системы. Данный пример перекликается с имеющейся в ОС Unix возможностью запустить процесс с правами супервизора (пример U9).
Индекс: 19 Система КVM/370
Источник информации: М. Schaefer, В. Gold, R. Linde, and J. Schield, «Program Confinement in KVM/370. Proc. of ACM National Conf., Oct., 1977.
Система KVM/370 выделяет каждой виртуальной машине квант времени физического процессора. Причем виртуальная машина может использовать весь отведенный ей квант или освободить процессор раньше срока. С учетом того, что виртуальная машина имеет доступ к часам реального времени, существует возможность организовать скрытый канал передачи информации от одной виртуальной машины к другой путем кодирования информации величиной временного интервала, использованного виртуальной машиной.
Индекс: МТ1. Система: MTS
Источник информации: В. Hebbard et al. «A penetration analysis of the Michigan Terminal System». ACM SIGOPS Operating Systems Review 14, Jan. 1980, pp. 7 — 20.
Пользователь может посредством манипулирования значениями параметров системных вызовов заставить систему изменить ряд критичных параметров и тем самым отключить механизмы управления безопасностью и получить полный контроль над системой. Некоторые подпрограммы ядра системы, осуществляющие модификацию переданных им параметров, используют для их передачи механизм косвенной адресации. В каждой функции ядра перед осуществлением каких-либо действий проверяется принадлежность полученного параметра-адреса пространству пользовательского процесса, в противном случае запрос пользователя отвергается. Однако пользователь может обойти этот контроль посредством задания параметра, который содержит адрес, принадлежащий самой области передачи параметров. При этом можно добиться того, что в результате вызова параметры будут модифицированы и в них окажутся адреса важных переменных из системной области, что дает возможность пользователю изменить их при помощи других системных вызовов.
Операционная система Multics
Операционная система Multics изначально применялась на специально разработанных компьютерах GE-645 фирмы General Electric. Позднее под управлением Multics функционировали компьютеры серии HIS 61,80. Аналогично системам IBM 360/370 аппаратное, обеспечение этих компьютеров поддерживало два режима работы: т. н. master режим, в котором являлись допустимыми все команды, и slave режим, в котором определенные команды были запрещены. Система обеспечения безопасности включала в себя 8 колец защиты, которые в компьютерах GE-645 были реализованы программно, а на платформе HIS 6180 — аппаратно. Кольцо 0 являлось наиболее привилегированным, предполагалось, что в нем может размещаться только код операционной системы.
Индекс: MU1 Система: Multics
Источник информации: A.S. Tanenbaum. «Operating System Design and Implementation». Prentice-Hall, Englewood Cliffs, NJ, 1987.
Система Multics в режиме пакетной обработки информации при считывании с перфокарт не поддерживала идентификацию/аутентификацию пользователя. Это позволяло любому пользователю записывать файлы с информацией, введенной с перфокарт, в любые каталога Поскольку пути поиска команд многих пользователей включали их собственные каталоги, это давало возможность внедрить в систему троянскую программу.
Индекс: MU2. Система: Multics
Источник информации: Р. A. Karger, R. R. Schell. «Multics Security Evaluation: Vulnerability Analysis», ESD-TR-74-193, Vol. II, June 1974.
В случае, когда программа, выполняющаяся в менее привилегированном кольце защиты, передает параметры программе, находящейся в более привилегированном кольце, последняя должна удостовериться, что вызвавшая ее программа имеет права доступа на чтение или запись переданных ей параметров. Поскольку разделение колен защиты в системах на базе компьютеров GE-645 было реализовано программно, эту функцию осуществляла специальная процедура. Однако данная процедура неправильно обрабатывала один из видов косвенной адресации системы GE-645, и проверка прав доступа не всегда осуществлялась корректно, что позволяло непривилегированным программам получить доступ к данным, обрабатываемым в привилегированных кольцах защиты.
Индекс: MU3. Система: Multics
Источник информации: Р. A. Karger, R. R. Schell. «Multics Security Evaluation: Vulnerability Analysis», ESD-TR-74-193, Vol.II, June 1974.
В ранних версиях Multics регистр указателя стека (sp) мог быть модифицирован только в режиме master. Когда Multics получила широкое распространение, это было признано неудобным, и в систему были внесены изменения, допускавшие изменение регистра sp во всех режимах. Однако в системе остался не исправлен ряд фрагментов кода, предполагавших, что модификация регистра sp возможна только в режиме master. Это нарушило интерфейс между master и slave режимами и позволило использовать эти фрагменты кода для осуществления несанкционированного доступа.
Индекс: MU9. Система: Multics
Источник информации: Р. A. Karger, R. R. Schell. «Multics Security Evaluation: Vulnerability Analysis», ESD-TR-74-193, Vol.II, June 1974.
С помощью программы тестирования аппаратно реализуемых механизмов защиты Multics (авторы назвали ее Subverter) была выявлена аппаратная ошибка в системе GE-645. Ошибка заключалась в следующем: если исполняемая команда вызывала команду, находящуюся в самом начале другого сегмента, которая использовала индексный регистр, но не устанавливала базу для индексации, то эта команда выполнялась без какого-либо контроля со стороны аппаратных средств. Благодаря этой возможности пользователь мог легко получить контроль над всей системой.
Операционная система Burroughs 6700
Механизмы защиты ОС Burroughs были основаны на| том, что пользователь не мог создать собственную прикладную программу, кроме как с использованием специально разработанных доверенных компиляторов с языков высокого уровня, которые осуществляли контроль за его действиями уже на стадии компиляции.
Индекс: В1. Система: Burroughs 6700
Источник информации: A.L. Wilkinson et al. «A penetration analysis of a Burroughs large system», ACM SIGOPS Operating Systems Review 15, Jan. 1981, pp. 14—25.
В системах Burroughs 6700 аппаратный контроль доступа к памяти осуществлялся с помощью проверки соответствия используемых программой адресов с диапазоном, задаваемым значениями регистров границ, которые программы самостоятельно устанавливали для себя. Данные регистры для каждой программы можно установить однократно без возможности их последующего изменения. Пользователь, написавший программу которая могла бы управлять значениями данных регистров, получил бы полный контроль над системой. Для предотвращения такой ситуации система содержала соответствующий механизм, состоявший в том, что могли выполняться только программы, созданные доверенными компиляторами, которые гарантировали не нарушающее защиту использование регистров границ. Каждому файлу в системе был поставлен в соответствие определенный тип. Системный загрузчик проверял соответствие программ типу файлов, создаваемых доверенным компилятором. Устанавливать тип файла непривилегированному пользователю было запрещено.
Таким образом, пользователь принципиально мог создать файл, который содержал бы исполняемый код, переустанавливающий значения регистров границ и забиравший на себя управление системой, но до тех пор, пока этому файлу не был назначен соответствующий тип, он не мог быть загружен в память и выполнен.
В системе присутствовала утилита копирования файлов с/на магнитную ленту, в которой была допущена ошибка. Эта утилита позволяла изменять тип файлов, находящихся на ленте. Это означало, что пользователь мог создать файл, содержащий соответствующий код, сбросить его на ленту, поменять его тип и скопировать его обратно, после чего запустить на выполнение и получить контроль над системой.
Система Univac 1108
Компьютеры Univac 1108, предоставлявшие собой высокопроизводительные мейнфреймы, в 70-х годах обеспечивали вычислительными ресурсами исследовательские лаборатории и университеты. Их основная память была поделена на два банка, каждый из которых состоял из совокупности 512-байтных элементов. Адресное пространство программ также состояло из двух банков: банк I (банк инструкций) содержал код программы, банк D (банк данных) — данные. Аппаратные средства защиты были организованы таким образом, что программы могли либо использовать оба банка как для чтения, так и для записи, либо установить запрет на запись в оба банка.
Индекс: UN1. Система: Univac 1108/Exec 8
Источник информации: D. Stryker. «Subversion os a «Secure» Operating System», NRL Memorandum Report 2821. June 1974.
Операционная система мейнфреймов Univac —Exec 8 поддерживала одновременное использование несколькими пользователями ряда системных утилит (редакторы. компиляторы и СУБД) с помощью их реализации в виде процессов с повторным вхождением (re-entrant process, или REPs). Эти процессы хранили данные пользователей в принадлежащих им D-банках и совместно использовали одну копию исполняемого кода, находящуюся в общем 1-банке, который был защищен от записи.
Кроме того, Exec 8 содержала схему обработки ошибок, которая позволяла любой программе перехватывать прерывание, генерируемое при возникновении ошибки (например, при делении на ноль или выходе за границы памяти). Когда установленная пользователем процедура обработки ошибок получала управление, она получала доступ к контексту возникновения ошибки. Системные процессы должны были устанавливать свои собственные процедуры обработки ошибок, однако многие процессы типа REP этого не делали. Это позволяло злоумышленнику установить собственную программу обработки ошибок, создать ошибочную ситуацию в REP-процессе (например, организовав для него D-банк слишком маленького размера) и перехватить прерывание. Получившая управление пользовательская программа обработки ошибок получала возможность доступа как по чтению, так и по записи к банкам I и D процесса типа REP. Это означало, что она могла модифицировать его код, который имел доступ к D-банкам многих пользователей, — например, внедрить «троянского коня», копирующего чужие данные. Несмотря на то что подобная «троянская» программа будет работать только до тех пор, пока существует соответствующий процесс, возможность даже временного получения злоумышленником информации от процесса типа REP является чрезвычайно опасной, так как дает ему неограниченный доступ к данным всех остальных пользователей этого процесса.
Системы DEC PDP-10 и VAX
Системы DEC PDP-10 были компьютерами средней производительности, ставшими стандартным средством поддержки распределенной интерактивной обработки данных в 70-х годах. Эти системы функционировали под управлением ОС TENEX, разработанной фирмой BBN. Компьютеры DEC VAX могли функционировать под управлением операционной системы VMS, Unix-подобной системы Ultrix и под управлением операционных систем, разработанных самой DEC. В системе VMS имелся т. н. файл авторизации, в котором находились записи о правах и привилегиях пользователей. Пользователь, который получил доступ к этому файлу, получал неограниченные возможности управления системой.
Индекс: DT1. Система: TENEX
Источники информации: A. S. Tanenabum. «Operating System Design and Implementation». Prentice-Hall, Englewood Cliffs, NJ, 1987., и R. P. Abbott et al, «Security Analysis and Enhancements of Computer Operating Systems, Final Report of RISOS Project». National Bureau of Standards NBSIR-76-1041, Apr. 1976, pp. 49—50.
Как и многие другиеОС, TENEX использовала систему паролей для контроля доступа к файловой системе. Процедура проверки правильности пароля была реализована таким образом, что позволяла злоумышленнику подобрать пароль за небольшое количество попыток. Проверка пароля осуществлялась символ за символом, причем выборка символов осуществлялась из области памяти пользовательского процесса, а как только обнаруживался неверный символ — проверка прекращалась. Так как пользователь контролировал область памяти, откуда считывались символы пароля, он мог использовать для радикального ускорения процесса перебора механизм подкачки виртуальных страниц памяти. Для этого вариант пароля помещался на границу виртуальной страницы таким образом, что подбираемый символ размещался в ее последнем байте, а следующая страница отсутствовала в физической оперативной памяти. После этого, если при проверке пароля возникала ситуации полгрузки страницы, это означало, что символ подобран верно (процедура проверки обращалась к следующему символу только в том случае, если текущий был верен), и противном случае процесс подбора этого символа продолжался. После подбора первого символа можно было перейти к подбору второго и т. д. Таким образом, вместе того чтобы проверять для подбора пароля, состоящего из N символов алфавита мощностью М, MN комбинаций, злоумышленник мог проверить всего M*N комбинаций. Это полностью дискредитировало всю парольную систему защиты данной ОС.
Индекс: D1. Система: DEC VMS
Источник информации: «VMS code patch eliminates security breach». Digital Review, June 1, 1987, p. 3.
Данный случай представляет особый интерес, так как система DEC VMS была тщательным образом исследована на предмет наличия изъянов в средствах защиты. В новой версии системы был добавлен системный вызов, предоставлявший уполномоченным пользователям возможность модификации файла авторизации. Проверка прав инициировавшего запрос пользователя на модификацию этого файла выполнялась на основе анализа содержимого этого же файла. Поэтому в ходе обработки этого запроса ОС первым делом открывала файл авторизации и считывала из него соответствующую информацию. Если пользователь не имел соответствующих прав, выполнение запроса прекращалось. Однако при задании определенных параметров, несмотря на то что неуполномоченный пользователь получал отказ, файл авторизации оставался открытым и доступным для пользователя. Злоумышленник, знавший об этом, мог присвоить себе все права по управлению системой.
Операционная система Unix
Операционная система Unix разрабатывалась лучшими специалистами в области создания ОС с одной целью — обеспечить удобную интерактивную среду обработки данных на компьютерах малой производительности. Поэтому на ранних стадиях разработки вопросам безопасности уделялось относительно мало внимания. Unix поддерживает иерархическую файловую систему с контролем доступа, основанным на понятии «владельца» файла. С каждым файлом связаны идентификаторы владельца и группы, а также атрибуты доступа. Эти идентификаторы можно изменить с помощью команд chown, chgrp. Атрибуты файла определяют права доступа к нему. Все пользователи подразделяются на три категории:
· владелец файла, его идентификатор совпадает с идентификатором владельца файла;
· члены группы владельца, их идентификатор группы совпадает с идентификатором группы файла;
· прочие — все остальные.
С помощью назначения соответствующих атрибутов доступа можно регламентировать доступ (чтение, запись, выполнение) для каждой категории пользователей. Изменить права доступа может только владелец файла либо root. Пользователь с идентификатором root является администратором системы и имеет неограниченные полномочия. Его действия не ограничиваются механизмами контроля доступа.
Все пользователи системы зарегистрированы в специальном файле /etc/passwd, В нем указаны имена пользователей, их идентификаторы и пароли в зашифрованном виде. Всем пользователям, кроме root, разрешен доступ к этому файлу только по чтению. Если злоумышленник получил возможность записи в этот файл, он может создать пользователя с полномочиями root и получить полный контроль над системой.
Когда пользователь запускает процесс, как правило, ему присваивается идентификатор этого пользователя, что дает процессу возможность действовать от имени данного пользователя и с его правами доступа. Этому механизму недостает гибкости, поэтому для того, чтобы пользователи могли, например, осуществлять модификацию файла /etc/passwd в пределах относящейся к ним записи, был введен атрибут SUID. Наличие у программы этого атрибута означает, что при ее запуске соответствующий процесс будет иметь идентификатор и права не запустившего его пользователя, а пользователя, являющегося владельцем файла, содержащего программу. Как правило, этот атрибут устанавливается у системных утилит, владельцем которых является root, требующий для своей работы его полномочий. Например, утилита setpass, позволяющая пользователю изменять свои пароль, должна иметь возможность осуществлять запись в файл /etc/passwd. При этом безопасность системы полностью зависит от корректности реализации подобных! программ, поскольку они позволяют любому пользователю выйти за рамки своих полномочий.
Индекс: U2. Система: Unix
Источник информации: A. S. Tanenbaum. Operating System Design and Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.
Присутствующая во многих версиях Unix утилита lpr помещает файл в очередь печати, а при указании опции «r», еще и удаляет его. В ранних версиях Unix при использовании указанной опции проверка наличия полномочий на удаление заданного файла у пользователя, вызвавшего утилиту lpr, отсутствовала. Это позволяло пользователю удалить любой файл, в том числе и файл /etc/passwd, после чего ни один пользователь не мог войти в систему.
Индекс: U3. Система: Unix
Источник информации: А. S. Tanenbaum. Operating System Design and Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.
В ряде версий Unix программа создания каталогов mkdir имела атрибут SUID, а ее владельцем был root. Создание каталога происходило в две стадии. Сначала посредством специального системного вызова mknod для нового каталога выделялись необходимые ресурсы и его владельцем назначался root. После этого с помощью другого системного вызова chown владельцем нового каталога назначался пользователь, вызвавший mkdir. Поскольку эти два этапа не были реализованы как атомарные операции, у пользователей имелась возможность стать владельцем любого каталога и файла в системе, в том числе и файла /etc/passwd. Для этого было достаточно запустить mkdir как фоновый процесс и после выполнения первой стадии — создания каталога, приостановить его. После этого пользователь удалял созданный каталог и под тем же именем создавал ссылку {link) на файл паролей /etc/passwd. Затем пользователь инициировал возобновление выполнения утилиты mkdir, которая делала пользователя владельцем созданного каталога. Однако, так как каталог предварительно был подменен ссылкой на файл /etc/passwd, пользователь становился его владельцем. Далее, в соответствии со своими полномочиями владельца, он мог изменять этот файл, получая таким образом полный контроль над системой.
Индекс: U4. Система: Unix
Источник информации: А.V. Discolo, «4.2 BSD Unix security». Computer Science Department, University of California, Santa-Barbara, Apr. 1985.
Во многих версиях Unix команда sendmail позволяли неавторизованному пользователю прочитать любой файл в системе. Эта программа могла считывать свой параметры из файла, указанного пользователем, а в том случае, когда формат файла не соответствовал синтаксису команд sendmail, выводила на экран каждую строку, в которой встретилась ошибка.
Проверка полномочий пользователя на доступ к файлу параметров не осуществлялась, так как sendmail имела атрибут SUID, а ее владельцем был root, так что пользователь легко мог ознакомиться с содержанием любого файла, просто указав его в качестве файла параметров программы sendmail (очевидно, что вероятность соответствия строк интересующего пользователя файла синтаксису, принятому в sendmail, крайне мала).
Индекс: U5. Система: Unix
Источник информации: М.Bishop. «Security problems with the UNIX operating system». Computer Science Department, Purdue University, West Lafayette, Indiana, March. 1982.
Неправильное использование ограничений доступа к каталогам электронной почты приводит к возникновению возможности преодоления системы защиты. В ряде версий Unix почтовая программа после добавления нового сообщения к файлу, в котором хранятся поступившие сообщения, назначает владельцем этого файла пользователя, на имя которого поступило сообщение. При этом не производится никаких проверок его атрибутов. В дополнение к этому многие системы настроены таким образом, что каталоги, содержащие электронную почту пользователей, доступны по записи для всех пользователей. Это означает, что любой пользователь может удалить «почтовый ящик» пользователя root и заменить его копией командного интерпретатора с установленным атрибутом SUID и доступным для выполнения любым пользователем. После этого пользователь может послать на имя root любое сообщение. Программа, обслуживающая почту, добавит это сообщение в конец файла – «почтового ящика» и назначит ему нового владельца — root. Таким образом, в системе появится командный интерпретатор, с установленным атрибутом SUID, владельцем root, и доступный для выполнения любому пользователю.
Индекс: U7. Система: Unix
Источник информации: М. Bishop. «Security problems with the UNIX operating system». Computer Science Department, Purdue University, West Lafayette, Indiana, March,1982.
В Unix имеется утилита uux, реализующая удаленное выполнение ограниченного множества команд и программ. Командная строка, содержащая имя и параметры программы, которую необходимо выполнить, передается программой mix на удаленную машину, где осуществляется ее анализ и проверка на принадлежность запускаемой программы к множеству доступных. Если анализ и проверка завершились успешно, порождается соответствующий процесс. В процедуре анализа командной строки содержалась ошибка, которая позволяла выполнять программы, не входящие в множество допустимых.
Разбор командной строки был организован следующим образом: утилита uux читала первое слово командной строки (имя команды), проверяла его, а затем пропускала (как аргументы и опции команды) все последующие символы до первого разделителя команд (признака конца команды). Затем производился разбор следующей команды и т. д. После окончания разбора вся строка целиком передавалась командному интерпретатору для выполнения. Но множество проверяемых разделителей команд было неполным, символы «|», «Λ», «;» учитывались, а «&» и «’» — нет. Таким образом, команды, следующие за неизвестным программе них разделителем. выполнялись, но не проверялись на принадлежность к множеству допустимых. Следовательно, пользователь мог осуществить удаленный запуск любых программ и выполнение любых команд в обход контроля них.
Индекс: U10. Система: Unix
Источник информации: Е. Н. Spafford. «Crisis and Aftermath», Comm. of the ACM 32, June 1989, PP 678 — 687.,
Во многих версиях ОС Unix программа sendmail распространялась с установленной по умолчанию отладочной опцией, позволявшей неавторизованным пользователям проникать в удаленные системы. Отладочный режим позволяет посылать сообщения, снабженные npoграммой-получателем, которая запускается на удалена ной машине и осуществляет прием сообщения. Эта возможность использовалась разработчиками для отладки программы и в коммерческой версии была оставлена по ошибке. Злоумышленник мог указать в качестве программы-приемника командный интерпретатор, а в текст сообщения включить соответствующие команды, что фактически превращало его в пользователя удаленной системы, несмотря на то что он не был в ней зарегистрирован. Известный вирус Р. Морриса использовал эту возможность для проникновения в удаленные системы.
Индекс: U11. Система: Unix
Источник информации: D. Gwyn. «UNIX-wizard digest», Vol. 6 No. 15, Nov. 1988.
Команда chfn системы Unix предоставляет пользователям возможность изменить имя, под которым они зарегистрированы в системе. Поскольку имя пользователя хранится в файле /etc/passwd, эта программа должна иметь возможность записи в этот файл. Для этого она имеет атрибут SUID, а ее владельцем является root. Само по себе изменение имени не несет никакой угрозы, но команда chfn не осуществляла проверку длины заданной пользователем строки символов. Пользователь, знающий об этом, мог создать очень большой входной буфер, при попытке записи которого окажется, что он не помещается на место прежней записи, и в файл /etc/passwd будет записана пустая строка. Пустая строка в этом файле интерпретируется как наличие в системе пользователя с пустыми именем и паролем, который обладает полномочиями root. Таким образом злоумышленник мог создать для себя идентификатор, обладающий максимальными привилегиями.
Индекс: U12. Система: Unix (4.3 BSD on VAX)
Источник информации: J. A. Rochlis, M. W. Eichin, «With microscope and tweezers: the worm from MITs perspective», Comm. ACM 32, June 1989, pp. 689—699.
Программа-демон fingerd имеющаяся в каждой Unix системе, предназначена для передачи удаленным пользователям информации о пользователях локальной системы. Ошибка в этой программе позволяла неавторизованному пользователю запускать на удаленной машине любой процесс. Данная программа содержала в себе фрагмент кода примерно следующего вида:
{
char buffer[100] ;
…
gets(buffer);
}
Проверка переполнения буфера не осуществлялась. Так как буфер размещался в стеке, то, создав в нем фрагмент кода и вызвав переполнение стека, можно заменить адрес возврата из процедуры таким образом, что управление будет передаваться на этот код. Посредством формирования соответствующего кода злоумышленник мог вынудить систему выполнить любую необходимую ему команду, в том числе запустить командный интерпретатор. Эта возможность наряду с отладочной опцией команды sendmail использовалась вирусом Р. Морриса.
Индекс: U14. Система: Unix (SunOS)
Источник информации: J. Purtilo, RISKS-FORUM Digest, Vol. 7 No. 2, June 1988.
Процесс-демон rpc.rexd обеспечивает в системе Unix поддержку удаленного выполнения программ. В реализации данной программой механизма идентификации присутствовала ошибка. Когда приходил запрос с удаленной системы на выполнение процесса, этот демон определял идентификатор пользователя, инициирующего запрос. Если это был пользователь root, запрос отвергался, так как root удаленной системы не имеет полномочий на локальной. Если это был не root, rpc.rexd проверял легальность для локальной системы идентификатора пользователя удаленной системы и в случае наличия в системе пользователя с таким идентификатором исполнял от его имени указанный процесс.
Эго означало, что пользователь, имеющий полномочия root в одной системе, мог создать пользователя с идентификатором, совпадающим с идентификатором пользователя удаленной системы, и запустить в удаленной системе процесс от имени и с полномочиями этого пользователя. Таким образом, злоумышленник, получивший контроль над одной из систем, мог получить доступ и к другим системам.
Персональные компьютеры
Распространенное системное программное обеспечение персональных компьютеров (ПК) характеризуется отсутствием средств защиты. В первую очередь это касается таких популярных систем, как DOS, Windows, Windows 95. Системы, при разработке которых было уделено хотя бы некоторое внимание проблеме защиты информации, выходят за рамки персональных и. как правило, служат в качестве сервисных ОС, предоставляющих пользователям тот или иной сервис. В качестве примера можно назвать Novel NetWare, Windows NT и многочисленные версии Unix для ПК (SCO, Linux, Solaris, QNX). Наиболее широко распространена информация о вирусных атаках и механизмах функционирования вирусов, использующих отсутствие в ОС, применяемых на ПК, даже минимальной зашиты. В качестве примера можно упомянуть публикацию авторов, посвященную этой теме [19] (литература к главе 3). В силу доступности информации по этому вопросу приводить здесь многочисленные факты нарушения безопасности в сие”. темах на базе ПК представляется нецелесообразным. Приведенные в таблицах третьей главы индексы примеров, связанных с нарушениями информационной безопасности ПК (IN1, РС1-РС4, МА1, МА2 СА1, \Т1), соответствуют индексам из [1] (литература к главе 3).
Специализированный Центр Защиты Информации и Кафедра Информационной Безопасности Компьютерных Систем Санкт-Петербургского Государственного Технического университета
предлагает:
· анализ безопасности прикладною и системного программного обеспечения и подготовку материалов для сертификации;
· разработку безопасных информационных систем:
· разработку безопасных сетевых решений для корпоративных сетей, в т. ч. подключение к Internet;
· оказание консультаций в области защиты информации, современных программных средств и современных сетевых решений;
· обучение по специальности 22.07 «Организация и технология защиты информации» (квалификация: инженер, бакалавр, магистр);
· краткосрочные курсы повышения квалификации администраторов безопасности;
· книги и учебные пособия по информационной безопасности.
оказывает услуги:
– восстановление работоспособности локальных сетей
Novell NetWare, UNIX и Windows NT в случае утери пароля:
восстановление информации, утерянной в результате компьютерных вирусов или сбоев;
– обнаружение и отражение удаленных атак в сетях Internet и Novell NetWare.
Наш адрес: 195251, Санкт-Петербург, Политехническая ул., д. 29, главное здание, ауд. 166, Тел./факс (812) 552-64-89
E-mail: [email protected] WWW: www.ssl.stu.neva.ru