Как построить защищенную информационную систему. Книга

Содержание Введение Глава 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 Dmitry@ssl.stu.neva.ru). Андрей Михайлович Ивашко — сотрудник Феде­рального Агентства Правительственной Связи и Инфор­мации при Президенте Российской Федерации (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]. Наши коллеги по Центру защиты информации опубликовали труд, в котором анализируются механиз­мы осуществления нарушений безопасности в сети Inter­net [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, Win­dows 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 Manage­ment System Interpretation» [9]). Эти документы содержат трактовку основных положений «Оранжевой книги» применительно к соответствующим классам систем, об­работки информации. Потеря актуальности рядом положений «Оран­жевой книги» вызвана прежде всего интенсивным раз­витием компьютерных технологий и переходов с мэйнфреймов (типа вычислительных комплексов IBM-360, 370; советский аналог — машины серии ЕС) к рабочим станциям, высокопроизводительным персо­нальным компьютерам и сетевой модели вычислений. Именно для того, чтобы исключить возникшую в связи с изменением аппаратной платформы некорректность некоторых положений «Оранжевой книги», адаптиро­вать их к современным условиям и сделать адекватны­ми нуждам разработчиков и пользователей программ­ного обеспечения, и была проделана огромная работа по интерпретации и развитию положений этого стан­дарта. В результате возник целый ряд сопутствующих «Оранжевой книге» документов, многие их которых стали ее неотъемлемой частью. К наиболее часто упо­минаемым относятся: Руководство по произвольному управлению досту­пом в безопасных системах («A guide to understanding discretionary access control in trusted systems») [10]. Руководство по управлению паролями («Password management guideline») [11]. Руководство по применению Критериев безопасности компьютерных систем в специфических средах («Gui­dance for applying the Department of Defence Trusted Com­puter 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 Stan­dards 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 De­fense 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 sys­tems. National Computer Security Center. NCSC-TG-003 Version 1, Sep­tember 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 Require­ments. National Computer Security Center. NCSC-TG-001-95, January 1995. 16. Information Technology Security Evaluation Criteria. Harmonized Crite­ria 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 De­cember 1992. 18. Canadian Trusted Computer Product Evaluation Criteria. Canadian System Security Centre Communication Security Establishment, Govern­ment of Canada. Version З.Ое. January 1993. 19. Common Criteria for Information Technology Security Evaluation, ra­tional 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 Hypothe­sis Methodology) [12]. Данная методология предусмат­ривает проведение исследований в три этапа. Первый этап состоит в изучении системы, причем особое вни­мание уделяется принципам функционирования меха­низмов защиты. На втором этапе происходит выдвиже­ние предположений (гипотез) о потенциально уязвимых компонентах, которые затем тщательно проверяются на основании анализа документации, реальных особенно­стей ВС и деталей ее функционирования и с помощью проведения специальных тестов, призванных подтвер­дить или опровергнуть присутствие предполагаемого изъяна в системе защиты. Наконец, на третьем, заклю­чительном этапе проводится обобщение полученных результатов и формируются списки (перечни) выявлен­ных ИЗ и успешных атак. Хотя в [12] и присутствует пе­речень ИЗ исследованных систем, а также разработан­ных и успешно осуществленных атак, систематизация полученных данных проведена не была. В середине 70-х годов подобные исследования про­водились по проектам RISOS (Research in Secured Oper­ating 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 Re­search 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 Sci­ences 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 Soft­ware 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 Na­tional Institute of Standards and Technology & USA National Se­curity 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 Com­puter 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 ex­perience with a distributed computation. Comm. ACM.25.3 (March) 172-180. 16. Sullivan M.R. and Chillarege R. 1992. A comparison of software de­fects 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. «Surrep­titious 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 penetra­tion 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 pene­tration 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. «Opera­ting 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: group@ssl.stu.neva.rli WWW: www.ssl.stu.neva.ru