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

Стандарты информационной безопасности Курс лекций. Учебное пособие Второе издание В. А. Галатенко Под редакцией академика РАН В. Б. Бетелина

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

Серия «Основы информационных технологий»

Интернет-Университет Информационных Технологий www.intuit.ru Москва, 2006

УДК 004.738.5.056(075.8) ББК 32.973.202-018.2я73-2 Г15 Стандарты информационной безопасности : курс лекций : учебное пособие / Второе издание / В. А. Галатенко. Под редакцией академика РАН В. Б. Бетелина / —М.: ИНТУИТ.РУ «Интернет-университет Информационных Технологий», 2006. - 264 с. ISBN 5-9556-0053-1 В курс включены сведения о стандартах и спецификациях, необходимые всем спе­ циалистам в области информационной безопасности (ИБ). Рассматриваются международ­ ные, национальные и промышленные стандарты, а также спецификации, разработанные в рамках Internet-сообщества. Рекомендовано для студентов высших учебных заведений, обучающихся по специальностям в области информационных технологий. Библиогр. 101.

Издание осуществлено при финансовой и технической поддержке компаний: Издательство «Открытые Системы», «РМ Телеком» и Kraftway Computers

Полное или частичное воспроизведение или размножения каким-либо способом, в том числе и публикация в Сети, настоящего издания допускается только с письменного разрешения Интернет-Университета Информационных Технологий. © Интернет-Университет Информационных Технологий, www.intuit.ru, 2006

ISBN 5-9556-0053-1

О проекте

Интернет-Университет И н ф о р м а ц и о н н ы х Технологий — это первое в России высшее учебное заведение, которое предоставляет возможность получить дополнительное образование во Всемирной Сети. Web-сайт университета находится п о адресу www.intuit.ru. М ы рады, что Вы решили расширить свои знания в области к о м п ь ю ­ терных технологий. Современный м и р — это м и р компьютеров и и н ф о р ­ мации. Компьютерная индустрия — самый быстрорастущий сектор э к о н о ­ м и к и , и ее рост будет продолжаться еще долгое время. Во времена жесткой конкуренции от уровня развития и н ф о р м а ц и о н н ы х технологий, достиже¬ н и й научной мысли и перспективных инженерных решений зависит успех не только отдельных людей и компаний, н о и целых стран. Вы выбрали са¬ мое подходящее время для изучения компьютерных дисциплин. Профес¬ сионалы в области и н ф о р м а ц и о н н ы х технологий сейчас востребованы везде: в науке, экономике, образовании, медицине и других областях, в го­ сударственных и частных компаниях, в России и за рубежом. Анализ д а н ­ ных, прогнозы, организация связи, создание программного обеспечения, построение моделей процессов — вот далеко н е полный список областей применения знаний для компьютерных специалистов. Обучение в университете ведется п о собственным учебным планам, разработанным ведущими российскими специалистами на основе между¬ народных образовательных стандартов Computer Curricula 2001 Computer Science. Изучать учебные курсы м о ж н о самостоятельно п о учебникам или на сайте Интернет-университета, задания выполняются только н а сайте. Для обучения необходимо зарегистрироваться н а сайте университета. Удостоверение об о к о н ч а н и и учебного курса или специальности выдает¬ ся п р и условии в ы п о л н е н и я всех заданий к л е к ц и я м и успешной сдачи итогового экзамена. Книга, которую Вы держите в руках, очередная в многотомной серии «Основы и н ф о р м а ц и о н н ы х технологий», выпускаемой ИнтернетУ н и в е р с и т е т о м И н ф о р м а ц и о н н ы х Технологий. В э т о й с е р и и будут в ы п у щ е н ы учебники п о всем базовым областям з н а н и й , связанным с компьютерными д и с ц и п л и н а м и . Добро пожаловать в Интернет-Университет Информационных Технологий! Анатолий Шкред [email protected] 3

Предисловие

Специалистам в области и н ф о р м а ц и о н н о й безопасности ( И Б ) сего­ д н я почти невозможно обойтись без знаний соответствующих стандартов и с п е ц и ф и к а ц и й . Н а то имеется несколько причин. Формальная состоит в том, что необходимость следования некото­ р ы м стандартам (например, криптографическим и / и л и Руководящим д о ­ кументам Гостехкомиссии России) закреплена законодательно. Однако наиболее убедительны содержательные п р и ч и н ы . Во-пер¬ вых, стандарты и с п е ц и ф и к а ц и и — одна и з ф о р м н а к о п л е н и я з н а н и й , прежде всего о процедурном и программно-техническом уровнях И Б . В них зафиксированы апробированные, высококачественные р е ш е н и я и методологии, разработанные наиболее к в а л и ф и ц и р о в а н н ы м и специали¬ стами. Во-вторых, и те, и другие являются о с н о в н ы м средством обеспече­ н и я взаимной совместимости аппаратно-программных систем и их к о м ­ понентов, причем в Internet-сообществе это средство действительно ра¬ ботает, и весьма э ф ф е к т и в н о . С практической точки зрения, количество стандартов и с п е ц и ф и к а ­ ц и й (международных, национальных, отраслевых и т.п.) в области и н ф о р ­ м а ц и о н н о й безопасности бесконечно. В курсе рассматриваются наиболее важные из них, з н а н и е которых необходимо всем или почти всем разра¬ ботчикам и о ц е н щ и к а м защитных средств, многим сетевым и системным а д м и н и с т р а т о р а м , р у к о в о д и т е л я м соответствующих п о д р а з д е л е н и й , пользователям. Отбор проводился таким образом, чтобы охватить различные аспек¬ ты и н ф о р м а ц и о н н о й безопасности, разные виды и конфигурации инфор¬ м а ц и о н н ы х систем, предоставить полезные сведения для самых разнооб¬ разных групп целевой аудитории. Часть стандартов и с п е ц и ф и к а ц и й была рассмотрена в курсе «Осно¬ вы и н ф о р м а ц и о н н о й безопасности» и в монографии автора «Информа¬ ц и о н н а я безопасность — практический подход»; в д а н н о м курсе о н и х приводятся л и ш ь краткие сведения. Основное в н и м а н и е уделяется меж­ дународному стандарту I S O / I E C 15408-1999 и его российскому аналогу ГОСТ Р И С О / М Э К 15408-2002 «Критерии оценки безопасности и н ф о р ­ м а ц и о н н ы х технологий», а также с п е ц и ф и к а ц и я м Internet-сообщества.

4

Об авторе

Галатенко Владимир Антонович Д о к т о р ф и з и к о - м а т е м а т и ч е с к и х наук, з а в е д у ю щ и й деле и н ф о р м а ц и о н н о й б е з о п а с н о с т и Н И И с и с т е м н ы х Р А Н . Автор т е о р е т и ч е с к и х и п р а к т и ч е с к и х р а з р а б о т о к , п о с о б и й и статей по и н ф о р м а ц и о н н о й б е з о п а с н о с т и программирования.

5

с е к т о р о м в от¬ исследований книг, учебных и технологии

Принятые сокращения ЗБ ИБ ИС ИТ КОБИТ МЭ ОК ОО ОС ОУД ПБ ПЗ ПО РД СУБД СУИБ УЦ ФБ ФП ЭЦП

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

6

Лекции Л е к ц и я 1.

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

13

Л е к ц и я 2.

«Общие критерии». Часть 1. О с н о в н ы е идеи

22

Л е к ц и я 3.

«Общие критерии». Часть 2. Ф у н к ц и о н а л ь н ы е требования безопасности

36

Л е к ц и я 4.

«Общие критерии». Часть 3. Требования доверия безопасности

52

Л е к ц и я 5.

П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 1. О б щ и е требования к сервисам безопасности

68

П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 2. Частные требования к сервисам безопасности

82

Л е к ц и я 6.

Л е к ц и я 7.

П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 3. Ч а с т н ы е требования к к о м б и н а ц и я м и п р и л о ж е н и я м сервисов безопасности . 107

Л е к ц и я 8.

Рекомендации семейства X.500

121

Л е к ц и я 9.

С п е ц и ф и к а ц и я Internet-сообщества IPsec

103

Л е к ц и я 10.

С п е ц и ф и к а ц и я Internet-сообщества T L S

144

Л е к ц и я 11.

С п е ц и ф и к а ц и я Internet-сообщества «Обобщенный прикладной программный интерфейс службы безопасности»

155

Л е к ц и я 12.

С п е ц и ф и к а ц и я Internet-сообщества «Руководство по и н ф о р м а ц и о н н о й безопасности предприятия»

170

С п е ц и ф и к а ц и я Internet-сообщества «Как реагировать на нарушения и н ф о р м а ц и о н н о й безопасности»

189

Л е к ц и я 13.

Л е к ц и я 14.

С п е ц и ф и к а ц и я Internet-сообщества «Как выбирать поставщика Интернет-услуг»

205

Л е к ц и я 15.

Британский стандарт BS 7799

220

Л е к ц и я 16.

Федеральный стандарт С Ш А FIPS 140-2 «Требования безопасности для криптографических модулей» 233

Л е к ц и я 17.

Заключение

245

7

Содержание Л е к ц и я 1. Обзор наиболее важных стандартов и с п е ц и ф и к а ц и й в области и н ф о р м а ц и о н н о й безопасности 13 Роль стандартов и с п е ц и ф и к а ц и й . Наиболее важные стандарты и с п е ц и ф и к а ц и и в области и н ф о р м а ц и о н н о й безопасности 14 Краткие сведения о стандартах и спецификациях, не являющихся предметом данного курса 16 Краткие аннотации подробно рассматриваемых в курсе стандартов и с п е ц и ф и к а ц и й 19 Л е к ц и я 2. «Общие критерии. Часть 1. Основные идеи 22 История создания и текущий статус «Общих критериев» 22 Основные понятия и идеи «Общих критериев» 25 Основные понятия и идеи «Общей методологии о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» 28 Л е к ц и я 3. «Общие критерии». Часть 2. Ф у н к ц и о н а л ь н ы е требования безопасности 36 К л а с с и ф и к а ц и я функциональных требований безопасности . . . . 37 Классы функциональных требований, о п и с ы в а ю щ и е элементарные сервисы безопасности 39 Классы функциональных требований, о п и с ы в а ю щ и е производные сервисы безопасности 42 Защита данных пользователя 43 Защита ф у н к ц и й безопасности объекта оценки 46 Классы функциональных требований, играющие инфраструктурную роль 49 Л е к ц и я 4. О б щ и е критерии». Часть 3. Требования д о в е р и я безопасности 52 Основные понятия и классификация требований доверия безопасности 52 Оценка профилей защиты и заданий по безопасности 54 Требования доверия к этапу разработки 55 Требования к этапу получения, представления и анализа результатов разработки 59 Требования к поставке и эксплуатации, поддержка доверия 62 Оценочные уровни доверия безопасности 64 Л е к ц и я 5. П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 1. О б щ и е требования к сервисам безопасности . . . . 68 Общие положения 68 8

О б щ и е предположения безопасности О б щ и е угрозы безопасности О б щ и е элементы политики и цели безопасности О б щ и е ф у н к ц и о н а л ь н ы е требования О б щ и е требования доверия безопасности Л е к ц и я 6. П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 2. Ч а с т н ы е требования к сервисам безопасности. . Биометрическая и д е н т и ф и к а ц и я и аутентификация Требования к п р о и з в о л ь н о м у ( д и с к р е ц и о н н о м у ) у п р а в л е н и ю доступом Требования к принудительному (мандатному) управлению доступом Ролевое управление доступом Межсетевое экранирование Системы активного аудита Анонимизаторы Выпуск и управление сертификатами Анализ з а щ и щ е н н о с т и Л е к ц и я 7. П р о ф и л и защиты, разработанные на основе «Общих критериев». Часть 3. Ч а с т н ы е требования к к о м б и н а ц и я м и п р и л о ж е н и я м сервисов безопасности О п е р а ц и о н н ы е системы Системы управления базами данных Виртуальные частные сети Виртуальные локальные сети Смарт-карты Некоторые выводы Л е к ц и я 8. Рекомендации семейства X.500 Основные понятия и идеи рекомендаций семейства X.500 Каркас сертификатов открытых ключей Каркас сертификатов атрибутов Простая и сильная аутентификация Л е к ц и я 9. С п е ц и ф и к а ц и я Internet-сообщества IPsec Архитектура средст безопасности IP-уровня Контексты безопасности и управление ключами Протокольные контексты и политика безопасности Обеспечение аутентичности IP-пакетов Обеспечение конфиденциальности сетевого трафика Л е к ц и я 10. С п е ц и ф и к а ц и я Internet-сообщества T L S Основные идеи и понятия протокола T L S Протокол передачи записей

9

71 72 73 75 80 . 82 83 84 86 88 89 91 96 101 105

107 107 112 114 115 116 119 121 121 123 126 128 130 130 132 135 140 141 144 144 145

П р о т о к о л установления с о е д и н е н и й и а с с о ц и и р о в а н н ы е протоколы П р и м е н е н и е протокола H T T P над T L S Л е к ц и я 11. С п е ц и ф и к а ц и я Internet-сообщества «Обобщенный прикладной программный интерфейс службы безопасности» Введение Основные понятия Ф у н к ц и и для работы с удостоверениями Создание и уничтожение контекстов безопасности Защита сообщений Логика работы пользователей интерфейса безопасности Представление некоторых объектов интерфейса безопасности в среде я з ы к а С Л е к ц и я 12. С п е ц и ф и к а ц и я Internet-сообщества «Руководство по и н ф о р м а ц и о н н о й безопасности предприятия» Основные понятия Проблемы, с которыми может столкнуться организация Основы предполагаемого подхода Общие п р и н ц и п ы выработки о ф и ц и а л ь н о й политики предприятия в области и н ф о р м а ц и о н н о й безопасности Анализ рисков, и д е н т и ф и к а ц и я активов и угроз Регламентация использования ресурсов Реагирование на нарушения политики безопасности (административный уровень) Подход к выработке процедур для предупреждения нарушений безопасности Выбор регуляторов для практичной защиты Ресурсы для предупреждения нарушений безопасности Р е а г и р о в а н и е на н а р у ш е н и я безопасности ( п р о ц е д у р н ы й уровень) Л е к ц и я 13. С п е ц и ф и к а ц и я Internet-сообщества «Как реагировать на нарушения и н ф о р м а ц и о н н о й безопасности» Взаимодействие между группой реагирования, опекаемым сообществом и другими группами Порядок публикации правил и процедур деятельности групп реагирования Описание правил группы реагирования Описание услуг группы реагирования Л е к ц и я 14. С п е ц и ф и к а ц и я Internet-сообщества «Как выбирать поставщика Интернет-услуг» Общие положения 10

149 153

155 155 156 159 160 162 164 164 170 170 172 173 174 176 177 179 182 183 185 186 189 191 192 195 201 205 205

Роль поставщика Internet-услуг в реагировании на нарушения безопасности М е р ы по защите Internet-сообщества Маршрутизация, фильтрация и ограничение вещания Защита системной инфраструктуры Размещение Web-серверов Возможные вопросы к поставщику Internet-услуг Л е к ц и я 15. Британский стандарт BS 7799 Регуляторы безопасности и реализуемые ими цели Часть 1. Регуляторы общего характера Часть 2. Регуляторы технического характера Часть 3. Разработка и сопровождение, управление бесперебойной работой, контроль соответствия Четырехфазная модель процесса управления и н ф о р м а ц и о н н о й безопасностью Л е к ц и я 16. Федеральный стандарт С Ш А FIPS 140-2 «Требования безопасности для криптографических модулей» Основные понятия и идеи стандарта F I P S 140-2 Требования безопасности Часть 1. Спецификация, порты и интерфейсы, роли, сервисы и аутенфикация Часть 2. Модель в виде конечного автомата, физическая безопасность Часть 3. Эксплуатационное окружение, управление криптографическими ключами Часть 4. Самотестирование, доверие проектированию, сдерживание прочих атак, другие рекомендации Л е к ц и я 17. Заключение Основные идеи курса «Общие критерии» и п р о ф и л и защиты на их основе С п е ц и ф и к а ц и я Internet-сообщества для программно-технического уровня И Б С п е ц и ф и к а ц и я Internet-сообщества для административного и процедурного уровней И Б

11

206 208 211 213 215 218 220 223 223 225 227 230 233 233 237 237 239 241 242 245 246 247 251 254

Внимание! На сайте Интернет-университета информационных технологий Вы можете пройти тестирование по каждой лекции и курсу в целом. Добро пожаловать на наш сайт:

www.intuit.ru

12

Лекция 1

Обзор наиболее важных стандартов

Лекция 1. Обзор наиболее важных стандартов и спецификаций в области информационной безопасности Выделяются наиболее важные стандарты и спецификации. Приводятся краткие сведения о стандартах, не являющихся предметом данного курса. Аннотируются спецификации, детально рассматриваемые в последующей ча¬ сти курса.

Ключевые слова: и н ф о р м а ц и о н н а я безопасность, стандарт, с п е ц и ­ ф и к а ц и я , п р и н ц и п ы стандартизации, «Оранжевая книга», безопас­ ная система, д о в е р е н н а я система, политика безопасности, уровень г а р а н т и р о в а н н о с т и , подотчетность, д о в е р е н н а я вычислительная база, м о н и т о р о б р а щ е н и й , я д р о безопасности, периметр безопас¬ ности, д и с к р е ц и о н н о е управление доступом, мандатное управле¬ н и е доступом, безопасность повторного и с п о л ь з о в а н и я , к л а с с и ф и ­ к а ц и я по т р е б о в а н и я м безопасности, «Радужная серия», « И н т е р ­ претация для сетевых к о н ф и г у р а ц и й » , к р и п т о г р а ф и я , конфиден¬ циальность, целостность, доступность, ф р а г м е н т и р о в а н и е монито¬ ра о б р а щ е н и й , « Г а р м о н и з и р о в а н н ы е к р и т е р и и Е в р о п е й с к и х стран», цель о ц е н к и , система, продукт, объект о ц е н к и , сервис безо¬ п а с н о с т и , механизм безопасности, э ф ф е к т и в н о с т ь , корректность, Р у к о в о д я щ и е документы Гостехкомиссии Р о с с и и , архитектура бе­ з о п а с н о с т и , а у т е н т и ф и к а ц и я , у п р а в л е н и е доступом, неотказуемость, ш и ф р о в а н и е , э л е к т р о н н а я ц и ф р о в а я подпись ( Э Ц П ) , д о ­ полнение трафика, управление маршрутизацией, нотаризация, сервер аутентификации Kerberos, к о н ц е п ц и я единого входа в сеть, «Общие критерии», ф у н к ц и о н а л ь н ы е требования, требования д о ­ верия, п р о ф и л ь з а щ и т ы , задание по безопасности, к р и п т о г р а ф и ч е ­ с к и й модуль, п р о г р а м м н ы й и н т е р ф е й с , к л и е н т / с е р в е р , аутентифи­ к а ц и я , целостность, к о н ф и д е н ц и а л ь н о с т ь , сетевой уровень, вирту¬ альные частные сети, т р а н с п о р т н ы й уровень, служба д и р е к т о р и й , сертификат открытых к л ю ч е й , сертификат атрибутов, политика бе¬ зопасности, процедуры безопасности, н а р у ш е н и е безопасности, р е а к ц и я на н а р у ш е н и е , п о с т а в щ и к Internet-услуг, к л а с с и ф и к а ц и я ресурсов, безопасность персонала, ф и з и ч е с к а я безопасность, уп¬ равление доступом.

13

Курс

Информационная безопасность: основные стандарты и спецификации

Роль с т а н д а р т о в и с п е ц и ф и к а ц и й . Н а и б о л е е важные стандарты и спецификации в области информационной безопасности Специалистам в области и н ф о р м а ц и о н н о й безопасности ( И Б ) сего¬ д н я почти невозможно обойтись без знаний соответствующих стандартов и с п е ц и ф и к а ц и й . Н а то имеется несколько причин. Формальная состоит в том, что необходимость следования некото­ р ы м стандартам (например, криптографическим и / и л и Руководящим до¬ кументам Гостехкомиссии России) закреплена законодательно. Однако наиболее убедительны содержательные п р и ч и н ы . Во-пер¬ вых, стандарты и с п е ц и ф и к а ц и и — одна и з ф о р м н а к о п л е н и я з н а н и й , прежде всего о процедурном и программно-техническом уровнях И Б . В них зафиксированы апробированные, высококачественные р е ш е н и я и методологии, разработанные наиболее к в а л и ф и ц и р о в а н н ы м и специали¬ стами. Во-вторых, и те, и другие являются о с н о в н ы м средством обеспече­ н и я взаимной совместимости аппаратно-программных систем и их к о м ­ понентов, причем в Internet-сообществе это средство действительно ра¬ ботает, и весьма э ф ф е к т и в н о . Отмеченная роль стандартов зафиксирована в основных понятиях закона Р Ф «О техническом регулировании» от 27 декабря 2002 года под номером 184-ФЗ (принят Государственной Думой 15 декабря 2002 года): • стандарт — документ, в котором в целях добровольного многократ­ ного использования устанавливаются характеристики продукции, правила осуществления и характеристики процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, в ы ­ полнения работ или оказания услуг. Стандарт также может содер­ жать требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения; • стандартизация — деятельность по установлению правил и характе­ ристик в целях их добровольного многократного использования, н а ­ правленная на достижение упорядоченности в сферах производства и обращения продукции и п о в ы ш е н и е конкурентоспособности про¬ дукции, работ или услуг. Примечательно также, что в число п р и н ц и п о в стандартизации, про¬ возглашенных в статье 12 упомянутого закона, входит п р и н ц и п п р и м е н е ­ н и я международного стандарта к а к основы разработки национального, за исключением случаев, если «такое п р и м е н е н и е признано невозможным вследствие несоответствия требований международных стандартов к л и ­ матическим и географическим особенностям Российской Федерации, техническим и (или) технологическим особенностям или по и н ы м о с н о ­ ваниям, либо Российская Федерация, в соответствии с установленными 14

Лекция 1

Обзор наиболее важных стандартов

процедурами, выступала против п р и н я т и я международного стандарта или отдельного его положения». С практической точки зрения, количест¬ во стандартов и с п е ц и ф и к а ц и й (международных, национальных, отрас¬ левых и т. п.) в области и н ф о р м а ц и о н н о й безопасности бесконечно. В курсе рассматриваются наиболее важные из них, знание которых необхо¬ д и м о всем или почти всем разработчикам и о ц е н щ и к а м з а щ и т н ы х средств, многим сетевым и системным администраторам, руководителям соответствующих подразделений, пользователям. Отбор проводился таким образом, чтобы охватить различные аспек¬ ты и н ф о р м а ц и о н н о й безопасности, разные виды и конфигурации инфор¬ м а ц и о н н ы х систем ( И С ) , предоставить полезные сведения для самых раз¬ нообразных групп целевой аудитории. На верхнем уровне м о ж н о выделить две существенно отличающиеся друг от друга группы стандартов и с п е ц и ф и к а ц и й : • оценочные стандарты, предназначенные для о ц е н к и и классифика­ ц и и и н ф о р м а ц и о н н ы х систем и средств защиты по требованиям бе¬ зопасности; • с п е ц и ф и к а ц и и , регламентирующие различные аспекты реализации и использования средств и методов защиты. Эти группы, разумеется, не конфликтуют, а дополняют друг друга. О ц е н о ч н ы е стандарты описывают важнейшие, с точки зрения и н ф о р м а ­ ц и о н н о й безопасности, понятия и аспекты И С , играя роль организаци­ о н н ы х и архитектурных с п е ц и ф и к а ц и й . Другие с п е ц и ф и к а ц и и определя­ ют, как и м е н н о строить И С предписанной архитектуры и выполнять о р ­ г а н и з а ц и о н н ы е требования. И з числа оценочных необходимо выделить стандарт Министерства обороны С Ш А «Критерии о ц е н к и доверенных компьютерных систем» и его интерпретацию для сетевых к о н ф и г у р а ц и й , «Гармонизированные к р и т е р и и Е в р о п е й с к и х стран», международный стандарт «Критерии о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» и, конечно, Руково¬ д я щ и е документы Гостехкомиссии России. К этой ж е группе относится и Федеральный стандарт С Ш А «Требования безопасности для криптогра¬ фических модулей», регламентирующий к о н к р е т н ы й , но очень важный и сложный аспект и н ф о р м а ц и о н н о й безопасности. Технические с п е ц и ф и к а ц и и , п р и м е н и м ы е к с о в р е м е н н ы м рас¬ п р е д е л е н н ы м И С , с о з д а ю т с я , г л а в н ы м о б р а з о м , «Тематической груп­ п о й п о технологии Internet» (Internet Engineering Task Force, I E T F ) и ее п о д р а з д е л е н и е м — р а б о ч е й группой п о б е з о п а с н о с т и . Я д р о м рассмат¬ р и в а е м ы х технических с п е ц и ф и к а ц и й служат д о к у м е н т ы п о безопас¬ н о с т и на I P - у р о в н е (IPsec). К р о м е этого, анализируется з а щ и т а на т р а н с п о р т н о м у р о в н е (Transport Layer Security, T L S ) , а т а к ж е на у р о в н е п р и л о ж е н и й ( с п е ц и ф и к а ц и и G S S - A P I , Kerberos). Н е о б х о д и м о о т м е 15

Курс

Информационная безопасность: основные стандарты и спецификации

т и т ь , ч т о I n t e r n e t - с о о б щ е с т в о уделяет д о л ж н о е в н и м а н и е а д м и н и с т р а ­ т и в н о м у и п р о ц е д у р н о м у у р о в н я м б е з о п а с н о с т и («Руководство п о и н ­ ф о р м а ц и о н н о й б е з о п а с н о с т и п р е д п р и я т и я » , « К а к выбирать п о с т а в щ и ­ ка Интернет-услуг», « К а к реагировать н а н а р у ш е н и я и н ф о р м а ц и о н н о й безопасности»). В вопросах сетевой безопасности невозможно разобраться без осво­ ения с п е ц и ф и к а ц и й X.800 «Архитектура безопасности для взаимодейст­ вия открытых систем», X.500 «Служба директорий: обзор к о н ц е п ц и й , м о ­ делей и сервисов» и X.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибутов». Британский стандарт BS 7799 «Управление и н ф о р м а ц и о н н о й безо­ пасностью. Практические правила», полезный для руководителей орга¬ н и з а ц и й и л и ц , отвечающих за и н ф о р м а ц и о н н у ю безопасность, без сколько-нибудь существенных изменений воспроизведен в международ¬ ном стандарте I S O / I E C 17799. Таков, на н а ш взгляд, «стандартный минимум», которым должны ак¬ тивно владеть все действующие специалисты в области и н ф о р м а ц и о н н о й безопасности.

Краткие с в е д е н и я о с т а н д а р т а х и с п е ц и ф и к а ц и я х , не я в л я ю щ и х с я п р е д м е т о м д а н н о г о к у р с а Упоминаемые в д а н н о м разделе стандарты и с п е ц и ф и к а ц и и деталь¬ но рассмотрены в курсе «Основы и н ф о р м а ц и о н н о й безопасности» и в книге « И н ф о р м а ц и о н н а я безопасность — практический подход» [1]. Только п о этой п р и ч и н е о н и н е включены в настоящий курс в качестве предмета изучения. Первым о ц е н о ч н ы м стандартом, получившим международное при¬ з н а н и е и оказавшим исключительно сильное в л и я н и е на последующие разработки в области и н ф о р м а ц и о н н о й безопасности, стал стандарт Ми¬ нистерства обороны С Ш А «Критерии о ц е н к и доверенных компьютерных систем» (Department of Defense Trusted Computer System Evaliation Criteria, T C S E C , [47]), более известный (по цвету обложки) под названием «Оран­ жевая книга». Без преувеличения м о ж н о утверждать, что в «Оранжевой книге» за­ ложен п о н я т и й н ы й базис И Б . Достаточно л и ш ь перечислить содержащи­ еся в нем понятия: безопасная и доверенная системы, политика безопас­ ности, уровень гарантированности, подотчетность, доверенная вычисли­ тельная база, монитор обращений, ядро и периметр безопасности. Ис¬ ключительно важно и выделение таких аспектов политики безопасности, как добровольное (дискреционное) и принудительное (мандатное) управ¬ ление доступом, безопасность повторного использования объектов. П о 16

Лекция 1

Обзор наиболее важных стандартов

следним п о порядку, н о отнюдь н е п о значению следует назвать п р и н ц и ­ п ы к л а с с и ф и к а ц и и п о требованиям безопасности на основе параллельно­ го ужесточения требований к политике безопасности и уровню гарантированности. После «Оранжевой книги» была выпущена целая «Радужная серия». С концептуальной точки зрения, наиболее значимый документ в ней — «Интерпретация «Оранжевой книги» для сетевых конфигураций» (Trusted Network Interpretation, [77]). О н состоит и з двух частей. Первая содержит собственно интерпретацию, во второй описываются сервисы безопаснос­ ти, специфичные или особенно важные для сетевых конфигураций. Важнейшее понятие, введенное в первой части, — сетевая доверен­ ная вычислительная база. Другой п р и н ц и п и а л ь н ы й аспект — учет дина¬ мичности сетевых конфигураций. Среди защитных механизмов выделена криптография, помогающая поддерживать к а к конфиденциальность, так и целостность. Н о в ы м для своего времени стал систематический подход к вопросам доступности, ф о р м и р о в а н и е архитектурных п р и н ц и п о в ее обеспечения. Упомянем также достаточное условие корректности фрагментирован и я монитора обращений, являющееся теоретической основой д е к о м п о ­ з и ц и и распределенной И С в объектно-ориентированном стиле в сочета¬ н и и с криптографической защитой коммуникаций. Переходя к з н а к о м с т в у с « Г а р м о н и з и р о в а н н ы м и к р и т е р и я м и Ев¬ р о п е й с к и х стран», о т м е т и м отсутствие в н и х а п р и о р н ы х т р е б о в а н и й к условиям, в которых должна работать и н ф о р м а ц и о н н а я система. П р е д п о л а г а е т с я , ч т о сначала ф о р м у л и р у е т с я цель о ц е н к и , затем орган с е р т и ф и к а ц и и определяет, н а с к о л ь к о п о л н о о н а достигается, т. е. в к а ­ к о й м е р е к о р р е к т н ы и э ф ф е к т и в н ы архитектура и р е а л и з а ц и я м е х а н и з ­ м о в б е з о п а с н о с т и в к о н к р е т н о й с и т у а ц и и . Ч т о б ы облегчить ф о р м у л и ­ р о в к у ц е л и о ц е н к и , стандарт содержат о п и с а н и е д е с я т и п р и м е р н ы х к л а с с о в ф у н к ц и о н а л ь н о с т и , т и п и ч н ы х д л я п р а в и т е л ь с т в е н н ы х и ком¬ м е р ч е с к и х систем. В «Гармонизированных критериях» подчеркивается различие между системами и продуктами и н ф о р м а ц и о н н ы х технологий, н о для у н и ф и к а ­ ц и и требований вводится единое понятие — объект оценки. Важно указание и на различие между ф у н к ц и я м и (сервисами) безо¬ пасности и реализующими их механизмами, а также выделение двух ас¬ пектов гарантированности — эффективности и корректности средств бе¬ зопасности. Руководящие документы (РД) Гостехкомиссии России [19-23] нача­ ли появляться несколько позже, уже после опубликования «Гармонизи¬ рованных критериев», и, по аналогии с последними, подтверждают раз¬ ницу между автоматизированными системами (АС) и продуктами (сред17

Курс

Информационная безопасность: основные стандарты и спецификации

ствами вычислительной техники, С В Т ) , н о в общем и целом о н и долгое время следовали в фарватере «Оранжевой книги». Первое примечательное отклонение от этого курса произошло в 1997 году, когда был принят РД по отдельному сервису безопасности — межсе­ тевым э к р а н а м ( М Э ) [24]. Его основная идея — классифицировать М Э на основании осуществляющих фильтрацию потоков данных уровней эта¬ л о н н о й семиуровневой модели — получила международное признание и продолжает оставаться актуальной. В 2002 году Гостехкомиссия России приняла в качестве РД русский перевод [25] международного стандарта I S O / I E C 15408:1999 «Критерии о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» [59-61], что послу­ ж и л о толчком для кардинальной и весьма своевременной со всех точек зрения переориентации (вспомним приведенный в ы ш е п р и н ц и п стан¬ дартизации и з закона «О техническом регулировании»). К о н е ч н о , пере¬ ход на рельсы «Общих критериев» будет непростым, н о главное, что о н начался. Среди технических с п е ц и ф и к а ц и й н а первое место, безусловно, следует поставить документ X.800 «Архитектура безопасности для взаи­ модействия открытых систем» [84]. Здесь выделены в а ж н е й ш и е сетевые сервисы безопасности: аутентификация, управление доступом, обеспе¬ чение к о н ф и д е н ц и а л ь н о с т и и / и л и целостности данных, а также невоз¬ можность отказаться от совершенных действий. Д л я реализации серви¬ сов предусмотрены следующие сетевые механизмы безопасности и их к о м б и н а ц и и : ш и ф р о в а н и е , электронная ц и ф р о в а я подпись ( Э Ц П ) , у п ­ равление доступом, контроль целостности данных, аутентификация, д о ­ п о л н е н и е т р а ф и к а , управление маршрутизацией, нотаризация. Выбраны уровни эталонной семиуровневой модели, на которых могут быть реали¬ зованы сервисы и механизмы безопасности. Н а к о н е ц , детально рассмо¬ трены вопросы администрирования средств безопасности для распреде¬ л е н н ы х конфигураций. С п е ц и ф и к а ц и я Internet-сообщества R F C 1510 «Сетевой сервис ау­ т е н т и ф и к а ц и и Kerberos (V5)» [70] относится к более ч а с т н о й , н о весьма в а ж н о й и актуальной п р о б л е м е — а у т е н т и ф и к а ц и и в р а з н о р о д н о й рас¬ п р е д е л е н н о й среде с п о д д е р ж к о й к о н ц е п ц и и единого входа в сеть. Сер¬ вер а у т е н т и ф и к а ц и и Kerberos представляет собой д о в е р е н н у ю третью сторону, владеющую с е к р е т н ы м и к л ю ч а м и обслуживаемых субъектов и п о м о г а ю щ у ю и м в п о п а р н о й п р о в е р к е п о д л и н н о с т и . О весомости дан¬ н о й с п е ц и ф и к а ц и и свидетельствует тот факт, что к л и е н т с к и е компо¬ н е н т ы Kerberos присутствуют в б о л ь ш и н с т в е с о в р е м е н н ы х операцион¬ н ы х систем. Далее предполагается, что читатель свободно разбирается в особен­ ностях охарактеризованных в ы ш е стандартов и с п е ц и ф и к а ц и й . 18

Лекция 1

Обзор наиболее важных стандартов

Краткие а н н о т а ц и и п о д р о б н о р а с с м а т р и в а е м ы х в курсе стандартов и спецификаций «Гармонизированные критерии Европейских стран» стали весьма передовым документом для своего времени, о н и подготовили появление международного стандарта I S O / I E C 15408:1999 «Критерии о ц е н к и безо­ пасности и н ф о р м а ц и о н н ы х технологий» (Evaluation criteria for IT security) [59-61], в русскоязычной литературе обычно (но н е совсем верно) имену­ емого «Общими критериями» ( О К ) . На сегодняшний день «Общие критерии» — самый п о л н ы й и совре­ м е н н ы й оценочный стандарт. Н а самом деле, это метастандарт, определя­ ю щ и й инструменты о ц е н к и безопасности И С и порядок их использова­ н и я ; о н н е содержат предопределенных классов безопасности. Такие классы м о ж н о строить, опираясь на заданные требования. О К содержат два основных вида требований безопасности: • ф у н к ц и о н а л ь н ы е , соответствующие активному аспекту з а щ и т ы , предъявляемые к ф у н к ц и я м (сервисам) безопасности и реализую¬ щ и м их механизмам; • требования доверия, соответствующие пассивному аспекту; о н и предъявляются к технологии и процессу разработки и эксплуатации. Требования безопасности формулируются, и их в ы п о л н е н и е прове­ ряется для определенного объекта оценки — аппаратно-программного продукта или и н ф о р м а ц и о н н о й системы. Подчеркнем, что безопасность в О К рассматривается н е статично, а в соответствии с ж и з н е н н ы м ц и к л о м объекта оценки. К р о м е того, по¬ следний предстает в контексте среды безопасности, характеризующейся определенными условиями и угрозами. «Общие критерии» способствуют ф о р м и р о в а н и ю двух базовых ви¬ дов используемых на практике нормативных документов — это профиль з а щ и т ы и задание п о безопасности. П р о ф и л ь защиты представляет собой типовой набор требований, которым должны удовлетворять продукты и / и л и системы определенного класса. Задание п о безопасности содержит совокупность требований к кон¬ кретной разработке, их в ы п о л н е н и е позволит решить поставленные зада¬ чи п о обеспечению безопасности. В последующей части курса будут детально рассмотрены к а к сами «Общие критерии», так и разработанные на их основе п р о ф и л и защиты и проекты профилей. Криптография — область специфическая, н о общее представление о ее месте в архитектуре безопасности и о требованиях к криптографическим компонентам иметь необходимо. Для этого целесообразно ознакомиться с 19

Курс

Информационная безопасность: основные стандарты и спецификации

Федеральным стандартом С Ш А FIPS 140-2 «Требования безопасности для криптографических модулей» (Security Requirements for Cryptographic Modules) [50]. О н выполняет организующую функцию, описывая внешний интерфейс криптографического модуля, общие требования к подобным модулям и их окружению. Наличие такого стандарта упрощает разработку сервисов безопасности и профилей защиты для них. Криптография как средство реализации сервисов безопасности име¬ ет две стороны: алгоритмическую и интерфейсную. Нас будет интересо¬ вать исключительно интерфейсный аспект, поэтому, наряду со стандар­ том F I P S 140-2, м ы рассмотрим предложенную в рамках Internet-сообщества техническую с п е ц и ф и к а ц и ю «Обобщенный прикладной программ¬ н ы й и н т е р ф е й с службы безопасности» (Generic Security Service Application Program Interface, G S S - A P I ) [GSS-API]. Интерфейс безопасности G S S - A P I предназначен для защиты ком¬ м у н и к а ц и й между компонентами программных систем, построенных в архитектуре клиент/сервер. О н создает условия для взаимной аутентифи­ кации общающихся партнеров, контролирует целостность пересылаемых сообщений и служит гарантией их конфиденциальности. Пользователя­ ми интерфейса безопасности G S S - A P I являются к о м м у н и к а ц и о н н ы е протоколы (обычно прикладного уровня) или другие программные систе­ м ы , самостоятельно в ы п о л н я ю щ и е пересылку данных. Технические с п е ц и ф и к а ц и и IPsec [IPsec] имеют, без преувеличения, фундаментальное значение, описывая п о л н ы й набор средств обеспече­ н и я конфиденциальности и целостности на сетевом уровне. Для д о м и н и ­ рующего в настоящее время протокола IP версии 4 о н и носят факульта­ тивный характер; в перспективной версии IPv6 их реализация обязатель­ на. На основе IPsec строятся з а щ и т н ы е механизмы протоколов более в ы ­ сокого уровня, вплоть до прикладного, а также законченные средства бе­ зопасности, в том числе виртуальные частные сети. Разумеется, IPsec су­ щественным образом опирается на криптографические механизмы и ключевую инфраструктуру. Точно так ж е характеризуются и средства безопасности транспорт­ ного уровня (Transport Layer Security, T L S ) [48]. С п е ц и ф и к а ц и я T L S раз­ вивает и уточняет популярный протокол Secure Socket Layer (SSL), ис¬ пользуемый в большом числе программных продуктов самого разного на¬ значения. В упомянутом в ы ш е инфраструктурном плане очень важны р е к о ­ мендации X.500 «Служба директорий: обзор к о н ц е п ц и й , моделей и серви­ сов» (The Directory: Overview of concepts, models and services) [55] и X.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибу¬ тов» (The Directory: Public-key and attribute certificate frameworks) [57]. В рекомендациях X.509 описан формат сертификатов открытых ключей и 20

Лекция 1

Обзор наиболее важных стандартов

атрибутов — базовых элементов инфраструктур открытых ключей и уп¬ равления привилегиями. К а к известно, обеспечение и н ф о р м а ц и о н н о й безопасности — про¬ блема комплексная, требующая согласованного п р и н я т и я мер на законо¬ дательном, административном, процедурном и программно-техническом уровнях. П р и разработке и реализации базового документа администра­ тивного уровня — политики безопасности организации — отличным под­ спорьем может стать рекомендация Internet-сообщества «Руководство п о и н ф о р м а ц и о н н о й безопасности предприятия» (Site Security Handbook, см. [53], [51]). В нем освещаются практические аспекты ф о р м и р о в а н и я политики и процедур безопасности, поясняются основные понятия ад­ министративного и процедурного уровней, содержится мотивировка р е ­ комендуемых действий, затрагиваются темы анализа рисков, реакции на нарушения И Б и действий после ликвидации нарушения. Более подробно последние вопросы рассмотрены в рекомендации « К а к реагировать н а н а р у ш е н и я и н ф о р м а ц и о н н о й безопасности» (Expectations for Computer Security Incident Response) [39]. В этом доку¬ менте м о ж н о найти и ссылки на полезные и н ф о р м а ц и о н н ы е ресурсы, и практические советы процедурного уровня. При развитии и реорганизации корпоративных информационных си¬ стем, несомненно, окажется полезной рекомендация «Как выбирать п о ­ ставщика Internet-услу^ (Site Security Handbook Addendum for ISPs) [46]. В первую очередь ее положений необходимо придерживаться в ходе формиро­ вания организационной и архитектурной безопасности, на которой базиру­ ются прочие меры процедурного и программно-технического уровней. Для практического создания и поддержания режима и н ф о р м а ц и о н ­ н о й безопасности с п о м о щ ь ю регуляторов административного и проце­ дурного уровней пригодится знакомство с британским стандартом BS 7799 «Управление и н ф о р м а ц и о н н о й безопасностью. Практические пра­ вила» (Code of practice for information security management) [37] и его вто­ рой частью BS 7799-2:2002 «Системы управления и н ф о р м а ц и о н н о й безо­ пасностью — спецификация с руководством по использованию» (Information security management systems — Specification with guidance for use) [38]. В нем разъясняются такие понятия и процедуры, к а к политика безопасности, о б щ и е п р и н ц и п ы организации защиты, классификация ресурсов и управление и м и , безопасность персонала, физическая безо­ пасность, п р и н ц и п ы администрирования систем и сетей, управление до¬ ступом, разработка и сопровождение И С , планирование бесперебойной работы организации. М о ж н о видеть, что отобранные для курса стандарты и специфика¬ ц и и затрагивают все уровни и н ф о р м а ц и о н н о й безопасности, кроме зако¬ нодательного. Далее м ы приступим к их детальному рассмотрению. 21

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 2 . «Общие к р и т е р и и » . Часть 1 . О с н о в н ы е и д е и Рассматривается история создания «Общих критериев», описывается их текущий статус, анализируются основные идеи.

Ключевые слова: оценка безопасности, и н ф о р м а ц и о н н ы е техноло¬ гии, международный стандарт, российский стандарт, Общие крите¬ р и и , Руководящий документ, методология о ц е н к и , соглашение о п р и з н а н и и , сертификат, объект о ц е н к и , система, продукт, изделие ИТ, среда безопасности, предположения безопасности, угрозы безо­ пасности, политика безопасности, цели безопасности, требования безопасности, класс, семейство, компонент, элемент, функциональ¬ ные требования, требования доверия, профиль защиты, задание по б е з о п а с н о с т и , ф у н к ц и о н а л ь н ы й пакет, к р а т к а я с п е ц и ф и к а ц и я , функциональная с п е ц и ф и к а ц и я , проект верхнего уровня, проект нижнего уровня, реализация, входная задача, задача о ц е н к и , выход­ ная задача, технический отчет о ц е н к и , рейтинг уязвимостей, стой­ кость ф у н к ц и й безопасности, потенциал нападения.

История создания и текущий статус «Общих к р и т е р и е в » В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета (JTC1/SC27/WG3) Международной организации по стандартизации (ISO) приступила к разработке «Критериев оценки бе¬ зопасности и н ф о р м а ц и о н н ы х технологий» (Evaluation Criteria for IT Security, E C I T S ) . Несколько позже, в 1993 году, правительственные орга¬ н и з а ц и и шести североамериканских и европейских стран — Канады, С Ш А , Великобритании, Германии, Нидерландов и Ф р а н ц и и — занялись составлением так называемых «Общих критериев о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» ( C o m m o n Criteria for IT Security Evaluation). За этим документом исторически закрепилось более короткое название — «Общие критерии», или О К (Common Criteria, C C ) . Рабочая группа ISO, возглавляемая представителем Ш в е ц и и , функ¬ ционировала на общественных началах и действовала весьма неторопли¬ во, пытаясь собрать и увязать между собой м н е н и я экспертов примерно из двух десятков стран, в то время как коллектив «Проекта ОК», ф и н а н ­ сируемый своими правительствами, несмотря на первоначальное трех¬ летнее отставание, весьма быстро начал выдавать реальные результаты. 22

Лекция 2

«Общие критерии». Часть 1. Основные идеи

Объяснить это нетрудно: в «Проекте ОК» требовалось объединить и раз¬ вить всего три весьма продвинутых и близких п о духу документа — «Гар¬ м о н и з и р о в а н н ы е критерии Европейских стран», а также «Канадские кри¬ терии о ц е н к и доверенных компьютерных продуктов» и «Федеральные критерии безопасности и н ф о р м а ц и о н н ы х технологий» ( С Ш А ) . (Сами разработчики «Общих критериев» относят к числу первоисточников е щ е и «Оранжевую книгу».) К а к правило, круг людей, заседающих в комитетах и комиссиях п о и н ф о р м а ц и о н н о й безопасности, довольно узок, поэтому нет ничего уди¬ вительного в том, что одни и те ж е представители стран (в частности, С Ш А и Великобритании) входили в обе группы разработчиков. Естест¬ венно, в таких условиях между коллективом «Проекта ОК» и Рабочей группой 3 установилось тесное взаимодействие. Практически это означа¬ ло, что группа WG3 стала бесплатным приложением к «Проекту О К » , а сами «Общие критерии» автоматически д о л ж н ы были получить статус н е межгосударственного, а международного стандарта. В О С Unix есть утилита tee, создающая ответвления каналов путем копирования стандартного вывода в ф а й л ы и довольно точно моделиру­ ю щ а я взаимоотношения между коллективом «Проекта ОК» и группой W G 3 . С 1994 года р а н н и е версии О К становятся рабочими проектами W G 3 . В 1996 году появилась версия 1.0 «Общих критериев», которая, п о ­ м и м о публикации в Internet для всеобщего свободного доступа, была одо¬ брена ISO и обнародована в качестве Проекта Комитета. Ш и р о к о е открытое обсуждение документа и «опытная эксплуата­ ция» привели к его существенной переработке и выходу версии 2.0 О К в мае 1998 года. Разумеется, эксперты W G 3 н е могли ее н е отредактировать. И х замечания были учтены в версии 2.1 О К [40-42], принятой в августе 1999 года. Соответствующий международный стандарт I S O / I E C 15408¬ 1999 [59-61] введен в действие с 1 декабря 1999 года. Таким образом, ф а к т и ч е с к и стандарт I S O / I E C 15408-1999 и версия 2.1 О К совпадают, а если пренебречь о п и с ы в а е м ы м и н и ж е н ю а н с а м и , их н а з в а н и я могут считаться в з а и м о з а м е н я е м ы м и . О д н а к о , строго г о ­ в о р я , « К р и т е р и и о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» и « О б щ и е к р и т е р и и о ц е н к и безопасности и н ф о р м а ц и о н н ы х техноло¬ гий» — р а з н ы е д о к у м е н т ы , поскольку в ы п у щ е н ы п о д эгидой р а з н ы х ор¬ г а н и з а ц и й , руководствующихся р а з н ы м и п р а в и л а м и р а с п р о с т р а н е н и я и обновления. ISO н е предоставляет свободный доступ к своим стандартам, о н и относительно статичны, поскольку их обновляют и л и подтверждают один раз в пять лет (какие-либо и з м е н е н и я в стандарте I S O / I E C 15408 м о ж н о о ж и д а т ь в 2004 году). Н а п р о т и в , п о р т а л « П р о е к т а О К » (http://www.commoncriteria.org) открыт для всех желающих, а разработ23

Курс

Информационная безопасность: основные стандарты и спецификации

ч и к и «Общих критериев» п о с т о я н н о предлагают и п р и н и м а ю т и з м е н е ­ н и я , уточнения, интерпретации отдельных п о л о ж е н и й и готовят третью версию своего документа. Поэтому, с ф о р м а л ь н о й точки зрения, между­ народный стандарт I S O / I E C 15408-1999 по-русски правильнее сокра­ щ е н н о именовать К О Б И Т , а н е О К . (Правда, велика вероятность, что р а ­ бочая группа ISO любезно согласится и дальше пользоваться плодами «Проекта О К » , естественно, внося в них свои редакторские правки...) Уточним, что далее, в рамках этой темы, м ы будем иметь в виду и м е н н о «Общие критерии», а н е стандарт ISO. С целью у н и ф и к а ц и и процедуры сертификации по «Общим крите¬ риям» в августе 1999 года была опубликована «Общая методология о ц е н ­ ки безопасности и н ф о р м а ц и о н н ы х технологий» (Common Methodology for Information Technology Security Evaluation) [43], описывающая мини¬ мальный набор действий при проведении оценки. «Проект ОК» с самого начала носил н е только технический, н о и э к о н о м и к о - п о л и т и ч е с к и й характер. Его цель состояла, в частности, в том, чтобы упростить, удешевить и ускорить выход сертифицированных изделий и н ф о р м а ц и о н н ы х технологий ( И Т ) на мировой рынок. Д л я это¬ го в мае 2000 года уполномоченные правительственные организации ше¬ сти стран-основателей «Проекта О К » , а также Австралии и Новой Зелан¬ д и и , Греции, Италии, И с п а н и и , Норвегии, Ф и н л я н д и и и Ш в е ц и и п о д п и ­ сали соглашение «О п р и з н а н и и сертификатов по О б щ и м критериям в об¬ ласти безопасности и н ф о р м а ц и о н н ы х технологий» (позднее к нему при¬ соединились Австрия и Израиль). Участие в соглашении предполагает соблюдение двух независимых условий: признание сертификатов, выданных соответствующими органа¬ ми других стран-участниц, а также возможность осуществления подоб­ ной сертификации. Очевидно, от взаимного п р и з н а н и я сертификатов выигрывают н е только производители, н о и потребители изделий ИТ. Ч т о ж е касается их выдачи, то соглашение предусматривает жесткий контроль при получении и подтверждении этого права (например, предусмотрено проведение так называемых теневых с е р т и ф и к а ц и о н н ы х испытаний под контролем независимых экспертов). Таким образом, для полноценного участия в соглашении, п о м и м о ж е л а н и я , государство должно располагать органами сертификации с достаточными ресурсами и штатом специалис¬ тов, к в а л и ф и к а ц и я которых получила о ф и ц и а л ь н о е международное при¬ знание. П о д а н н ы м на конец 2002 года, правом выдачи сертификатов, признаваемых участниками соглашения, обладали Австралия и Новая З е ­ ландия, Великобритания, Германия, Канада, С Ш А и Ф р а н ц и я . К началу 2003 года сертификаты по «Общим критериям» получили около семидесяти разнообразных изделий И Т ведущих производителей: о п е р а ц и о н н ы е системы, системы управления базами данных, межсетевые 24

Лекция 2

«Общие критерии». Часть 1. Основные идеи

э к р а н ы , к о м м у н и к а ц и о н н ы е средства, интеллектуальные карты и т.п.; еще почти сорок находились в процессе сертификации. Определяя статус «Общих критериев» в России, следует отметить, что отечественные специалисты с самого начала внимательно следили за этим проектом, публиковали аналитические обзоры и переводы (см., на¬ пример, [JI981K]). В 1999 году была организована работа п о подготовке российского стандарта и Руководящего документа (РД) Гостехкомиссии России на основе аутентичного перевода О К . Она велась в тесном кон¬ такте с зарубежными коллегами и успешно завершена в 2002 году. Имен¬ но тогда был о ф и ц и а л ь н о издан ГОСТ Р И С О / М Э К 15408-2002 «Крите­ р и и о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий» [16-18] с датой введения в действие 1 я н в а р я 2004 года. А пока положение регулируется РД Гостехкомиссии России [25], который, к а к и «Общие критерии», п о замыслу разработчиков, должен быть д и н а м и ч н е е стандарта, модифици¬ руясь вместе с О К . Российские специалисты — активные участники «Проекта ОК», о н и вносят предложения п о доработке «Общих критериев», выступают с д о ­ кладами на конференциях, ведут научно-исследовательские работы, в н е ­ дряют О К в практику различных организаций. Следующим логичным шагом стало бы присоединение России к соглашению «О п р и з н а н и и сер¬ тификатов».

О с н о в н ы е п о н я т и я и и д е и «Общих к р и т е р и е в » О с н о в н ы м свойством, к о т о р ы м д о л ж н ы обладать действительно о б щ и е критерии о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий, является универсальность. Следовательно, о н и н е д о л ж н ы содержать а п р и о р н ы х п р е д п о л о ж е н и й об объекте о ц е н к и . В О К д а н н о е условие в ы п о л н е н о : п о д объектом о ц е н к и (ОО) п о н и м а е т с я а п п а р а т н о - п р о ­ г р а м м н ы й продукт и л и и н ф о р м а ц и о н н а я система с соответствующей документацией. Система — это специфическое воплощение и н ф о р м а ц и о н н ы х техно¬ логий с к о н к р е т н ы м назначением и условиями эксплуатации. Продукт, согласно О К , есть совокупность средств ИТ, предоставляю­ щая определенные функциональные возможности и предназначенная для непосредственного использования или включения в различные системы. В качестве собирательного термина для систем и продуктов п р и м е ­ няют словосочетание «изделие ИТ». О н о может быть к а к уже существую¬ щ и м , так и проектируемым. В первом случае — доработано по результатам о ц е н к и , во втором — сама перспектива подобного контроля способна дис¬ циплинировать разработчиков; так или иначе проведение о ц е н к и должно оказать положительное в л и я н и е на безопасность О О . 25

Курс

Информационная безопасность: основные стандарты и спецификации

Объект о ц е н к и рассматривается в определенном контексте — среде безопасности, в которую включаются все, что имеет отношение к его бе¬ зопасности, а именно: • законодательная среда — законы и нормативные акты, затрагиваю¬ щ и е ОО; • административная среда — положения политик и программ безопас¬ ности, учитывающие особенности О О ; • процедурная среда — физическая среда ОО и меры физической за­ щ и т ы , персонал и его свойства (знания, опыт и т.п.), п р и н я т ы е экс¬ плуатационные и и н ы е процедуры; • программно-техническая среда — предназначение объекта о ц е н к и и предполагаемые области его п р и м е н е н и я , активы (ресурсы), кото¬ р ы е требуют защиты средствами ОО. Д а л ь н е й ш и й этап технологического цикла подготовки к оценке, со¬ гласно «Общим критериям», — описание следующих аспектов среды ОО: • предположения безопасности. О н и выделяют объект оценки из об­ щего контекста, задают границы рассмотрения. Истинность этих предположений принимается без доказательства, а из множества возможных отбирается только то, что заведомо необходимо для обеспечения безопасности О О ; • угрозы б е з о п а с н о с т и О О , н а л и ч и е к о т о р ы х в р а с с м а т р и в а е м о й среде установлено и л и предполагается. О н и характеризуются н е ­ с к о л ь к и м и п а р а м е т р а м и : и с т о ч н и к , метод в о з д е й с т в и я , о п а с н ы е с т о ч к и з р е н и я з л о н а м е р е н н о г о и с п о л ь з о в а н и я у я з в и м о с т и , ресур¬ сы ( а к т и в ы ) , п о т е н ц и а л ь н о п о д в е р ж е н н ы е п о в р е ж д е н и ю . П р и а н а л и з е р и с к о в п р и н и м а ю т с я во в н и м а н и е в е р о я т н о с т ь а к т и в и з а ­ ц и и угрозы и ее у с п е ш н о г о о с у щ е с т в л е н и я , а т а к ж е р а з м е р воз¬ м о ж н о г о ущерба. П о результатам анализа и з м н о ж е с т в а допусти¬ мых угроз отбираются т о л ь к о те, ущерб от к о т о р ы х нуждается в уменьшении; • положения политики безопасности, предназначенные для п р и м е н е ­ н и я к объекту оценки. Для системы И Т такие положения могут быть описаны точно, для продукта — в общих чертах. На о с н о в а н и и предположений, при учете угроз и п о л о ж е н и й поли¬ тики безопасности формулируются цели безопасности для объекта о ц е н ­ к и , н а п р а в л е н н ы е на обеспечение противостояния угрозам и выполне¬ н и е п о л и т и к и безопасности. В зависимости от непосредственного отно¬ ш е н и я к ОО или к среде о н и подразделяются на две группы. Часть целей для среды может достигаться нетехническими (процедурными) мерами. Все остальные (для объекта и среды) носят программно-технический ха­ рактер. Для их достижения к объекту и среде предъявляются требования безопасности. 26

Лекция 2

«Общие критерии». Часть 1. Основные идеи

«Общие критерии» в главной своей части как раз и являются катало¬ гом (библиотекой) требований безопасности. Спектр стандартизованных требований чрезвычайно ш и р о к — это необходимое условие универсаль¬ ности О К . Высокий уровень детализации делает их к о н к р е т н ы м и , допус¬ к а ю щ и м и однозначную проверку, что важно для обеспечения повторяе¬ мости результатов оценки. Наличие параметров обусловливает гибкость требований, а дополнительную возможность ее достижения (через рас­ ширяемость) привносит использование нестандартных (не входящих в каталог О К ) требований. Для структуризации пространства требований в «Общих критериях» введена иерархия класс-семейство-компонент-элемент. Классы определяют наиболее общую (как правило, предметную) группировку требований. Семейства в пределах класса различаются по строгости и другим ха¬ рактеристикам требований. К о м п о н е н т — м и н и м а л ь н ы й набор требований, фигурирующий как целое. Элемент — неделимое требование. Между компонентами могут существовать зависимости. О н и возни¬ кают, когда компонент сам по себе недостаточен для достижения цели бе¬ зопасности. Соответственно, при включении такого компонента необхо¬ д и м о добавить всю «гроздь» его зависимостей. «Общие критерии» содержат два основных вида требований безопас¬ ности: • ф у н к ц и о н а л ь н ы е , соответствующие активному аспекту з а щ и т ы , предъявляемые к ф у н к ц и я м безопасности ОО и реализующим их механизмам; • требования доверия, которые соответствуют пассивному аспекту, предъявляются к технологии и процессу разработки и эксплуатации ОО. Библиотека функциональных требований составляет вторую часть «Общих критериев», а каталог требований доверия — третью (первая часть содержит изложение основных к о н ц е п ц и й О К ) . Сформулировав ф у н к ц и о н а л ь н ы е требования, требования доверия и требования к среде, м о ж н о приступать к оценке безопасности готового изделия ИТ. Для типовых изделий «Общие критерии» предусматривают разработку типовых совокупностей требований безопасности, называе¬ мых п р о ф и л я м и защиты ( П З ) . Для проектируемого изделия за выработкой требований следует раз­ работка краткой спецификации, входящей в задание по безопасности (ЗБ). ( К а к вспомогательный элемент, у п р о щ а ю щ и й создание п р о ф и л е й з а щ и т ы и заданий по безопасности, могут применяться ф у н к ц и о н а л ь н ы е 27

Курс

Информационная безопасность: основные стандарты и спецификации

пакеты ( Ф П ) — неоднократно используемые совокупности к о м п о н е н т о в , объединенных для д о с т и ж е н и я установленных целей безопасности.) Краткая с п е ц и ф и к а ц и я определяет отображение требований на ф у н к ц и и безопасности ( Ф Б ) . «Общие критерии» не предписывают кон¬ кретной методологии или д и с ц и п л и н ы разработки изделий ИТ, но преду¬ сматривают наличие нескольких уровней представления проекта с его д е ­ композицией и детализацией. За требованиями безопасности следует функциональная с п е ц и ф и к а ц и я , затем проект верхнего уровня, необхо­ димое число промежуточных уровней, проект нижнего уровня, после это­ го, в зависимости от типа изделия, исходный код или схемы аппаратуры и, наконец, реализация в виде исполняемых файлов, аппаратных продук­ тов и т.п. Между уровнями представления должно демонстрироваться с о ­ ответствие, то есть все сущности более высоких уровней обязаны фигури­ ровать и «ниже», а «внизу» нет места л и ш н и м сущностям, не обусловлен­ н ы м потребностями более высоких уровней. П р и проведении о ц е н к и изделия И Т главными являются следующие вопросы: • отвечают ли ф у н к ц и и безопасности ОО ф у н к ц и о н а л ь н ы м требова¬ ниям? • корректна ли реализация ф у н к ц и й безопасности? Если оба ответа положительны, м о ж н о говорить о достижении целей безопасности.

О с н о в н ы е п о н я т и я и и д е и «Общей м е т о д о л о г и и оценки безопасности информационных технологий» «Общая методология о ц е н к и безопасности и н ф о р м а ц и о н н ы х техно­ логий» — второй по важности документ (после «Общих критериев»), под­ готовленный в рамках «Проекта ОК». Основная цель «Общей методоло­ гии» — добиться объективности, повторяемости и воспроизводимости ре¬ зультатов оценки. Следуя п р и н ц и п а м структурной д е к о м п о з и ц и и , разработчики выде¬ лили в процессе оценки три задачи (этапа): • входная задача; • задача оценки; • выходная задача. Входная задача имеет дело с представленными для о ц е н к и свиде­ тельствами (далее для краткости м ы будем именовать их свидетельствами оценки). Ее назначение — убедиться, что версии свидетельств корректны и д о л ж н ы м образом з а щ и щ е н ы . Обычно для оценки представляются стабильные, официально выпу­ щ е н н ы е версии свидетельств, однако в ситуациях, когда оценка ведется 28

Лекция 2

«Общие критерии». Часть 1. Основные идеи

параллельно разработке или доработке О О , возможно предъявление ра¬ бочих версий. О ц е н щ и к у вместе со спонсором этого процесса необходи¬ м о составить каталог и в дальнейшем производить к о н ф и г у р а ц и о н н ы й контроль версий. Он обязан обеспечить защиту свидетельств от измене­ н и я и утери, а по о к о н ч а н и и процесса о ц е н к и возвратить их, поместить в архив или уничтожить. На всех этапах оценки должна обеспечиваться конфиденциальность. Задача о ц е н к и в общем случае разбивается на следующие подзадачи: • оценка задания по безопасности; • оценка управления конфигурацией ОО; • оценка документации по передаче ОО потребителю и эксплуатаци¬ о н н о й документации; • оценка документации разработчиков; • оценка руководств; • оценка поддержки жизненного цикла ОО; • оценка тестов; • тестирование; • оценка анализа уязвимостей. Н е р е д к о п р о в о д я т с я в ы б о р о ч н ы е п р о в е р к и , когда вместо всего ( о т н о с и т е л ь н о о д н о р о д н о г о ) м н о ж е с т в а свидетельств анализируется п р е д с т а в и т е л ь н о е п о д м н о ж е с т в о , что п о з в о л я е т с э к о н о м и т ь ресурсы п р и с о х р а н е н и и необходимого у р о в н я д о в е р и я б е з о п а с н о с т и . Р а з м е р в ы б о р к и д о л ж е н быть о б о с н о в а н м а т е м а т и ч е с к и и э к о н о м и ч е с к и , н о п р и а н а л и з е р е а л и з а ц и и объекта о ц е н к и о н д о л ж е н составлять не м е ­ н е е 20%. О ш и б к и , обнаруженные при выборочной проверке, подразделяются на систематические и случайные. После исправления систематической о ш и б к и необходимо произвести новую выборку; после случайной этого не требуется. Допускается выборочная проверка доказательств, тестов, результа­ тов анализа скрытых каналов, в ы п о л н е н и я требований к содержанию и представлению свидетельств, выборочное тестирование. В остальных ситуациях такой способ м о ж н о применять только в и с ­ ключительных случаях, когда полная проверка требует с л и ш к о м много ресурсов по сравнению с другими действиями в процессе о ц е н к и или ког¬ да она не существенно увеличивает доверие безопасности. П р и этом не¬ обходимо обосновать допустимость и целесообразность выборочного подхода. В «Общей методологии» специально подчеркивается, что сами по себе большие размеры и высокая сложность объекта о ц е н к и не оправды­ вают замены полных проверок выборочными, поскольку для оценки бе­ зопасности подобных объектов заведомо требуется много сил и средств. 29

Курс

Информационная безопасность: основные стандарты и спецификации

Необходимый элемент о ц е н к и — проверка внутренней согласован¬ ности каждого из представленных свидетельств, а также внешней взаим¬ ной согласованности различных свидетельств. Внутренняя согласованность проверяется в первую очередь для сущ­ ностей, имеющих несколько представлений: для с п е ц и ф и к а ц и й и проек­ тов всех уровней, а также для руководств. Проверка в н е ш н е й согласованности производится для о п и с а н и й ф у н к ц и й , параметров безопасности, процедур и событий, связанных с бе­ зопасностью, поскольку эти описания могут содержаться в разных доку¬ ментах. Внутренняя несогласованность высокоуровневых сущностей может иметь глобальные последствия для процесса о ц е н к и . Н а п р и м е р , выявле­ н и е противоречий в целях заставляет заново проанализировать требова­ н и я и ф у н к ц и и безопасности. Р а з н ы е подзадачи в п р о ц е с с е о ц е н к и могут в ы п о л н я т ь с я в п р о и з ­ в о л ь н о м п о р я д к е или п а р а л л е л ь н о , о д н а к о существуют з а в и с и м о с т и , н а к л а д ы в а ю щ и е н е к о т о р ы е о г р а н и ч е н и я на очередность в ы п о л н е н и я . Н а и б о л е е о ч е в и д н о е из н и х состоит в т о м , что а н а л и з з а д а н и я п о б е з о ­ п а с н о с т и д о л ж е н в ы п о л н я т ь с я до к а к и х бы то н и было п р о в е р о к объ¬ екта о ц е н к и . Задание по безопасности среди других характеристик объекта оцен¬ ки определяет его границы и спектр рассматриваемых угроз. Следова¬ тельно, процесс и результат оценки одного и того ж е продукта в сочета¬ н и и с р а з н ы м и заданиями могут быть разными. Н а п р и м е р , если в нем с о ­ держатся средства межсетевого экранирования и поддержки виртуальных частных сетей (ВЧС), но в задании по безопасности предусмотрена ис¬ ключительно защита внутренней сети от внешних угроз, то свойства В Ч С - ф у н к ц и й важны л и ш ь в контексте возможности обхода средств эк¬ ранирования. Д а ж е если В Ч С - ф у н к ц и и не обеспечивают конфиденци¬ альности сетевых потоков данных, продукт с таким заданием получит по¬ ложительную оценку. (Заметим, что набор проверяемых требований необходим при серти­ ф и к а ц и и не только по «Общим критериям». Нередко производитель в рекламных целях ограничивается кратким «продукт сертифицирован», что, по сути, бессодержательно и может ввести в заблуждение потребите¬ ля, так как зачастую означает соответствие к а к и м - л и б о условиям общего характера, вроде отсутствия недекларированных возможностей.) Важным моментом, обычно вызывающим много вопросов, является анализ уязвимостей и стойкости ф у н к ц и й безопасности. Цель обоих видов проверки заключается в выявлении степени устойчи­ вости объекта оценки по отношению к атакам, выполняемым нарушителем с определенным (низким, умеренным или высоким) потенциалом нападения. 30

Лекция 2

«Общие критерии». Часть 1. Основные идеи

А н а л и з уязвимостей п р и м е н я е т с я к о всем ф у н к ц и я м б е з о п а с н о с ­ т и ; п р и этом н е делается к а к и х - л и б о п р е д п о л о ж е н и й о т н о с и т е л ь н о к о р р е к т н о с т и их р е а л и з а ц и и , с о х р а н е н и я целостности, в о з м о ж н о с т и обхода и т.п. Анализу стойкости подвергаются только ф у н к ц и и безопасности, ре­ ализованные с п о м о щ ь ю вероятностных или перестановочных механиз­ мов, у которых и проверяется стойкость — базовая, средняя или высокая (базовая означает защищенность от нарушителя с н и з к и м потенциалом нападения). В п р и н ц и п е , все вероятностные ф у н к ц и и м о ж н о считать уяз­ в и м ы м и , а подобный анализ классифицировать как анализ уязвимостей специального вида. Для успешного нападения необходимо сначала идентифицировать, а затем использовать некоторую уязвимость. Оба действия оцениваются с точки зрения временных затрат, необходимой к в а л и ф и к а ц и и , уровня зна¬ н и й об ОО, характера и продолжительности доступа к ОО, необходимых аппаратно-программных и и н ы х ресурсов. Перечисленные составляющие не являются независимыми. Высо­ кая к в а л и ф и к а ц и я может сэкономить время, а специальное оборудование — упростить и ускорить доступ к ОО. Следовательно, если оценивать каж¬ д ы й параметр количественно, то результирующую ф у н к ц и ю , характери¬ зующую серьезность уязвимости, естественно сделать аддитивной. В таблицах 2.1 — 2.5 содержатся условные баллы, присваиваемые па­ раметрам уязвимости в зависимости от того, в какой диапазон или на ка­ кой уровень они попадают. Для получения общего рейтинга нужно вы¬ брать по одному значению из обоих числовых столбцов всех таблиц и сло¬ жить эти десять чисел. П р и оценке стойкости ф у н к ц и й безопасности фа­ за идентификации не рассматривается (предполагается, что уязвимость известна), поэтому достаточно выбрать и сложить пять чисел из послед¬ них столбцов. Диапазон

Идентификация уязвимости

Использование уязвимости

< 0.5 часа

0

0

< суток

2

3

< месяца

3

5

> месяца

5

8

Табл. 2.1. Условные баллы, присваиваемые уязвимости в зависимос­ ти от времени, которое понадобится для ее и д е н т и ф и к а ц и и и и с ­ пользования. 31

Курс

Информационная безопасность: основные стандарты и спецификации

Уровень

Идентификация уязвимости

Использование уязвимости

Любитель

0

0

Специалист

2

2

Эксперт

5

4

Табл. 2.2. Условные баллы, присваиваемые уязвимости в зависимос­ ти от уровня к в а л и ф и к а ц и и , необходимого для ее и д е н т и ф и к а ц и и и использования.

Уровень

Идентификация уязвимости

Использование уязвимости

Отсутствие з н а н и й

0

0

Общедоступные знания

2

2

Конфиденциальные сведения

5

4

Табл. 2.3. Условные баллы, присваиваемые уязвимости в зависимос­ ти от уровня з н а н и й об объекте о ц е н к и , необходимого для ее иден­ т и ф и к а ц и и и использования.

Диапазон

Идентификация уязвимости

Использование уязвимости

< 0.5 часа или доступ незаметен

0

0

< суток

2

4

< месяца

3

6

> месяца

4

9

Табл. 2.4. Условные баллы, присваиваемые уязвимости в зависимос­ ти от времени доступа к объекту о ц е н к и , требуемого для ее иденти­ ф и к а ц и и и использования. 32

Лекция 2

«Общие критерии». Часть 1. Основные идеи

Уровень Отсутствие оборудования Стандартное оборудование Специальное оборудование Заказное оборудование

Идентификация уязвимости

Использование уязвимости

0

0

1

2

3

4

5

6

Табл. 2.5. Условные баллы, присваиваемые уязвимости в зависимос­ ти от аппаратно-программных и иных ресурсов (оборудования), н е ­ обходимых для ее и д е н т и ф и к а ц и и и использования. Если уязвимость м о ж н о идентифицировать и / и л и использовать н е ­ сколькими способами, для каждого из них вычисляется рейтинг и из п о ­ лученных значений выбирается минимальное, то есть уязвимость харак­ теризуется самым простым методом успешного нападения. В табл. 2.6 приведены диапазоны рейтинга, которые характеризуют стойкость ф у н к ц и и безопасности. Диапазон

Стойкость функции безопасности

10 — 17

Базовая

18 — 24

Средняя

> 24

Высокая

Табл. 2.6. Д и а п а з о н ы рейтинга, характеризующие стойкость функ¬ ц и и безопасности. Согласно «Общей методологии», потенциал нападения оценивается в общем и целом по той же схеме, что и степень риска от наличия уязвимос­ тей, с некоторыми очевидными отличиями (например, из нескольких сце­ нариев нападения выбирается худший, с наибольшим потенциалом). Счи­ тается, что он является функцией уровня мотивации злоумышленника, его квалификации и имеющихся ресурсов. Мотивация влияет на выделяемое на атаки время и, возможно, на привлекаемые ресурсы и подбор нападающих. 33

Курс

Информационная безопасность: основные стандарты и спецификации

В табл. 2.7 приведены д и а п а з о н ы рейтинга, иллюстрирующие опре¬ деленный потенциал нападения. Диапазон

Потенциал нападения

< 10

Низкий

10 — 17

Умеренный

18 — 24

Высокий

> 24

Нереально высокий

Табл. 2.7. Д и а п а з о н ы рейтинга, характеризующие потенциал напа­ дения. Нападение может быть успешным, только если его потенциал н е м е н ь ш е рейтинга уязвимости. Отсюда следует, в частности, что уязвимос¬ ти с рейтингом в ы ш е 24 устойчивы к нападению с высоким потенциалом, поэтому их практическое использование злоумышленниками представ­ ляется нереальным. Отметим, что потенциал предполагаемых нападений н а ОО выявля­ ется дважды: при анализе задания п о безопасности для выбора надлежа­ щих мер противодействия и при анализе уязвимостей для определения достаточности выбранных мер и качества их реализации. Рассмотрим п р и м е р анализа стойкости ф у н к ц и и безопасности. Пусть доступ к и н ф о р м а ц и о н н о й системе осуществляется посредством территориально разнесенных терминалов, работа за которыми не контро¬ лируется. Авторизованные пользователи проходят аутентификацию пу­ тем введения паролей, состоящих из четырех различных ц и ф р . Если па­ роль введен неверно, терминал блокируется н а одну минуту. Требуется оценить стойкость такой парольной защиты для заданного пользователя с известным нападающему входным именем. Для нападения выбран один терминал, временем ввода м о ж н о пренебречь. Очевидно, число возможных парольных последовательностей со¬ ставляет 10*9*8*7

= 5040

Для успешного подбора пароля методом полного перебора требуется п р и м е р н о 2520 попыток, которые м о ж н о произвести за 42 часа, что боль¬ ш е суток, но меньше месяца. Н и к а к о й к в а л и ф и к а ц и и , знаний и / и л и о б о 34

Лекция 2

«Общие критерии». Часть 1. Основные идеи

рудования для этого не нужно. Следовательно, чтобы определить стой­ кость ф у н к ц и и , достаточно сложить два числа: 5 из табл. 2.1 и 6 из табл. 2.4. Сумма 11 позволяет сделать вывод, что данная ф у н к ц и я безопаснос­ ти обладает базовой стойкостью и является устойчивой к нападению с н и з к и м потенциалом. Возвращаясь к трем о с н о в н ы м задачам процесса о ц е н к и , рассмот­ р и м последнюю, выходную задачу. Ее цель — сформулировать замечания и получить технический отчет оценки. Текст с замечаниями не является обязательным. О н нужен, если в процессе о ц е н к и выявились какие-либо неясности или проблемы. Технический отчет о ц е н к и — это главный выходной документ, от ка¬ чества которого во многом зависит повторяемость и воспроизводимость результатов о ц е н к и , т. е. возможность их многократного использования. «Общая методология» предписывает следующую структуру подобных от¬ четов: • введение; • архитектурное (высокоуровневое) описание объекта о ц е н к и с рас¬ смотрением основных компонентов; • описание процесса о ц е н к и , п р и м е н е н н ы х методов, методологий, инструментальных средств и стандартов; • представление результатов оценки; • выводы и рекомендации; • список представленных свидетельств; • список с о к р а щ е н и й , словарь терминов; • список замечаний. Изучение «Общей методологии» полезно не только о ц е н щ и к а м , но и разработчикам, так к а к дает представление о вопросах, которые могут возникать в процессе о ц е н к и . К сожалению, более детальное рассмотре­ н и е этого документа выходит за рамки настоящего курса.

35

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 3. «Общие к р и т е р и и » . Часть 2. Ф у н к ц и о н а л ь н ы е т р е б о в а н и я б е з о п а с н о с т и Детально рассматриваются семейства функциональных требований бе­ зопасности, представленные в «Общих критериях». Анализируются достоин­ ства и недостатки принятого в них подхода.

Ключевые слова: ф у н к ц и о н а л ь н ы е требования безопасности, класс, семейство, компонент, библиотека требований,параметризация, н а ­ значение, выбор, итерация, уточнение, аудит безопасности, генера­ ция данных аудита безопасности, выбор событий аудита безопасно¬ сти, хранение событий аудита безопасности, просмотр аудита безо¬ пасности, анализ аудита безопасности, автоматическая реакция ау­ дита безопасности, и д е н т и ф и к а ц и я , аутентификация, аутентифика­ ц и я , з а щ и щ е н н а я от подделок,механизмы одноразовой аутентифи¬ кации, сочетание механизмов аутентификации, определение атри¬ бутов пользователя, связывание пользователь-субъект, отказы аутен¬ т и ф и к а ц и и , секрет, использование ресурсов, отказоустойчивость, приоритет обслуживания, распределение ресурсов, квоты, неотказуемость, свидетельство, в е р и ф и к а ц и я , приватность, анонимность, псевдонимность, псевдоним, невозможность ассоциации, скрыт¬ ность, распределение и н ф о р м а ц и и в пределах О О , многоаспектность и н ф о р м а ц и о н н о й безопасности, импорт данных пользовате¬ ля, экспорт данных пользователя, управление доступом, управление и н ф о р м а ц и о н н ы м и потоками, иерархические атрибуты безопаснос¬ ти, скрытый канал, аутентификация данных, неотказуемость, внут¬ р е н н и й канал, в н е ш н и й канал, защита остаточной и н ф о р м а ц и и , от¬ кат, целостность, архитектурная безопасность, невозможность обхо­ да защитных средств, посредничество при обращениях, разделение доменов, безопасность при сбое, надежное восстановление, физиче¬ ская защита, самотестирование ф у н к ц и й безопасности, согласован­ ность данных ф у н к ц и й безопасности, базовая абстрактная м а ш и н а , обнаружение повторного использования, синхронизация состоя­ н и й , надежные метки времени, криптографическая поддержка, ге­ нерация ключей, распределение ключей, доступ к ключам, уничто¬ ж е н и е ключей, криптографические операции, управление безопас¬ ностью, срок действия атрибутов безопасности, роли управления бе¬ зопасностью, управление сеансами работы пользователей, ограни¬ чение параллельных сеансов, блокирование сеанса, история досту¬ па, доверенный маршрут/канал. 36

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

Классификация функциональных требований безопасности Часть 2 «Общих критериев», представляющая собой весьма обшир¬ ную библиотеку функциональных требований безопасности, описывает 11 классов, 66 семейств, 135 компонентов и содержит сведения о том, ка¬ к и е цели безопасности могут быть достигнуты при современном уровне и н ф о р м а ц и о н н ы х технологий и каким образом. А н а л о г и я между б и б л и о т е к о й ф у н к ц и о н а л ь н ы х т р е б о в а н и й безо­ п а с н о с т и и б и б л и о т е к о й п р о г р а м м н ы х модулей я в л я е т с я в д а н н о м слу­ ч а е д о в о л ь н о п о л н о й . Ф у н к ц и о н а л ь н ы е к о м п о н е н т ы могут быть н е д о к о н ц а к о н к р е т и з и р о в а н ы , п о э т о м у ф а к т и ч е с к и е п а р а м е т р ы подстав¬ л я ю т с я н е в самих « О б щ и х критериях», а в о п р е д е л е н н ы х п р о ф и л я х за­ щ и т ы , з а д а н и я х по б е з о п а с н о с т и и ф у н к ц и о н а л ь н ы х пакетах. ( П р а в д а , в Г О С Т Р И С О / М Э К 15408-2002 п а р а м е т р и з а ц и я н е о ч е н ь удачно на¬ звана «назначением».) В качестве п а р а м е т р о в могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ). Н е к о т о р ы е ф у н к ц и о н а л ь н ы е к о м п о н е н т ы « О б щ и х критериев» за¬ д а ю т с я «с запасом», в н и х в к л ю ч а е т с я с п и с о к в о з м о ж н о с т е й , и з к о т о ­ р ы х затем с п о м о щ ь ю соответствующей о п е р а ц и и в ы б и р а е т с я т о л ь к о т о , что н у ж н о в к о н к р е т н о й с и т у а ц и и . П р и м е р — о б н а р у ж е н и е и / и л и предотвращение определенных нарушений политики безопасности. Н а п р о г р а м м и с т с к о м я з ы к е п о д о б н ы й отбор называется ч а с т и ч н ы м применением. Разумеется, любой ф у н к ц и о н а л ь н ы й компонент допускает много¬ кратное использование (например, чтобы охватить разные аспекты объ¬ екта о ц е н к и ) , называемое в О К итерацией, а также уточнение и добавле¬ н и е дополнительных деталей (последнее м о ж н о считать еще одной фор¬ мой частичного применения). Между компонентами функциональных требований, как и между п р и в ы ч н ы м и библиотечными ф у н к ц и я м и , могут существовать зависимо­ сти. О н и возникают, когда компонент не является самодостаточным и для своей реализации нуждается в привлечении других компонентов. Оче­ видно, размещая в П З , З Б или Ф П подобный компонент, нужно вклю¬ чить туда и всю гроздь зависимостей (это похоже на разрешение внешних ссылок при ф о р м и р о в а н и и выполняемого модуля). Классы функциональных требований «Общих критериев» м о ж н о разделить в зависимости от того, описывают ли о н и элементарные серви¬ сы безопасности или производные, реализуемые на основе элементар¬ ных, направлены ли они на достижение высокоуровневых целей безопас¬ ности или играют инфраструктурную роль. 37

Курс

Информационная безопасность: основные стандарты и спецификации

К первой группе относятся следующие классы: • F A U — аудит безопасности (описывает требования к сервису прото­ колирования/аудита); • F I A — идентификация/аутентификация; • F R U — использование ресурсов (прежде всего — обеспечение отказо¬ устойчивости). Классы второй группы: • F C O — связь (обслуживает неотказуемость отправителя/получате­ ля); • F P R — приватность; Достичь высокоуровневых целей безопасности помогают два класса: • F D P — защита данных пользователя; • F P T — защита ф у н к ц и й безопасности объекта оценки. Наиболее многочисленны классы, и г р а ю щ и е инфраструктурную роль: • F C S — криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции); • F M T — управление безопасностью; • F T A — доступ к объекту о ц е н к и (управление сеансами работы поль¬ зователей); • F T P — доверенный маршрут/канал. Приведенная классификация содержит несколько примечательных моментов. Во-первых, ф у н к ц и о н а л ь н ы е требования О К довольно р а з н о ­ родны. Трудно объяснить, например, почему протоколированию/аудиту соответствует собственный класс, а такой в а ж н е й ш и й , без преувеличе¬ н и я , к л а с с и ч е с к и й сервис безопасности, к а к у п р а в л е н и е доступом, «спрятан» среди других требований защиты данных пользователя. Во-вторых, в О К не выделены архитектурные требования. Правда, некоторые весьма важные архитектурные к о м п о н е н т ы , в числе которых — посредничество при обращениях (частный случай невозможности обхода защитных средств) и разделение доменов, вошли в класс F P T (защита ф у н к ц и й безопасности). В-третьих, требования для защиты данных пользователя и ф у н к ц и й безопасности объекта о ц е н к и разделены, хотя, очевидно, в обоих случаях необходимо применять сходные механизмы. Возможно, такой подход объясняется желанием выделить ядро безопасности и сохранить его ком¬ пактность. Далее м ы кратко рассмотрим все 11 классов функциональных требо¬ ваний безопасности «Общих критериев». 38

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

Классы функциональных требований, описывающие элементарные сервисы безопасности В этом разделе рассматриваются три класса функциональных требо¬ ваний безопасности: • F A U — аудит безопасности; • F I A — идентификация/аутентификация; • F R U — использование ресурсов. Класс F A U состоит из шести семейств, содержащих требования к от¬ бору, протоколированию (регистрации), хранению и анализу данных о действиях и событиях, затрагивающих безопасность объекта оценки. Семейство F A U G E N (генерация д а н н ы х аудита безопасности) включает два компонента. П е р в ы й , F A U G E N . 1 (генерация данных ау¬ дита), специфицирует потенциально подвергаемые протоколированию и аудиту события, вводит понятие уровня протоколирования (минималь­ н ы й , базовый, детализированный, неопределенный), определяет м и н и ­ мум регистрационных данных о событии (дата, время, тип, результат с о ­ бытия, а также идентификатор субъекта). Второй, F A U G E N . 2 (ассоциа­ ц и я идентификатора пользователя), предписывает ассоциировать каждое потенциально регистрируемое событие с идентификатором пользователя, его инициирующего. Семейство F A U S E L (выбор событий аудита безопасности) опреде­ ляет требования к средствам отбора (включения или исключения) собы¬ тий из числа потенциально регистрируемых, которые будут реально про¬ токолироваться и подвергаться аудиту в процессе ф у н к ц и о н и р о в а н и я объекта оценки. Отбор может производиться на основе таких атрибутов, к а к идентификаторы объекта, пользователя, субъекта, узла сети или тип события. Предусматривается задание дополнительных атрибутов. Семейство F A U S T G (хранение событий аудита безопасности) с о ­ держит две пары компонентов. Первая, F A U S T G . 1 ( з а щ и щ е н н о е хране­ н и е журнала аудита) и F A U S T G . 2 (гарантии доступности данных ауди¬ та), специфицирует защиту регистрационного журнала от несанкциони¬ рованного удаления, м о д и ф и к а ц и и , а также от повреждения регистраци­ о н н ы х данных при его переполнении, сбое или атаке. Вторая пара, F A U STG.3 (действия в случае возможной потери данных аудита) и F A U S T G . 4 (предотвращение потери данных аудита), определяет после¬ довательность действий, если объем и н ф о р м а ц и и в регистрационном журнале превышает заранее заданный порог. В их число входят игнориро¬ вание и своевременное запрещение протоколируемых событий, запись поверх самых старых регистрационных данных и т.д. Семейство F A U S A R (просмотр аудита безопасности) предоставля¬ ет право на чтение (полное или выборочное, на основе критериев с логи39

Курс

Информационная безопасность: основные стандарты и спецификации

ч е с к и м и о т н о ш е н и я м и ) регистрационного журнала у п о л н о м о ч е н н ы м пользователям и запрет на доступ к журналу для прочих пользователей. Семейство F A U S A A (анализ аудита безопасности) устанавливает требования к средствам автоматического анализа ф у н к ц и о н и р о в а н и я объекта о ц е н к и , п о з в о л я ю щ и м выявлять возможные нарушения безопас­ ности. Базовым компонентом семейства является F A U S A A . 1 (анализ п о ­ тенциального нарушения), регламентирующий п р и м е н е н и е набора пра¬ вил, основанных на накоплении или объединении событий, сигнализи¬ рующих о вероятном нарушении безопасности. В рамках семейства этот компонент усилен по двум направлениям. В F A U S A A . 2 (выявление а н о ­ малий, опирающееся на профиль) вводится п о н я т и я п р о ф и л я поведения, рейтинга подозрительной активности для каждого пользователя, чьи д е й ­ ствия отражены в профиле, а также порога, превышение которого указы­ вает на ожидаемое нарушение политики безопасности. F A U S A A . 3 (про­ стая эвристика атаки) и F A U S A A . 4 (сложная эвристика атаки) содержит понятие сигнатуры атаки (разной степени сложности) и специфические ф у н к ц и и выявления сигнатур в реальном масштабе времени. Шестое семейство класса F A U — F A U A R P (автоматическая реак­ ц и я аудита безопасности) — определяет действия, которые необходимо предпринять при выявлении возможных нарушений безопасности. Д е й ­ ствия эти характеризуются как «наименее разрушительные». М о ж н о сделать вывод, что в «Общих критериях» н а ш л и отражение такие важные достижения относительно недавнего прошлого, как разра¬ ботка и п р и м е н е н и е методов активного аудита. Шесть семейств класса F I A (идентификация/аутентификация) с о ­ держат требования к ф у н к ц и я м установления и проверки подлинности заявленного идентификатора пользователя, а также связывания атрибу¬ тов безопасности с уполномоченным пользователем. Семейство F I A U I D (идентификация пользователя) включает два компонента и определяет набор действий (например, получение справоч­ ной и н ф о р м а ц и и ) , которые разрешается выполнять до идентификации. Обычно применяют более сильный компонент F I A U I D . 2 — и д е н т и ф и ­ кация до любых действий, выполняемых пользователем при посредниче¬ стве ф у н к ц и й безопасности. С е м е й с т в о F I A U A U ( а у т е н т и ф и к а ц и я пользователя) устроено сложнее. Оно специфицирует т и п ы механизмов аутентификации и ис¬ пользуемые при этом атрибуты. Два первых компонента, F I A U A U . 1 (вы­ бор момента аутентификации) и F I A U A U . 2 (аутентификация до любых действий пользователя), играют (применительно к аутентификации) ту ж е роль, что и к о м п о н е н т ы семейства F I A U I D . На реализацию надеж¬ ной аутентификации, устойчивой к сетевым угрозам, направлены компо¬ н е н т ы F I A U A U . 3 ( а у т е н т и ф и к а ц и я , з а щ и щ е н н а я от п о д д е л о к ) , 40

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

F I A U A U . 4 (механизмы одноразовой аутентификации) и F I A U A U . 5 (сочетание механизмов аутентификации). После периода неактивности пользователя и в ряде других ситуаций уместно п р и м е н е н и е компонента F I A U A U . 6 (повторная аутентификация). Н а к о н е ц , F I A U A U . 7 (аутен­ т и ф и к а ц и я с з а щ и щ е н н о й обратной связью) указывает, как отображать пароль при вводе. Семейство F I A A T D (определение атрибутов пользователя) предус¬ матривает наличие у пользователей не только идентификаторов, но и дру¬ гих атрибутов безопасности, предписываемых политикой безопасности. Обычно после успешной идентификации и аутентификации от име¬ н и пользователя начинает действовать некий процесс (субъект). Семейст­ во F I A U S B (связывание пользователь-субъект) содержит требования по ассоциированию атрибутов безопасности пользователя с этим субъектом. В ы я в л е н и е м и р е а г и р о в а н и е м на неудачи а у т е н т и ф и к а ц и и ведает семейство F I A A F L (отказы а у т е н т и ф и к а ц и и ) . Разумеется, и ч и с л о д о ­ пустимых неудачных п о п ы т о к , и д е й с т в и я , в ы п о л н я е м ы е п р и превы¬ ш е н и и порога неудач, — все это параметры единственного к о м п о н е н т а семейства. Обычно пользователь доказывает свою подлинность, сообщая не¬ что, что знает только он («секрет» в терминологии О К ) . Семейство F I A SOS (спецификация секретов) вводит понятие метрики качества се­ кретов и содержит требования к средствам проверки качества и генера¬ ц и и секретов заданного качества. П р и м е р ы подобных средств — проверка в ы п о л н е н и я технических ограничений на пользовательские пароли в О С U n i x и программные генераторы паролей. В целом класс F I A , по сравнению с F A U , менее конкретен, его ком¬ п о н е н т ы с л и ш к о м параметризованы. Вероятно, это связано с тем, что криптография, без которой надежная и удобная для пользователя аутен­ т и ф и к а ц и я невозможна, находится вне р а м о к «Общих критериев». Класс F R U (использование ресурсов) включает три семейства, при¬ званные р а з н ы м и способами поддерживать высокую доступность. Выполнение требований семейства F R U F L T (отказоустойчивость) должно обеспечить корректную работу всех или хотя бы некоторых функ¬ ц и й объекта о ц е н к и даже в случае сбоев. F R U P R S (приоритет обслуживания) регламентирует действия по защите высокоприоритетных операций от препятствий или задержек со стороны операций с более н и з к и м приоритетом. Семейство F R U R S A (распределение ресурсов) для достижения вы¬ сокой доступности ресурсов привлекает механизм квот. Обращение к вопросу высокой доступности — н е с о м н е н н о е досто¬ инство «Общих критериев», которое, к сожалению, несколько проигры¬ вает из-за отсутствия системного подхода. П о н е я с н ы м п р и ч и н а м в каче41

Курс

Информационная безопасность: основные стандарты и спецификации

стве сущностей одного уровня выделен один из трех высокоуровневых ас¬ пектов доступности и два механизма, способствующих ее поддержанию. За пределами рассмотрения остались надежность и обслуживае­ мость, да и отказоустойчивость может достигаться очень р а з н ы м и спосо­ бами — от использования многопроцессорных конфигураций до органи¬ зации резервных вычислительных центров. П о м и м о двух рассмотренных механизмов поддержания доступности существуют и другие, не менее важные, например, балансировка загруз¬ ки, проактивное управление и т.п. Н а н а ш взгляд, было бы целесообраз­ н ы м обобщить требования к доступности регистрационного журнала (см. в ы ш е семейство F A U S T G ) на случай произвольных ресурсов. Отметим также, что включение в класс F R U конкретных механизмов еще резче обозначает и з л и ш н ю ю обобщенность требований класса F I A .

Классы функциональных требований, описывающие производные сервисы безопасности М ы приступаем к рассмотрению двух следующих классов функцио¬ нальных требований безопасности: • F C O — связь; • F P R — приватность. Класс F C O состоит из двух семейств, F C O N R O и F C O N R R , веда­ ющих неотказуемостью (невозможностью отказаться от факта отправки или получения данных), которая достигается путем избирательной или принудительной генерации допускающих в е р и ф и к а ц и ю свидетельств, позволяющих ассоциировать атрибуты отправителя (получателя) с эле¬ ментами передаваемых данных. Класс F P R (приватность) содержит четыре семейства функциональ¬ ных требований, обеспечивающих защиту пользователя от раскрытия и несанкционированного использования его и д е н т и ф и к а ц и о н н ы х данных. Семейство F P R A N O (анонимность) дает возможность в ы п о л н е н и я действий без идентификатора пользователя. Анонимность может быть полной или выборочной. В первом случае ф у н к ц и и безопасности обяза¬ н ы предоставить заданный набор услуг без запроса идентификатора поль¬ зователя. Во втором предусмотрено более слабое требование, в соответст­ вии с которым идентификатор может запрашиваться, но должен с к р ы ­ ваться от заранее указанных пользователей и / и л и субъектов. Семейство F P R P S E (псевдонимность) обеспечивает условия, когда пользователь может использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то ж е время подотчетным за свои действия. Базовый компонент семейства, F P R P S E . 1 , предписывает выборочную анонимность, а также наличие средств генерации заданного числа псев42

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

д о н и м о в и определения или п р и н я т и я псевдонима от пользователя с ве­ р и ф и к а ц и е й соответствия некоторой метрике псевдонимов. Эти требова­ н и я дополняются в компоненте F P R PSE.2 (обратимая псевдонимность) возможностью определения доверенными субъектами идентификатора пользователя п о п р е д с т а в л е н н о м у псевдониму, а в к о м п о н е н т е F P R PSE.3 (альтернативная псевдонимность) — возможностью опера­ тивного перехода на н о в ы й псевдоним, связь которого со старым п р о я в ­ ляется л и ш ь в заранее оговоренных ситуациях. Семейство F P R U N L (невозможность ассоциации) содержит един¬ ственный компонент, предусматривающий неоднократное п р и м е н е н и е пользователем и н ф о р м а ц и о н н ы х сервисов, не позволяя заданным субъ¬ ектам ассоциировать их между собой и приписывать одному лицу. Невоз¬ можность ассоциации защищает от построения п р о ф и л е й поведения пользователей (см. в ы ш е компонент F A U S A A . 2 ) . С а м ы м с л о ж н ы м в классе F P R является семейство F P R U N O (скрытность). Его требования направлены на то, чтобы пользователь мог незаметно для кого бы то н и было работать с определенными и н ф о р м а ц и ­ о н н ы м и сервисами. Наиболее интересны два из четырех имеющихся к о м ­ понентов семейства. F P R U N O . 2 (распределение и н ф о р м а ц и и , влияю¬ щее на скрытность) предписывает рассредоточить соответствующие дан¬ н ы е по различным частям объекта оценки. Это одно из немногих архитек¬ турных требований «Общих критериев» (правда, выраженное в очень об¬ щей форме). В некотором смысле противоположную роль играет компо¬ нент F P R U N O . 4 (открытость для уполномоченного пользователя), со¬ гласно которому уполномоченные пользователи должны иметь возмож¬ ность наблюдать за тем, как употребляются заданные ресурсы и / и л и услу­ ги. (Как сказал один пессимист: «Я так и знал, что этим все кончится!») Требования приватности ставят очень серьезную проблему многоаспектности и н ф о р м а ц и о н н о й безопасности, заставляют искать баланс к о н ф л и к т у ю щ и х интересов субъектов и н ф о р м а ц и о н н ы х о т н о ш е н и й . Разработчики заданий по безопасности д о л ж н ы учесть и конкретизиро¬ вать эти требования с учетом действующего законодательства и с п е ц и ф и ­ ки систем ИТ.

Защита данных пользователя М ы переходим к рассмотрению классов функциональных требова¬ н и й , направленных на достижение высокоуровневых целей безопасност и . К высокоуровневым целям безопасности относятся защита данных пользователя и защита ф у н к ц и й безопасности объекта о ц е н к и . Соответ­ ствующие классы функциональных требований характеризуются боль­ ш и м числом входящих в них семейств и разнородностью компонентов. 43

Курс

Информационная безопасность: основные стандарты и спецификации

Класс F D P (защита данных пользователя) включает тринадцать се¬ мейств, которые м о ж н о разбить на четыре группы: • политики защиты данных пользователя; • виды защиты данных пользователя; • импорт и экспорт данных пользователя; • защита данных пользователя при передаче между доверенными и з ­ делиями ИТ. В первую группу входят два семейства — F D P A C C (политика управ­ ления доступом) и F D P I F C (политика управления и н ф о р м а ц и о н н ы м и потоками), — играющие, по сути, формальную роль именования политик, распространяющихся на определенные множества субъектов, объектов (потоков) и операций. Управление может быть ограниченным и полным. В последнем случае требуется, чтобы все операции всех субъектов на л ю ­ бом объекте (потоке) из области действия ф у н к ц и й безопасности были охвачены некоторой политикой. Вторая группа объединяет семь семейств. Содержательные аспекты управления доступом ( и н ф о р м а ц и о н н ы м и потоками) регламентируются семействами F D P A C F ( ф у н к ц и и управления доступом) и F D P I F F (функции управления и н ф о р м а ц и о н н ы м и потоками). Первое устроено очень просто, состоит из одного компонента и требует наличия политик, основанных на атрибутах безопасности, а также дополнительных правил, я в н о разрешающих или запрещающих доступ. Требования к ф у н к ц и я м управления и н ф о р м а ц и о н н ы м и потоками, представленные шестью компонентами, существенно сложнее и многооб¬ разнее. Компонент F D P I F F . 1 аналогичен F D P A C F . 1 . Усиливающий его компонент F D P I F F . 2 требует поддержки многоуровневых политик, о с ­ нованных на иерархических атрибутах (метках) безопасности. F D P I F F . 3 , F D P IFF.4 и F D P IFF.5 направлены, соответственно, на ограничение пропускной способности, частичное или полное устранение скрытых ка¬ налов. Наконец, F D P IFF.6 требует осуществления мониторинга скрытых каналов, пропускная способность которых превышает заданный порог. Семейство F D P D A U (аутентификация данных) обслуживает один из видов статической целостности данных. В соответствии с его требова¬ н и я м и ф у н к ц и и безопасности д о л ж н ы предоставить возможность гене¬ рировать и верифицировать свидетельства правильности определенных объектов или типов и н ф о р м а ц и и (компонент F D P D A U . 1 ) , а также (уси­ л и в а ю щ и й компонент F D P D A U . 2 ) идентификатора пользователя, со¬ здавшего свидетельство. Отметим, что компонент F D P D A U . 2 ведает неотказуемостью ав¬ торства, а рассмотренный в ы ш е класс F C O — неотказуемостью отправки и получения данных, что м о ж н о считать разновидностью динамической целостности. 44

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

Семейство F D P I T T (передача в пределах ОО) содержит требова­ н и я , с в я з а н н ы е с з а щ и т о й д а н н ы х пользователя п р и их передаче п о в н у т р е н н и м к а н а л а м объекта о ц е н к и . Предусматривается базовая за­ щ и т а внутренней передачи ( F D P I T T . 1 ) , н а п р а в л е н н а я на предотвра­ щ е н и е р а с к р ы т и я , м о д и ф и к а ц и я ситуаций недоступности, а т а к ж е м о ­ н и т о р и н г целостности д а н н ы х ( F D P I T T . 3 ) . П р и о б н а р у ж е н и и о ш и б о к ц е л о с т н о с т и д о л ж н ы в ы п о л н я т ь с я з а д а н н ы е д е й с т в и я . Эти т р е б о в а н и я усиливаются, соответственно, к о м п о н е н т а м и F D P I T T . 2 и F D P I T T . 4 за счет раздельной передачи д а н н ы х , обладающих р а з н ы м и атрибутам безопасности. Согласно требованиям семейства F D P R I P (защита остаточной ин¬ ф о р м а ц и и ) , унаследованным от «Оранжевой книги», ф у н к ц и и безопас¬ ности д о л ж н ы обеспечить уничтожение любого предыдущего содержания ресурсов при их выдаче и / и л и освобождении. Семейство F D P R O L (откат) предусматривает возможность отмены последней операции и возврат к предшествующему состоянию с сохране­ н и е м целостности данных пользователя. Последнее семейство второй группы, F D P S D I (целостность храни­ мых данных), содержит требования мониторинга целостности всех к о н ­ тролируемых объектов и выполнения заданных действий при обнаруже¬ н и и о ш и б о к целостности хранимых данных. В третью группу семейств класса F D P , обслуживающую импорт и экспорт данных пользователя в/за пределы области действия ф у н к ц и й безопасности объекта о ц е н к и , м ы включили, как и следовало ожидать, два сходных по структуре двухкомпонентных семейства: F D P E T C (экс­ порт) и F D P I T C (импорт). О н и различаются по наличию или отсутст¬ в и ю (использованию или игнорированию) ассоциированных с д а н н ы м и атрибутов безопасности. Согласованная интерпретация атрибутов огово¬ рена экспортером и импортером. В последнюю, четвертую группу (защита данных пользователя при передаче между доверенными изделиями И Т ) входят два семейства, веда­ ю щ и х обеспечением конфиденциальности ( F D P U C T ) и целостности ( F D P U I T ) . Имеется в виду, что одним из доверенных изделий является объект о ц е н к и , а для передачи используются в н е ш н и е (по о т н о ш е н и ю к ОО) каналы. F D P U C T состоит из одного компонента, требующего защиты от несанкционированного раскрытия. В семейство F D P U I T включены более содержательные требования. Во-первых, предусматривается всеобъемлющая защита от м о д и ф и к а ц и и , удаления, вставки и п о в т о р е н и я данных. Во-вторых, обнаруженная ошибка целостности может быть восстановлена как с п о м о щ ь ю отправи¬ теля, доверенного изделия ИТ, так и силами самого объекта оценки. 45

Курс

Информационная безопасность: основные стандарты и спецификации

Обратим в н и м а н и е на различие требований к защите данных поль¬ зователя при передаче по внутреннему (семейство F D P I T T ) и внешнему (семейства F D P U C T и F D P U I T ) каналам, что м о ж н о считать проявле­ н и е м гибкости «Общих критериев». Для внешних каналов требования за­ д а н ы более детально (особенно это касается целостности), однако не пре­ дусматривается обеспечение высокой доступности данных. Отметим также, что за различные аспекты целостности данных пользователя отвечают пять семейств: F D P D A U , F D P ITT (точнее, компонент F D P ITT.3), F D P R O L , F D P S D I и F D P UIT. Первое кон¬ тролирует аутентичность и з б р а н н ы х н а б о р о в д а н н ы х , к о м п о н е н т F D P I T T . 3 и семейство F D P U I T отвечают за (динамическую) целост­ ность передаваемых данных, F D P R O L — за восстановление целостности после сбоев или о ш и б о к , а F D P S D I предусматривает тотальный монито¬ ринг статической целостности. На практике эти варианты целостности контролируются и восста­ навливаются р а з н ы м и методами (например, для выполнения требований F D P D A U естественно воспользоваться к р и п т о г р а ф и ч е с к и м и х э ш ф у н к ц и я м и или ц и ф р о в о й подписью, для F D P S D I — о б ы ч н ы м и к о н ­ трольными суммами), поэтому разнесение требований, относящихся к одному аспекту И Б , представляется в д а н н о м случае оправданным, хотя, на наш взгляд, предпочтительнее было бы ограничиться уровнем компо¬ нентов, а не семейств. П р и м е р о м могут служить рассмотренные в ы ш е к о м п о н е н т ы F A U S A A . 2 и F A U S A A . 4 , обслуживающие различные м е ­ тоды выявления подозрительной активности.

Защита функций безопасности объекта оценки М ы п р о д о л ж а е м р а с с м о т р е н и е к л а с с о в ф у н к ц и о н а л ь н ы х требо¬ в а н и й , н а п р а в л е н н ы х на д о с т и ж е н и е в ы с о к о у р о в н е в ы х целей безо¬ пасности. Класс F P T (защита ф у н к ц и й безопасности объекта оценки) включа¬ ет шестнадцать семейств (больше, чем какой-либо другой класс функци¬ ональных требований), которые м о ж н о разбить на четыре группы: • архитектурная безопасность; • защита реализации ф у н к ц и й безопасности; • защита данных ф у н к ц и й безопасности; • инфраструктурные требования. В а ж н е й ш и й п р и н ц и п архитектурной безопасности — невозмож¬ ность обхода защитных средств. Семейство F P T R V M (посредничество при обращениях) предназначено для достижения этой цели. Входящий в него единственный компонент F P T R V M . 1 (невозможность обхода п о ­ литики безопасности ОО) предписывает, чтобы ф у н к ц и и , проводящие в 46

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

ж и з н ь политику безопасности, вызывались и успешно в ы п о л н я л и с ь прежде любого другого действия, предусмотренного П Б . Е щ е один фундаментальный п р и н ц и п архитектурной безопасности поддерживается семейством F P T S E P (разделение доменов). Минималь¬ но необходимо отделение домена ф у н к ц и й безопасности (компонент F P T S E P . 1 ) , то есть ф у н к ц и и безопасности д о л ж н ы поддерживать домен безопасности, который защищает их от вмешательства не облеченных до¬ верием субъектов и искажений с их стороны (кроме того, должно быть ре¬ ализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений (компонент F P T S E P . 3 ) , то есть предоставление отдельного домена той части функ­ ц и й безопасности, которая проводит в ж и з н ь политики управления до¬ ступом и / и л и и н ф о р м а ц и о н н ы м и потоками. З а щ и т о й р е а л и з а ц и и ф у н к ц и й безопасности з а н и м а ю т с я четыре семейства. С а м о е простое из н и х (по ф о р м у л и р о в к е , но н е по воплоще¬ н и ю и / и л и проверке), F P T F L S (безопасность п р и сбое), содержит тре­ бование, чтобы политика безопасности н е нарушалась п р и сбоях задан¬ ных типов. Обеспечения высокой доступности и корректной работы ф у н к ц и й безопасности вопреки возможным сбоям добивается и более сложное се­ мейство F P T R C V (надежное восстановление). F P T R C V . 4 (восстановле­ н и е ф у н к ц и и ) предписывает, что ф у н к ц и я безопасности либо нормально завершается, либо, для предусмотренных сценариев сбоев, восстанавли­ вается ее устойчивое и безопасное состояние. Первые три его компонен¬ та отвечают за восстановление — ручное, автоматическое и автоматичес¬ кое без недопустимой потери. Для ручного восстановления требуется, чтобы после сбоя ф у н к ц и и безопасности перешли в режим аварийной поддержки, оставляющего возможность возврата ОО к безопасному с о ­ стоянию. Автоматическое восстановление без недопустимой потери оз¬ начает следующее: • при сбоях заданных типов возврат к безопасному состоянию обеспе­ чивается автоматическими процедурами; • безопасное состояние восстанавливается без п р е в ы ш е н и я заранее определенной меры потери данных; • ф у н к ц и и безопасности помогают выяснить, какие объекты могут быть восстановлены, а какие нет. Семейство F P T P H P (физическая защита) требует наличия средств выявления и реагирования на н е с а н к ц и о н и р о в а н н ы й ф и з и ч е с к и й доступ к частям О О , участвующим в реализации ф у н к ц и й безопасности. К о м п о ­ нент F P T P H P . 1 (пассивное обнаружение физического нападения) мож­ но отнести к средствам контроля целостности, так как он требует о д н о ­ значного обнаружения физического воздействия, которое может угро47

Курс

Информационная безопасность: основные стандарты и спецификации

жать в ы п о л н е н и ю ф у н к ц и й безопасности; и н ф о р м а ц и я о наличии или отсутствии подобного воздействия предоставляется по запросу. Усилива­ ю щ и й компонент F P T PHP.2 (оповещение о физическом нападении) предусматривает постоянный контроль за определенными элементами и оповещение назначенного пользователя о подобных происшествиях. Н а ­ к о н е ц , компонент F P T PHP.3 (противодействие физическому нападе¬ нию) требует автоматической реакции, предотвращающей нарушение по¬ литики безопасности. Семейство F P T T S T (самотестирование ф у н к ц и й безопасности) с о ­ стоит из одного компонента, но служит сразу двум целям: выполняет соб¬ ственно самотестирование (при запуске, периодически, по запросу упол¬ номоченного пользователя и т.п.), а также осуществляет контроль целост­ ности данных и выполняемого кода ф у н к ц и й . Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но п о з ­ воляет плавно перейти к третьей группе семейств класса F P T (защита данных ф у н к ц и й безопасности). В эту группу входят шесть семейств, три из которых, F P T ITA, F P T I T C и F P T I T I , отвечают, соответственно, за доступность, конфи¬ денциальность и целостность экспортируемых данных ф у н к ц и й безопас¬ ности. Отметим, что доступность должна быть обеспечена с заданной ве¬ роятностью, а контроль целостности в общем случае предусматривает возможность восстановления поврежденных данных удаленным доверен¬ н ы м изделием ИТ. Семейство F P T T D C содержит требование согласованной интер­ претации данных, совместно используемых ф у н к ц и я м и безопасности ОО и другим доверенным изделием ИТ. Я в н ы х требований к контролю и м ­ портируемых данных в классе F P T (в отличие от F D P ) нет, хотя из сооб¬ ражений симметрии о н и , безусловно, должны присутствовать (см. в ы ш е семейства F D P E T C и F D P ITC). Пятое семейство группы, F P T I T T (передача данных ф у н к ц и й безо¬ пасности в пределах объекта о ц е н к и ) , аналогично рассмотренному ранее семейству из класса защиты данных пользователя F D P ITT (передача в пределах ОО), но не предусматривает обеспечения доступности и разде­ ления по атрибутам при контроле целостности. Справедливости ради ука­ ж е м , однако, что в компоненте F P T I T T . 3 более детально с п е ц и ф и ц и р о ­ ваны обнаруживаемые виды нарушений целостности: м о д и ф и к а ц и я , под¬ мена, перестановка, удаление данных. Семейство F P T T R C отвечает за согласованность данных ф у н к ц и й безопасности при дублировании в пределах ОО. Здесь следует обратить в н и м а н и е на требования элемента F P T TRC.1.2: если части О О , содержа 48

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

щ и е дублируемые д а н н ы е , были разъединены, необходимо обеспечить согласованность таких данных после восстановления соединения перед обработкой запросов к заданным ф у н к ц и я м безопасности. Отметим, что к взаимодействию с удаленным доверенным изделием И Т требование со¬ гласованности данных не предъявляется. В целом ж е остается н е я с н ы м смысл разнесения по разным классам требований защиты данных пользователя и ф у н к ц и й безопасности. П о ­ следние, к р о м е того, трактуются как одноуровневые, для них не предус­ мотрено разделение по атрибутам, что для сложных систем может ока­ заться неприемлемым. Требования, которые м ы назвали инфраструктурными, вошли в с о ­ став четырех семейств. Семейство F P T A M T (тестирование базовой абст­ рактной м а ш и н ы ) определяет требования к тестированию, демонстриру¬ ющему правильность предположений, обеспечиваемых абстрактной ма¬ ш и н о й (аппаратно-программной платформой), лежащей в основе функ¬ ц и й безопасности. Семейство F P T R P L (обнаружение повторного использования) на­ целено на выявление повторного использования сущностей различных типов (например, сообщений, запросов на обслуживание и ответов на за¬ просы) и в ы п о л н е н и е заданных ответных действий. Семейство F P T S S P (протокол синхронизации состояний) на самом деле содержит требования одностороннего или взаимного надежного подтверждения при обмене д а н н ы м и между ф у н к ц и я м и безопасности в распределенной среде. Наконец, семейство F P T S T M (метки времени) требует предоставле­ н и я надежных меток времени в пределах объекта оценки. Подобные мет­ ки необходимы, например, ф у н к ц и я м протоколирования и управления.

Классы функциональных требований, и г р а ю щ и е инфраструктурную роль Криптографические механизмы — обязательный элемент з а щ и щ е н ­ ных систем. Класс F C S (криптографическая поддержка) состоит из 2 се¬ мейств, где в самом общем виде (точнее, в виде параметризованных шаб¬ лонов) рассматриваются генерация, распределение, доступ и уничтоже¬ н и е ключей, а также криптографические операции. Смысл требований состоит в том, что необходимо действовать в соответствии с н е к и м и алго¬ ритмами, длинами ключей и стандартами; какие-либо содержательные с п е ц и ф и к а ц и и отсутствуют. Класс F M T (управление безопасностью), включающий шесть се¬ мейств, регламентирует управление ф у н к ц и я м и безопасности и их д а н ­ н ы м и , атрибутами и ролями безопасности. 49

Курс

Информационная безопасность: основные стандарты и спецификации

Семейство F M T M O F (управление отдельными функциями) содер¬ жит единственное требование: только уполномоченные пользователи (точ¬ нее, уполномоченные идентифицированные роли) могут управлять режи­ мами выполнения, подключением и отключением функций безопасности. К управлению атрибутами безопасности (семейство F M T M S A ) предъявляется больше требований. Во-первых, о н о должно быть доступ­ но только определенным ролям. Во-вторых, необходимо контролировать безопасность присваиваемых значений. В-третьих, при создании объек­ тов должна существовать возможность задания значений, отличных от подразумеваемых. Аналогичным образом устроено семейство F M T M T D (управление д а н н ы м и ф у н к ц и й безопасности), только вместо переопределения подра­ зумеваемых значений в компоненте F M T M T D . 2 специфицируются гра­ н и ч н ы е значения и действия, предпринимаемые в случае выхода за допу¬ стимые границы. F M T R E V (отмена) предусматривает возможность отмены (отзыва) атрибутов безопасности пользователей, субъектов и объектов. F M T S A E позволяет устанавливать сроки действия атрибутов безо­ пасности. Для каждого атрибута могут задаваться действия, выполняемые по истечении срока. Н а к о н е ц , семейство F M T S M R (роли управления безопасностью) предназначено для управления назначением различных ролей пользова­ телям. Предусмотрено наличие правил, управляющих о т н о ш е н и я м и меж­ ду ролями. Шесть семейств простой структуры содержит и класс F T A (доступ к объекту о ц е н к и ) , куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации). Семейство F T A L S A определяет требования по ограничению атри¬ бутов безопасности сеанса, которые может выбирать пользователь. Семейство F T A M C S ограничивает количество параллельных сеан­ сов, предоставляемых пользователю. Оно может быть как о б щ и м , так и индивидуальным (с учетом атрибутов безопасности). Семейство F T A S S L (блокирование сеанса) определяет возмож­ ность блокирования или завершения интерактивного сеанса как по и н и ­ циативе пользователя, так и по инициативе ф у н к ц и й безопасности (если пользователь неактивен заданное время). Действия, осуществляемые при блокировании, описаны весьма детально: • очистка или перезапись устройств отображения, придание их теку¬ щему содержанию нечитаемого вида; • блокирование любых действий по доступу к д а н н ы м пользователя и устройствам отображения, кроме необходимых для разблокирова­ н и я сеанса. 50

Лекция 3

«Общие критерии». Часть 2. Функциональные требования безопасности

Е щ е три однокомпонентных семейства содержат некоторые подроб­ ности открытия сеанса. Семейство F T A T A B (предупреждения перед предоставлением до¬ ступа к ОО) предписывает, чтобы перед открытием сеанса отображалось предупреждающее сообщение относительно несанкционированного ис¬ пользования объекта о ц е н к и . Это одно из весьма немногих ф у н к ц и о н а л ь ­ ных требований без управляющих конструкций назначения или выбора. Семейство F T A T A H (история доступа к ОО) при успешном откры­ тии сеанса определяет требования к отображению истории попыток п о ­ лучить доступ от имени пользователя, выполняющего вход в систему. Здесь проявлена просто-таки трогательная забота о пользователе: огова­ ривается, что справочная и н ф о р м а ц и я не должна исчезать с экрана до то¬ го, как пользователь успеет ее просмотреть. К р о м е того, ф у н к ц и и безопасности могут отказать пользователю в открытии сеанса, основываясь на атрибутах безопасности, такая возмож­ ность с обманчивым названием «Открытие сеанса с ОО» предусмотрена семейством F T A T S E . Если сопоставить степень детализации требований к криптографи¬ ческой поддержке и к управлению сеансами, то различие представляется с л и ш к о м большим. Впрочем, выдержать единый уровень в столь боль¬ ш о м и сложном документе, как «Общие критерии», едва ли возможно. П р и в ы ч н ы е , традиционные требования предъявляет класс F T P (до­ веренный маршрут/канал), состоящий из двух семейств, содержащих по о д н о м у к о м п о н е н т у в к а ж д о м . Д о в е р е н н ы й маршрут (семейство F T P T R P ) позволяет выполнять определенные действия в режиме п р я ­ мого взаимодействия с ф у н к ц и я м и безопасности (например, при началь­ н о й аутентификации). Д о в е р е н н ы е каналы (семейство F T P I T C ) пред­ назначены для передачи критичных по безопасности данных между ф у н к ц и я м и безопасности с другими доверенными изделиями ИТ. Дове¬ р е н н ы й маршрут/канал должен быть логически отличим от других марш¬ рутов (каналов), обеспечивать уверенную и д е н т и ф и к а ц и ю взаимодейст¬ вующих сторон, а также конфиденциальность и целостность передавае¬ мых данных. На этом м ы завершаем рассмотрение функциональных требований безопасности.

51

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 4 . «Общие к р и т е р и и » . Часть 3. Т р е б о в а н и я д о в е р и я б е з о п а с н о с т и Детально рассматриваются семейства требований и оценочные уровни доверия безопасности, представленные в «Общих критериях». Анализируют­ ся достоинства и недостатки принятого в них подхода.

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

Основные понятия и классификация требований доверия безопасности Требования доверия безопасности составляют содержание третьей части «Общих критериев». Доверие в трактовке «Общих критериев» — это основа для уверенно­ сти в том, что изделие И Т отвечает целям безопасности. Доверие обеспе­ чивается через активное исследование (оценку) изделия ИТ. Требования доверия безопасности охватывают весь ж и з н е н н ы й ц и к л изделий И Т и предполагают выполнение следующих действий: • оцениваются задания по безопасности (ЗБ) и п р о ф и л и защиты ( П З ) , ставшие источниками требований безопасности; 52

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

• анализируются различные представления проекта объекта оценки и соответствие между н и м и , а также соответствие каждого из них тре¬ бованиям безопасности; • проверяются процессы и процедуры безопасности, их применение; • анализируется документация; • верифицируются представленные доказательства; • анализируются тесты и их результаты; • анализируются уязвимости объекта оценки; • проводится независимое тестирование, в том числе тестовые «взло­ мы» (называемые далее тестированием п р о н и к н о в е н и я ) . Каждое требование (элемент) доверия принадлежит одному из трех типов: • элементы действий разработчика (помечаются буквой «D» после н о ­ мера элемента); эти действия д о л ж н ы подтверждаться доказатель¬ н ы м материалом (свидетельствами); • элементы представления и содержания свидетельств (помечаются буквой «C»); • элементы действий о ц е н щ и к а (помечаются буквой «E»); о ц е н щ и к и обязаны проверить представленные разработчиками свидетельства, а также выполнить необходимые дополнительные действия (напри¬ мер, провести независимое тестирование). Требования доверия разделены на 10 классов, 44 семейств и 93 ком¬ понента. Классы м о ж н о сгруппировать в зависимости от охватываемых этапов жизненного цикла изделий ИТ. К первой группе, логически предшествующей разработке и оценке О О , принадлежат классы A P E (оценка п р о ф и л я защиты) и A S E (оценка задания по безопасности). Во вторую группу входят классы A D V (разработка), A L C (поддержка ж и з н е н н о г о цикла) и A C M (управление конфигурацией). К этапу получения, представления и анализа результатов разработки м о ж н о отнести классы A G D (руководства), A T E (тестирование) и A V A (оценка уязвимостей). Требования к поставке и эксплуатации составляют содержание клас¬ са A D O . Н а к о н е ц , класс A M A (поддержка доверия) включает требования, п р и м е н я е м ы е после сертификации объекта о ц е н к и на соответствие «Об­ щ и м критериям». П о сравнению с ф у н к ц и о н а л ь н ы м и , требования доверия устроены несколько проще. Во-первых, к их элементам не применяются операции назначения и выбора. Во-вторых, к о м п о н е н т ы в пределах семейства л и ­ н е й н о упорядочены, то есть компонент с большим номером всегда усили¬ вает предыдущий. 53

Курс

Информационная безопасность: основные стандарты и спецификации

Одна из целей «Общих критериев» состоит в м и н и м и з а ц и и усилий разработчиков и о ц е н щ и к о в , направленных на обеспечение заданного уровня доверия. Этому способствует введение семи оценочных уровней доверия (ОУД), содержащих полезные для практического п р и м е н е н и я к о м б и н а ц и и компонентов, упорядоченные по степени усиления. П о в ы ­ сить уровень доверия помогут дополнительные действия: • р а с ш и р е н и е границ объекта оценки; • увеличение уровня детализации рассматриваемых аспектов ОО; • п о в ы ш е н и е строгости рассмотрения, п р и м е н е н и е более формаль¬ ных методов верификации. Далее м ы кратко рассмотрим семейства требований и оценочные уровни доверия безопасности.

Оценка профилей защиты и заданий по б е з о п а с н о с т и Цель требований, вошедших в классы A P E (оценка п р о ф и л я з а щ и ­ ты) и A S E (оценка задания по безопасности), — проверить полноту, не¬ противоречивость и реализуемость П З или З Б . Класс A P E состоит из шести однокомпонентных семейств, соответ¬ ствующих предписанной структуре п р о ф и л е й защиты. Семейство A P E I N T (введение П З ) требует от разработчика пред¬ ставить введение как часть П З , содержащую д а н н ы е и д е н т и ф и к а ц и и и аннотацию П З . О ц е н щ и к должен подтвердить, что имеющаяся и н ф о р м а ­ ц и я удовлетворяет всем требованиям к содержанию и представлению свидетельств, что введение является логически последовательным и вну­ тренне непротиворечивым и согласуется с другими частями П З . Перечис­ л е н н ы е требования к действиям о ц е н щ и к а носят стандартный характер и далее упоминаться не будут. Семейство A P E D E S (описание ОО) специфицирует, что описание объекта о ц е н к и должно включать в себя, как м и н и м у м , тип продукта и его общую характеристику. Требования семейства A P E E N V (среда безопасности) более содержа­ тельны. Необходимо идентифицировать и объяснить все допущения о пред­ полагаемом применении ОО и среде использования, все угрозы, от которых нужна защита, и все политики безопасности, обязательные для исполнения. Е щ е содержательнее требования семейства A P E O B J (цели безопас­ ности). Разработчик должен не только сформулировать цели безопаснос­ ти для объекта оценки и его среды, но и представить их логическое обос­ нование, продемонстрировав противостояние всем идентифицирован¬ н ы м угрозам, охват всех установленных положений политик безопаснос¬ ти и предположений безопасности. 54

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

Основное содержание п р о ф и л я защиты составляют требования бе­ зопасности. К этой части п р и м е н и м ы семейства A P E R E Q (требования безопасности И Т ) и A P E S R E (требования безопасности ИТ, сформули­ р о в а н н ы е в я в н о м виде). Первое относится к стандартным требованиям «Общих критериев», второе — к р а с ш и р е н и я м О К , введенным разработ­ ч и к о м П З . Логическое обоснование требований безопасности должно де¬ монстрировать их решающую роль в достижении целей безопасности. Класс A S E устроен аналогично классу A P E , некоторые отличия вызва­ н ы большей конкретностью задания по безопасности в сравнении с профи­ лем защиты и наличием дополнительньгх разделов. Модифицированы тре­ бования шести рассмотренных выше семейств и добавлены два новых. Семейство A S E TSS (краткая с п е ц и ф и к а ц и я ОО) определяет в са­ м о м общем виде ф у н к ц и и безопасности и меры доверия, предназначен­ н ы е , соответственно, для выполнения функциональных требований и требований доверия. Ф у н к ц и и безопасности и ф у н к ц и о н а л ь н ы е требования сопоставля­ ют таким образом, чтобы м о ж н о было понять, какие из них обслуживают отдельно взятое требование и, наоборот, для в ы п о л н е н и я каких требова­ н и й предназначена каждая из ф у н к ц и й . Логическое обоснование краткой с п е ц и ф и к а ц и и ОО должно демонстрировать, что с п е ц и ф и ц и р о в а н н ы е ф у н к ц и и пригодны для удовлетворения функциональных требований. Ф у н к ц и и , реализованные вероятностными или перестановочными меха­ н и з м а м и , нуждаются в определении требований к стойкости. Если задание по безопасности является конкретизацией некоторых П З , к нему применяются требования семейства A S E P P C (утверждения о соответствии п р о ф и л я м защиты). Подчеркнем важность тщательной разработки и о ц е н к и профилей защиты и заданий по безопасности. Просчеты на стадиях выработки тре­ бований и с п е ц и ф и к а ц и й изделий И Т чреваты особо тяжелыми последст­ в и я м и , исправлять которые сложно и дорого.

Требования доверия к этапу разработки Ф у н к ц и о н а л ь н ы е требования, политика безопасности и краткая с п е ц и ф и к а ц и я объекта о ц е н к и служат отправным пунктом процесса раз¬ работки ф у н к ц и й безопасности ОО. Класс A D V (разработка) состоит из семи многокомпонентных семейств и содержит требования для посте­ пенного п о в ы ш е н и я уровня детализации проекта вплоть до представле­ н и я реализации с демонстрацией соответствия между уровнями. В этом классе предусмотрены три стиля изложения с п е ц и ф и к а ц и й : н е ф о р м а л ь н ы й , полуформальный и формальный — и три способа демон¬ страции соответствия. 55

Курс

Информационная безопасность: основные стандарты и спецификации

Неформальная с п е ц и ф и к а ц и я пишется как о б ы ч н ы й текст с опреде­ лением необходимых терминов. Неформальная демонстрация соответст­ вия требует установления «соответствия по сути». Полуформальная с п е ц и ф и к а ц и я создается при п о м о щ и языка с ог­ р а н и ч е н н ы м синтаксисом и, как правило, сопровождается пояснитель­ н ы м текстом. Полуформальная демонстрация соответствия невозможна без структурированного подхода. В формальной с п е ц и ф и к а ц и и используется математическая нота­ ц и я , а методом демонстрации соответствия служит формальное доказа¬ тельство. Ранжирование компонентов в семействах класса A D V в основном соответствует стилю изложения с п е ц и ф и к а ц и й , ужесточаясь от нефор¬ мального к формальному. В классе A D V выделены четыре уровня детализации проекта: ф у н к ­ циональная с п е ц и ф и к а ц и я , проект верхнего уровня, проект нижнего уровня, представление реализации. Поскольку в конкретной разработке некоторые из них могут отсутствовать, предусмотрена независимая д е ­ монстрация соответствия каждого ф у н к ц и о н а л ь н ы м требованиям. Требования к функциональной спецификации, сосредоточенные в се­ мействе A D V FSP, указывают на обязательность включения в функцио­ нальную спецификацию описания назначения и методов использования всех внешних интерфейсов функций безопасности объекта оценки с добав¬ лением, где это необходимо, детализации результатов, нештатных ситуаций и сообщений об ошибках. И з описания должно быть понятно, как учтены функциональные требования и каким образом строить тесты соответствия. Требования семейства A D V S P M (моделирование политики безо¬ пасности) охватывают еще один аспект ф у н к ц и о н а л ь н о й специфика¬ ц и и — соответствие политике безопасности объекта о ц е н к и , возможнос¬ ти ее осуществления. Средством демонстрации соответствия служит мо¬ дель политики безопасности: необходимо показать, что все ф у н к ц и и бе¬ зопасности в функциональной с п е ц и ф и к а ц и и непротиворечивы и их полнота адекватна модели. Семейство A D V H L D содержит требования к проекту верхнего уровня, описывающего структуру ф у н к ц и й безопасности ОО в терминах подсистем. Проект должен идентифицировать все необходимые базовые аппаратные, программно-аппаратные и / и л и программные средства с представлением ф у н к ц и й , обеспечиваемых поддержкой реализуемых этими средствами механизмов защиты, а также все интерфейсы подсис¬ тем, выделяя те из них, которые предполагаются видимыми извне. К а ж ­ д ы й интерфейс необходимо снабдить описанием назначения и методов использования (то ж е касается и функциональных с п е ц и ф и к а ц и й — это означает демонстрацию соответствия ф у н к ц и о н а л ь н ы м требованиям и 56

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

позволяет организовать тестирование.) Следует выделить подсистемы, осуществляющие политику безопасности. Н а к о н е ц , проект верхнего уровня должен содержать обоснование того, что выбранные механизмы достаточны для реализации ф у н к ц и й безопасности. Требования к проекту н и ж н е г о у р о в н я образуют семейство A D V L L D , в котором детализация доходит до уровня модуля. С п е ц и ф и ­ цируются все интерфейсы модулей (с выделением видимых извне), реа­ лизующих ф у н к ц и и безопасности. Обязательное условие — описание раз­ деления на модули, в ы п о л н я ю щ и е политику безопасности, и прочие, а также предоставление осуществляющих эту политику ф у н к ц и й . Взаимо­ связи между модулями следует определять в терминах имеющихся функ¬ циональных возможностей безопасности и зависимостей от других моду¬ лей. Проект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей, а при необходимос­ ти — возможность создания детального отчета о результатах, нештатных ситуациях и отправки уведомлений об ошибках. О ч е н ь в а ж н о , ч т о б ы п р е д с т а в л е н и е р е а л и з а ц и и (семейство A D V I M P ) однозначно определяло ф у н к ц и и безопасности объекта оцен¬ ки на высоком уровне детализации, тогда впоследствии их возможно со¬ здать без дальнейших проектных решений. Представление реализации должно быть структурировано в малые и п о н я т н ы е разделы, включать в себя описание связей между всеми частями реализации. Семейство A D V R C R ведает соответствием всех имеющихся смеж­ ных уровней представления ф у н к ц и й безопасности. Надо доказать, что все ф у н к ц и о н а л ь н ы е возможности более абстрактного представления, относящиеся к безопасности, правильно и полностью уточнены на менее абстрактном уровне. Требования семейства A D V I N T (внутренняя структура ф у н к ц и й бе­ зопасности ОО) носят технологический характер и сходны по смыслу с требованиями структурированного программирования. Основная идея состоит в м и н и м и з а ц и и сложности процесса и результата разработки пу¬ тем разбиения на модули и использования нескольких уровней абстрак­ ц и и . Здесь придется впервые сформулировать требования к действиям разработчика (до этого м ы ограничивались требованиями к представле¬ н и ю и содержанию свидетельств). Разработчик должен проектировать и структурировать ф у н к ц и и бе¬ зопасности объекта о ц е н к и в модульном, многоуровневом виде, облегчая связи между модулями, а также между уровнями проекта, уменьшая об¬ щую сложность, в особенности тех частей, которые отвечают за политику безопасности, чтобы о н и были простыми для анализа. Разработчик обязан представить о п и с а н и е архитектуры с изложе­ н и е м назначения, интерфейсов, параметров и результатов п р и м е н е н и я 57

Курс

Информационная безопасность: основные стандарты и спецификации

каждого модуля и выделением частей, осуществляющих политику безо¬ пасности, с разбиением на уровни и демонстрацией того, что сложность минимизирована. На наш взгляд, подобные архитектурные требования крайне важны, они заслуживают развития и вынесения в отдельный класс. Есть еще ц е ­ л ы й ряд других архитектурных п р и н ц и п о в , с п е ц и ф и ч н ы х для информа¬ ц и о н н о й безопасности (например, эшелонированность обороны, разно¬ образие защитных средств), которые, к сожалению, остались за рамками «Общих критериев». Технологические требования процедурного характера составляют содержание класса A L C (поддержка жизненного цикла), состоящего из четырех семейств. Прежде всего определяется модель ж и з н е н н о г о цикла (семейство A L C L C D ) , описывающая процессы разработки и сопровождения О О , включая детализацию количественных параметров и / и л и метрик, и с ­ пользуемых для оценки соответствия процесса разработки и принятой модели. Затем следует обосновать выбор инструментальных средств и мето¬ дов (семейство A L C T A T ) . Это относится, в частности, к используемым я з ы к а м программирования, средствам подготовки документации, стан¬ дартам реализации и т.п. Безопасность разработки организуется в соответствии с т р е б о в а н и ­ я м и семейства A L C D V S . Разработчик д о л ж е н н е только иметь о п и с а ­ н и е и о б о с н о в а н и е всех физических, относящихся к персоналу и и н ы х мер безопасности, которые необходимы для обеспечения конфиденци¬ альности и целостности проекта ОО и его р е а л и з а ц и и , но и соблюдать эти м е р ы во время создания и с о п р о в о ж д е н и я О О , что проверяется оценщиками. Важным элементом этапа сопровождения является устранение недо­ статков (семейство A L C F L R ) . Процедуры отслеживания и устранения недостатков фиксируются разработчиком. Они д о л ж н ы содержать требо­ вание представления описания природы и проявлений каждого недостат­ ка безопасности, а также статуса завершения исправления этого недо¬ статка. Разработчик устанавливает процедуру приема и отработки сооб¬ щ е н и й о недостатках, запросов на их исправление с указанием контакт¬ ных адресов и автоматическим распространением сообщений о недостат¬ ках и их исправлении зарегистрированным пользователям. Все ставшие известными недостатки безопасности д о л ж н ы быть исправлены (без со¬ здания новых), а исправления изданы. Управление конфигурацией (УК, класс A C M ) — необходимый инст­ румент коллектива разработчиков. В этот класс входят три семейства, са­ мое содержательное из которых — A C M C A P , с п е ц и ф и ц и р у ю щ е е воз58

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

можности УК. К р о м е выполнения очевидных требований уникальной и д е н т и ф и к а ц и и (маркировки) объекта о ц е н к и , его версий и элементов (с выделением частей, относящихся к ф у н к ц и я м безопасности), необходи¬ м о предусмотреть меры защиты от н е с а н к ц и о н и р о в а н н ы х изменений и меры поддержки генерации ОО. Л ю б о п ы т н о п р и м е н е н и е п р и н ц и п а разделения обязанностей: требу­ ется, чтобы л и ц о , ответственное за включение элемента в У К , не являлось его разработчиком. Семейство A C M S C P специфицирует область действия управления конфигурацией. Она включает представление реализации объекта оцен¬ к и , проектную и тестовую документацию, документацию пользователя и администратора, документацию У К , и н ф о р м а ц и ю о недостатках безопас¬ ности и инструментальные средства разработки. Для уменьшения числа возможных о ш и б о к управление конфигура¬ цией следует максимально автоматизировать — в этом смысл требований семейства A C M A U T . Автоматизация должна распространяться на защи¬ ту от н е с а н к ц и о н и р о в а н н ы х и з м е н е н и й , генерацию объекта о ц е н к и , вы¬ я в л е н и е различий между версиями и на нахождение элементов, подверга­ ющихся воздействию определенной м о д и ф и к а ц и и . В целом требования доверия к этапу разработки сформулированы на высоком уровне, в соответствии с современной технологией создания и сопровождения сложных систем.

Требования к этапу получения, представления и а н а л и з а результатов р а з р а б о т к и М ы переходим к рассмотрению трех следующих классов требований доверия безопасности: A G D (руководства), A T E (тестирование) и A V A (оценка уязвимостей). Класс A G D состоит из двух однокомпонентных семейств, где сфор¬ мулированы требования к руководствам администратора ( A G D A D M ) и пользователя ( A G D U S R ) . Руководство администратора должно содержать: • описание особенностей управления ОО безопасным способом; • описание ф у н к ц и й и интерфейсов администрирования; • предупреждения относительно ф у н к ц и й и привилегий, подлежащие контролю; • описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО; • описание всех параметров безопасности, контролируемых админис¬ тратором, с указанием безопасных значений; • описание событий, относящихся к безопасности; 59

Курс

Информационная безопасность: основные стандарты и спецификации

• описание всех требований безопасности к среде ИТ, имеющих отно¬ ш е н и е к администратору. В руководство пользователя необходимо включить: • описание ф у н к ц и й и интерфейсов объекта о ц е н к и , доступных поль¬ зователям; • описание п р и м е н е н и я доступных пользователям ф у н к ц и й безопас¬ ности; • предупреждения относительно доступных пользователям ф у н к ц и й и привилегий, которые следует контролировать; • изложение всех обязанностей пользователя по безопасной эксплуа¬ тации ОО. Класс A T E (тестирование) состоит из четырех семейств, содержащих требования к полноте, глубине, способам и результатам тестирования ф у н к ц и й безопасности на предмет их соответствия с п е ц и ф и к а ц и я м . Разработчик выполняет функциональное тестирование (семейство A T E F U N ) , обосновывает достаточность глубины (семейство A T E D P T ) и покрытия ( A T E C O V ) тестов. П р и ф у н к ц и о н а л ь н о м тестировании необходимо проверить все ф у н к ц и и безопасности, не ограничиваясь подтверждением наличия тре­ буемых ф у н к ц и й безопасности, но проверяя также, отсутствуют ли неже­ лательные р е ж и м ы ф у н к ц и о н и р о в а н и я . Анализ глубины должен показать достаточность тестов для демонст­ р а ц и и того, что ф у н к ц и и безопасности выполняются в соответствии с проектами верхнего и нижнего уровней и представлением реализации. Важно, чтобы анализ покрытия демонстрировал полное соответст¬ вие между представленными тестами и описанием ф у н к ц и й безопаснос¬ ти в ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и . Требуется полностью проверить все в н е ш н и е интерфейсы ф у н к ц и й безопасности. Семейство A T E I N D (независимое тестирование) регламентирует действия оценщиков. О ц е н щ и к у следует протестировать необходимое подмножество ф у н к ц и й безопасности и подтвердить, что объект о ц е н к и функционирует в соответствии со с п е ц и ф и к а ц и я м и , а также выполнить некоторые или все тесты из тестовой документации, чтобы верифициро¬ вать результаты, полученные разработчиком. Один из ключевых моментов о ц е н к и безопасности изделия И Т — оценка уязвимостей (класс A V A ) , отправным пунктом которой является анализ уязвимостей (семейство A V A V L A ) , в ы п о л н я е м ы й разработчиком и о ц е н щ и к о м . Четыре компонента этого семейства ранжированы по уровню строгости анализа и потенциалу предполагаемого нарушителя. Анализ, проводимый разработчиком, направлен на п о и с к и иденти¬ ф и к а ц и ю уязвимостей, обоснование невозможности их использования в предполагаемой среде и стойкости объекта о ц е н к и к я в н ы м нападениям. 60

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

Прежде всего о ц е н щ и к обязан проверить, что ОО противостоит на­ падениям нарушителя, соответственно, с н и з к и м ( A V A V L A . 2 ) , умерен­ н ы м (AVA V L A . 3 ) или высоким (AVA V L A . 4 ) потенциалом. Для достиже­ н и я этой цели в общем случае проводится независимый анализ уязвимо­ стей, а затем оцениваются возможности использования и д е н т и ф и ц и р о ­ ванных разработчиком и дополнительно выявленных уязвимостей, п о ­ средством проведения тестовых атак. Анализ стойкости ф у н к ц и й безопасности объекта о ц е н к и (семейст¬ во A V A S O F ) проводится на уровне реализующих механизмов. П о своей направленности он аналогичен анализу уязвимостей. Выше, в разделе «Основные п о н я т и я и идеи «Общей методологии оценки безопасности и н ф о р м а ц и о н н ы х технологий», м ы подробно рассматривали эту тему. Здесь ж е отметим, что требования единственного компонента семейства A V A S O F носят формальный характер: для каждого механизма, имеюще¬ го утверждение относительно стойкости ф у н к ц и и безопасности, анализ должен показать, что стойкость достигает или превышает уровень, опре¬ д е л е н н ы й в п р о ф и л е защиты или задании по безопасности. Требования семейства A V A M S U (неправильное применение) на¬ правлены на то, чтобы исключить возможность такого конфигурирова¬ н и я и / и л и п р и м е н е н и я объекта о ц е н к и , которое администратор или пользователь считают безопасным, в то время как оно таковым не являет­ ся. Необходимо обеспечить отсутствие в руководствах вводящих в за¬ блуждение, необоснованных и противоречивых указаний и наличие безо¬ пасных процедур для всех режимов ф у н к ц и о н и р о в а н и я . Опасные состоя­ н и я д о л ж н ы легко выявляться. Задача решается следующим образом: в представленных разработчи­ ком руководствах идентифицируются все возможные р е ж и м ы эксплуата­ ц и и объекта о ц е н к и , включая действия после сбоя или о ш и б к и в работе, их последствия и значение для безопасности эксплуатации. Прилагается с п и с о к всех предположений относительно среды эксплуатации и требо¬ ваний к в н е ш н и м мерам безопасности. О ц е н щ и к должен повторить все процедуры конфигурирования и ус­ тановки, а также выборочно другие процедуры для подтверждения того факта, что объект о ц е н к и м о ж н о безопасно конфигурировать и использо¬ вать, применяя только представленные руководства. К р о м е того, он обя¬ зан выполнить независимое тестирование и проверить, смогут ли адми¬ нистратор или пользователь выяснить, руководствуясь документацией, что ОО сконфигурирован или используется о п а с н ы м образом. Анализ скрытых каналов, регламентируемый семейством A V A C C A , крайне сложен и концептуально, и технически (см., например, статью [14]). Здесь легко требовать, но трудно выполнять. Согласно «Общим критериям», разработчик проводит исчерпывающий п о и с к скрытых ка61

Курс

Информационная безопасность: основные стандарты и спецификации

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

Требования к поставке и эксплуатации, поддержка доверия Класс A D O (поставка и эксплуатация) содержит требования к про¬ цедурам поставки, установки, генерации и запуска объекта о ц е н к и . Требования к поставке сосредоточены в трехкомпонентном семействе A D O D E L . Разработчик должен документировать и использовать процеду¬ р ы поставки объекта оценки или его частей. Необходимо описать, каким образом различные процедуры и технические меры обеспечивают обнару¬ жение ( A D O D E L . 2 ) или предотвращение ( A D O D E L . 3 ) модификаций либо иного расхождения между оригиналом разработчика и версией, полу­ ченной в месте применения, а также обнаружение попыток подмены от имени разработчика в тех случаях, когда последний ничего не поставлял. Семейство A D O I G S (установка, генерация и запуск) предназначе­ но для безопасного перехода к этапу эксплуатации. Процедуры безопас­ ной установки, генерации и запуска объекта о ц е н к и документируются разработчиком. Документация должна содержать описание процедур, обеспечивающих протоколирование применявшихся о п ц и й генерации, для точного ответа на вопрос, как и когда был сгенерирован ОО. Класс A M A (поддержка доверия) включает четыре семейства и с о ­ держит требования, к которым обращаются после сертификации объекта оценки. О н и помогают (по возможности э к о н о м н о , без полной повтор¬ ной оценки) сохранить уверенность в том, что ОО продолжает отвечать своему заданию по безопасности после изменений в нем или в его среде. Речь идет о выявлении новых угроз или уязвимостей, изменении в требо­ ваниях пользователя, а также об исправлении ошибок. Действия по поддержке доверия носят циклический характер. К а ж ­ дая итерация цикла состоит из двух фаз: • приемка объекта оценки для поддержки; • мониторинг ОО. Фаза приемки включает разработку плана поддержки доверия и категорирование компонентов объекта о ц е н к и по их в л и я н и ю на безопас­ ность. Элементы фазы мониторинга — представление описания текущей версии ОО и в ы п о л н е н и е анализа в л и я н и я и з м е н е н и й на безопасность. 62

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

Возможно, в к о н ц е итерации выяснится, что план или категорирование нуждаются в уточнении или изменении; тогда новая итерация начнется с повторной приемки ОО. Ц и к л поддержки доверия не может выполняться бесконечно. В к о н ­ це к о н ц о в , либо накопится много мелких и з м е н е н и й , либо потребуются крупные, и тогда переоценка станет неизбежной. Семейство A M A A M P (план поддержки доверия) регламентирует вход в ц и к л поддержки доверия. Оно идентифицирует процедуры, кото­ р ы е выполняет разработчик при изменении объекта о ц е н к и или его сре­ ды. П л а н поддержки доверия должен содержать краткое описание О О , включающее предоставляемые им ф у н к ц и о н а л ь н ы е возможности безо¬ пасности, идентифицировать сертифицированную версию ОО и ссылать¬ ся на результаты о ц е н к и , определять предусматриваемые пределы изме­ н е н и я О О , содержать описание ж и з н е н н о г о цикла ОО, текущие п л а н ы новых выпусков О О , аудита и следующей переоценки, а также включать в себя краткое описание любых запланированных и з м е н е н и й , которые, как ожидается, будут иметь заметное в л и я н и е на безопасность. П л а н необхо­ д и м о дополнить описанием процедур, которые предполагается п р и м е ­ нять для поддержки доверия и куда, как м и н и м у м , следует включить п р о ­ цедуры управления конфигурацией, поддержки свидетельства доверия, в ы п о л н е н и я анализа в л и я н и я произведенных изменений на безопас­ ность, устранения недостатков. П л а н поддержки доверия опирается на отчет о категорировании компонентов ОО для сертифицированной версии О О , специфицируемый семейством A M A CAT. Категорирование критически важно для анализа в л и я н и я на безопасность и переоценки ОО. Отчет должен распределить по категориям каждый компонент, который может быть идентифициро¬ ван в каждом представлении ф у н к ц и й безопасности от наиболее до наи¬ менее абстрактного, согласно его о т н о ш е н и ю к безопасности. К а к мини¬ мум, необходимо разделить к о м п о н е н т ы ОО на осуществляющие и не осуществляющие политику безопасности. Следует описать примененную схему категорирования, чтобы сделать в о з м о ж н ы м распределение по ка­ тегориям новых компонентов, а также перераспределение существующих вследствие и з м е н е н и й в ОО или в его задании по безопасности. Н а к о н е ц , отчет должен идентифицировать средства разработки, м о д и ф и к а ц и я к о ­ торых влияет на доверие. Назначение семейства A M A E V D (свидетельство поддержки доверия) состоит в том, чтобы в рамках фазы мониторинга убедиться в поддержке разработчиком доверия безопасности объекта оценки в соответствии с представленным планом. Семейство содержит требования к документации поддержки доверия для текущей версии ОО. Документация должна вклю¬ чать список текущей конфигурации ОО и список идентифицированных 63

Курс

Информационная безопасность: основные стандарты и спецификации

уязвимостей, подтверждать следование процедурам, описанным в плане поддержки доверия. Для каждой уязвимости в текущей версии требуется по¬ казать, что она не может быть использована в предполагаемой среде ОО. О ц е н щ и к должен подтвердить, что все и з м е н е н и я , документирован­ н ы е при анализе в л и я н и я на безопасность для текущей версии О О , нахо­ дятся в пределах, установленных планом поддержки доверия, и что ф у н к ­ циональное тестирование выполнялось на текущей версии ОО соразмер­ но поддерживаемому уровню доверия. Анализ влияния на безопасность (семейство A M A SIA), проведен­ н ы й разработчиком, позволит оценить последствия и з м е н е н и й , воздейст¬ вующих на с е р т и ф и ц и р о в а н н ы й объект оценки. П о его результатам гото¬ вится документ, идентифицирующий с е р т и ф и ц и р о в а н н ы й О О , откуда была получена текущая версия, а также все новые и м о д и ф и ц и р о в а н н ы е компоненты. Для каждого и з м е н е н и я , воздействующего на задание по бе­ зопасности или на представления ф у н к ц и й безопасности, следует о п и ­ сать все последствия, к которым оно приводит на более низких уровнях представления, идентифицировать все ф у н к ц и и безопасности и к о м п о ­ ненты, категорированные к а к осуществляющие политику безопасности и подверженные влиянию со стороны данного изменения. Если изменение приводит к м о д и ф и к а ц и и представления реализа¬ ц и и , следует идентифицировать тесты, подтверждающие правильность ф у н к ц и о н и р о в а н и я новой версии. Н а к о н е ц , необходимо проанализировать в л и я н и е и з м е н е н и й на оценку уязвимости, управление конфигурацией, руководства, поставку и эксплуатацию, поддержку ж и з н е н н о г о цикла объекта оценки. О ц е н щ и к должен удостовериться, что при анализе в л и я н и я на безо­ пасность все изменения документированы на приемлемом уровне детали зации вместе с соответствующим строгим обоснованием поддержки дове¬ р и я в текущей версии ОО. На этом м ы завершаем рассмотрение семейств требований доверия безопасности.

Оценочные уровни доверия безопасности В «Общих критериях» определено семь упорядоченных по возраста­ н и ю оценочных уровней доверия (ОУД) безопасности, содержащих рас­ считанные на многократное применение комбинации требований доверия (не более одного компонента из каждого семейства). Наличие такой шкалы дает возможность сбалансировать получаемый уровень доверия со сложно­ стью, сроками, стоимостью и самой возможностью его достижения. Предполагается, что в профилях защиты и заданиях по безопаснос­ ти будут фигурировать или сами оценочные уровни, или их усиления, п о 64

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

лученные путем р а с ш и р е н и я требований (за счет добавления к ОУД н о ­ вых компонентов) либо увеличения строгости и / и л и глубины оценки (по¬ средством замены компонентов более сильным вариантом из того ж е се¬ мейства). Таким образом, ОУД играют роль опорных точек в многомер¬ н о м пространстве требований доверия. Отметим, что в ОУД не включены требования классов A P E (оценка п р о ф и л я защиты), A S E (оценка задания по безопасности) и A M A (под­ держка доверия), поскольку они находятся вне пределов основного ц и к ­ ла разработки изделий ИТ. Оценочный уровень доверия 1 (ОУД1), предусматривающий функ­ циональное тестирование, п р и м е н и м , когда требуется некоторая уверен¬ ность, что объект о ц е н к и работает безукоризненно, а угрозы безопаснос¬ ти не считаются серьезными. Его м о ж н о достичь без п о м о щ и разработчи¬ ка и с м и н и м а л ь н ы м и затратами посредством анализа функциональной с п е ц и ф и к а ц и и , с п е ц и ф и к а ц и и интерфейсов, эксплуатационной доку¬ ментации в сочетании с независимым тестированием. Оценочный уровень доверия 2 (ОУД2) предусматривает структурное тестирование и доступ к части проектной документации и результатам те¬ стирования разработчиком. ОУД2 п р и м е н и м , когда разработчикам или пользователям требуется независимо получаемый умеренный уровень д о ­ верия при отсутствии доступа к полной документации по разработке. В д о п о л н е н и е к ОУД1 предписывается анализ проекта верхнего уровня. Анализ должен быть поддержан независимым тестированием ф у н к ц и й безопасности, актом разработчика об испытаниях, основанных на ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и , в ы б о р о ч н ы м н е з а в и с и м ы м под¬ тверждением результатов тестирования разработчиком, анализом стойко­ сти ф у н к ц и й и свидетельством поиска я в н ы х уязвимостей. Требуется на¬ личие списка конфигурации ОО с уникальной идентификацией элемен¬ тов конфигурации и свидетельства безопасных процедур поставки. Оценочный уровень доверия 3 (ОУД3), предусматривающий систе­ матическое тестирование и проверку, позволяет достичь максимально возможного доверия при использовании обычных методов разработки. О н п р и м е н и м в тех случаях, когда разработчикам или пользователям тре­ буется умеренный уровень доверия на основе всестороннего исследова­ н и я объекта оценки и процесса его разработки. П о сравнению с ОУД2 сюда добавлено требование, которое предпи¬ сывает разработчику создавать акт об испытаниях с учетом особенностей не только ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и , но и проекта верхнего уров¬ ня. К р о м е того, требуется контроль среды разработки и управление кон¬ фигурацией объекта о ц е н к и . Оценочный уровень доверия 4 (ОУД4) предусматривает системати­ ческое проектирование, тестирование и просмотр. Он позволяет достичь 65

Курс

Информационная безопасность: основные стандарты и спецификации

доверия, максимально возможного при следовании общепринятой прак­ тике коммерческой разработки. Это самый высокий уровень, на который, вероятно, э к о н о м и ч е с к и целесообразно ориентироваться для существую¬ щих типов продуктов. ОУД4 характеризуется анализом ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и , полной с п е ц и ф и к а ц и и интерфейсов, эксплуатационной документации, проектов верхнего и нижнего уровней, а также подмножества реализа¬ ц и и , применением неформальной модели политики безопасности ОО. Среди других дополнительных требований — независимый анализ уязви­ мостей, демонстрирующий устойчивость к попыткам п р о н и к н о в е н и я н а ­ рушителей с н и з к и м потенциалом нападения, и автоматизация управле­ н и я конфигурацией. Отличительные особенности оценочного уровня доверия 5 (ОУД5) — полуформальное проектирование и тестирование. С его п о м о щ ь ю дости¬ гается доверие, максимально возможное при следовании строгой практи¬ ке коммерческой разработки, поддержанной умеренным применением специализированных методов обеспечения безопасности. ОУД5 востре­ бован, когда нужен высокий уровень доверия и строгий подход к разра¬ ботке, не влекущий и з л и ш н и х затрат. Для достижения ОУД5 требуется формальная модель политики безо¬ пасности ОО и полуформальное представление функциональной специ¬ ф и к а ц и и и проекта верхнего уровня, полуформальная демонстрация с о ­ ответствия между н и м и , а также модульная структура проекта ОО. Акт об испытаниях должен быть основан еще и на проекте нижнего уровня. Н е ­ обходима устойчивость к попыткам п р о н и к н о в е н и я нарушителей с уме­ р е н н ы м потенциалом нападения. Предусматривается проверка правиль¬ ности анализа разработчиком скрытых каналов и всестороннее управле¬ н и е конфигурацией. Оценочный уровень доверия 6 (ОУД6) характеризуется полуфор­ мальной верификацией проекта. О н позволяет получить высокое доверие путем п р и м е н е н и я специальных методов проектирования в строго кон¬ тролируемой среде разработки при производстве высококачественных изделий И Т и при защите ценных активов от значительных рисков. Особенности ОУД 6: • структурированное представление реализации; • полуформальное представление проекта нижнего уровня; • иерархическая структура проекта О О ; • устойчивость к попыткам п р о н и к н о в е н и я нарушителей с высоким потенциалом нападения; • проверка правильности систематического анализа разработчиком скрытых каналов; • использование структурированного процесса разработки; 66

Лекция 4

«Общие критерии». Часть 3. Требования доверия безопасности

• полная автоматизация управления конфигурацией ОО. Оценочный уровень доверия 7 (ОУД7), предусматривающий ф о р ­ мальную в е р и ф и к а ц и ю проекта, п р и м е н и м к разработке изделий И Т для использования в ситуациях чрезвычайно высокого риска или там, где в ы ­ сокая ценность активов оправдывает п о в ы ш е н н ы е затраты. На седьмом уровне дополнительно требуются: • формальное представление ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и и про¬ екта верхнего уровня и формальная демонстрация соответствия между н и м и ; • модульная, иерархическая и простая структура проекта ОО; • добавление представления реализации как основы акта об испыта­ ниях; • полное независимое подтверждение результатов тестирования раз¬ работчиком. На наш взгляд, оценочные уровни доверия выбраны очень удачно; их усиление в профилях защиты и заданиях по безопасности в подавляю¬ щ е м большинстве случаев носит н е п р и н ц и п и а л ь н ы й характер. Дополнительную и н ф о р м а ц и ю по «Общим критериям» м о ж н о н а й ­ ти в книге [2].

67

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 5. П р о ф и л и з а щ и т ы , р а з р а б о т а н н ы е на о с н о в е «Общих к р и т е р и е в » . Часть 1 . О б щ и е т р е б о в а н и я к сервисам безопасности Определяется роль профилей защиты, описывается их структура. Вы­ деляются общие требования к сервисам безопасности.

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

Общие положения М ы приступаем к анализу п р о ф и л е й защиты и их проектов, постро­ енных на основе «Общих критериев» и описывающих сервисы безопасно­ сти, их к о м б и н а ц и и и приложения. В первой части выделяются общие требования, которые могут войти в состав применимого ко всем сервисам функционального пакета, упрощающего разработку и п о н и м а н и е профи¬ лей для конкретных сервисов. Анализ п р о ф и л е й защиты позволяет оце¬ нить сильные и слабые стороны «Общих критериев», наметить возмож¬ н ы е направления новых исследований. 68

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

« О б щ и е критерии» в п р и м е н е н и и к о ц е н к е безопасности изделий и н ф о р м а ц и о н н ы х технологий ( И Т ) я в л я ю т с я , по сути, метасредствами, з а д а ю щ и м и систему п о н я т и й , в т е р м и н а х к о т о р ы х д о л ж н а п р о и з в о ­ диться о ц е н к а , н о не п р е д о с т а в л я ю щ и х к о н к р е т н ы х н а б о р о в требова­ н и й и к р и т е р и е в , п о д л е ж а щ и х обязательной п р о в е р к е . Эти т р е б о в а н и я и к р и т е р и и фигурируют в п р о ф и л я х з а щ и т ы ( П З ) и заданиях по безо­ п а с н о с т и ( З Б ) (см., н а п р и м е р , [62], [26], [ G T K R R P P ] ) . П р о ф и л и защиты, в отличие от заданий по безопасности, носят уни¬ версальный характер: они характеризуют определенный класс изделий И Т вне зависимости от с п е ц и ф и к и условий п р и м е н е н и я . И м е н н о о ф и ц и ­ ально п р и н я т ы е п р о ф и л и защиты образуют построенную на основе «Об­ щ и х критериев» (ОК) и используемую на практике нормативную базу в области и н ф о р м а ц и о н н о й безопасности ( И Б ) . В настоящее время такая база и в мире (см., например, [95], [100]), и в России только создается. В нашей стране эту работу курирует Государст­ венная техническая к о м и с с и я при Президенте Р Ф (Гостехкомиссия Рос¬ сии). П р о ф и л и защиты могут характеризовать отдельные сервисы безо¬ пасности, к о м б и н а ц и и подобных сервисов, реализованные, например, в операционной системе, а также прикладные изделия ИТ, для которых обеспечение и н ф о р м а ц и о н н о й безопасности критически важно (пример — смарт-карты). Нас в первую очередь будут интересовать п р о ф и л и защиты сервисов безопасности, поскольку последние являются универсальными строи­ тельными блоками, п о з в о л я ю щ и м и формировать з а щ и т н ы е рубежи и н ­ ф о р м а ц и о н н ы х систем ( И С ) различного назначения, разной степени критичности. В курсе [3] «Основы и н ф о р м а ц и о н н о й безопасности» выде¬ л е н ы следующие базовые сервисы безопасности: • идентификация и аутентификация; • управление доступом; • протоколирование и аудит; • шифрование; • контроль целостности; • экранирование; • анализ защищенности; • обеспечение отказоустойчивости; • обеспечение безопасного восстановления; • туннелирование; • управление. В силу разных п р и ч и н не для всех перечисленных сервисов п р о ф и л и защиты разработаны или разрабатываются. Так, традиционные протоко¬ лирование и аудит, отказоустойчивость и безопасное восстановление 69

Курс

Информационная безопасность: основные стандарты и спецификации

адекватно описываются соответствующими классами функциональных требований «Общих критериев», поэтому формировать на их основе при¬ вычные классы з а щ и щ е н н о с т и относительно несложно (однако сделать это, разумеется, все ж е необходимо). Выделение сервисов туннелирования и управления еще не вошло в общепринятую практику, поэтому пока они обойдены вниманием разра¬ ботчиков П З . Н а к о н е ц , криптография во многих странах (да и в самих «Общих критериях») является «особой точкой» безопасности, поэтому создание профилей защиты для сервисов ш и ф р о в а н и я и контроля целостности, а также для других сервисов, реализация которых опирается на криптогра¬ фические механизмы, затруднено по законодательным и / и л и организа¬ ц и о н н ы м причинам. (Заметим, что, хотя сложившееся вокруг к о м п ь ю ­ терной криптографии положение м о ж н о объяснить, его н и к а к нельзя признать нормальным.) Если придерживаться объектно-ориентированного подхода (см., н а ­ пример, курс [3], а также книгу [6]), то целесообразно выделить по к р а й ­ ней мере два уровня в иерархии наследования требований к сервисам бе¬ зопасности: • общие требования, п р и м е н и м ы е ко всем или многим сервисам; • частные требования, с п е ц и ф и ч н ы е для конкретного сервиса. С точки зрения технологии программирования, «Общие критерии» построены по дообъектной, «библиотечной» методологии. О н и предо¬ ставляют параметризованные ф у н к ц и о н а л ь н ы е требования, но не содер­ жат необходимые для практического п р и м е н е н и я к о м б и н а ц и и таких требований или универсальные и н т е р ф е й с ы , допускающие конкретиза¬ ц и ю в контексте различных сервисов. Тем не менее, м ы попытаемся в ы ­ делить из разных п р о ф и л е й о б щ и е требования к сервисам безопасности, поскольку это упростит охват и п о н и м а н и е всей системы имеющихся п р о ф и л е й защиты. П р и изложении общих и частных требований к сервисам безопасно¬ сти, их к о м б и н а ц и я м и п р и л о ж е н и я м м ы будем следовать стандартной структуре профилей защиты (см. в ы ш е описание класса требований дове¬ р и я A P E ) , обращая особое в н и м а н и е на интересующие нас аспекты: • предположения безопасности; • угрозы безопасности; • политика безопасности; • цели безопасности для объекта оценки; • цели безопасности для среды; • ф у н к ц и о н а л ь н ы е требования безопасности; • требования доверия безопасности.

70

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

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

71

Курс

Информационная безопасность: основные стандарты и спецификации

Общие угрозы безопасности Современные сервисы безопасности функционируют в распределен¬ ной среде, поэтому необходимо учитывать наличие как локальных, так и сетевых угроз. В качестве общих можно выделить следующие угрозы: • обход злоумышленником защитных средств; • осуществление злоумышленником физического доступа к вычисли¬ тельной установке, на которой функционирует сервис безопасности; • о ш и б к и администрирования, в частности, неправильная установка, о ш и б к и при конфигурировании и т.п.; • переход сервиса в небезопасное состояние в результате сбоя или от¬ каза, при начальной загрузке, в процессе или после перезагрузки: • маскарад пользователя (попытка злоумышленника выдать себя за уполномоченного пользователя, например, за администратора; в распределенной среде возможны подмена исходного адреса или вос¬ произведение ранее перехваченных данных идентификации/аутен¬ тификации); • маскарад сервера (попытка злоумышленника выдать свою систему за легальный сервер; следствием подобных действий может стать на¬ вязывание пользователю ложной и н ф о р м а ц и и или получение от не¬ го к о н ф и д е н ц и а л ь н ы х сведений); • использование злоумышленником чужого сетевого соединения или интерактивного сеанса (например, путем доступа к оставленному без присмотра терминалу); • н е с а н к ц и о н и р о в а н н о е и з м е н е н и е з л о у м ы ш л е н н и к о м конфигура¬ ции сервиса и / и л и конфигурационных данных; • нарушение целостности программной конфигурации сервиса, в ча¬ стности, внедрение троянских компонентов или получение к о н т р о ­ ля над сервисом; • н е с а н к ц и о н и р о в а н н ы й доступ к к о н ф и д е н ц и а л ь н о й (например, ре¬ гистрационной) и н ф о р м а ц и и , в том числе н е с а н к ц и о н и р о в а н н о е р а с ш и ф р о в а н и е закодированных данных; • н е с а н к ц и о н и р о в а н н о е изменение данных (например, регистраци¬ онных), включая такие, целостность которых з а щ и щ е н а криптогра¬ ф и ч е с к и м и методами; • н е с а н к ц и о н и р о в а н н ы й доступ к д а н н ы м (на чтение и / и л и измене¬ ние) в процессе их передачи по сети; • анализ потоков данных с целью получения к о н ф и д е н ц и а л ь н о й ин¬ формации; • перенаправление потоков данных (в частности, на системы, контро¬ лируемые злоумышленником); • блокирование потоков данных; 72

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

• повреждение или утрата регистрационной, к о н ф и г у р а ц и о н н о й или и н о й и н ф о р м а ц и и , влияющей на безопасность ф у н к ц и о н и р о в а н и я сервиса (например, из-за повреждения носителей или переполнения регистрационного журнала); • агрессивное потребление злоумышленником ресурсов, в частности, ресурсов протоколирования и аудита, а также полосы пропускания; • сохранение остаточной и н ф о р м а ц и и в многократно используемых объектах.

Общие элементы политики и цели безопасности Сформулируем о б щ и е положения политики безопасности организа­ ц и и , относящиеся к защитным сервисам: • идентификация и аутентификация всех субъектов доступа; • управление доступом к и н ф о р м а ц и о н н ы м ресурсам сервиса безо¬ пасности; • подотчетность пользователей сервиса безопасности; • протоколирование и аудит функционирования сервиса безопасности; • обеспечение доступности к о м м у н и к а ц и о н н ы х каналов; • обеспечение конфиденциальности и целостности управляющей ин¬ ф о р м а ц и и (в частности, при удаленном администрировании); • обеспечение целостности аппаратно-программной и информацион¬ ной частей сервиса безопасности; • обеспечение невозможности обхода защитных средств. Переходя к изложению целей безопасности для объекта о ц е н к и , от­ метим, что их достижение должно способствовать противостоянию угро¬ зам безопасности и реализации предписаний политики безопасности. Для различных сервисов безопасности о б щ и м и являются нижеперечис¬ л е н н ы е цели: • подотчетность субъектов и объектов, взаимодействующих с серви¬ сом (необходимое условие достижения этой цели — идентификация и аутентификация взаимодействующих субъектов и объектов, а так­ ж е протоколирование и аудит выполняемых действий); • автоматизация административных действий, наличие средств про¬ верки корректности конфигурации, к а к локальной, так и распреде¬ л е н н о й , наглядный интерфейс администрирования; • обеспечение (прежде всего средствами пользовательского интер¬ фейса) корректного использования ф у н к ц и й безопасности; • предоставление пользователям средств для проверки аутентичности серверов и других партнеров по о б щ е н и ю , а также открытых крипто¬ графических ключей; реальное осуществление подобных проверок; 73

Курс

Информационная безопасность: основные стандарты и спецификации

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

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

Общие функциональные требования Для различных сервисов безопасности о б щ и м и являются ф у н к ц и о ­ нальные требования, связанные с идентификацией и аутентификацией, управлением доступом, протоколированием и аудитом, а также обеспече¬ н и е м высокой доступности. Далее эти требования разбиты в соответствии с иерархией, п р и н я т о й в «Общих критериях». Для сервисов безопасности предусмотрены общие требования по протоколированию и аудиту (класс F A U ) : • автоматическая реакция аудита безопасности ( F A U ARP.1.1), в к л ю ­ чая генерацию записи в регистрационном журнале, а также локаль­ ную или удаленную сигнализацию об обнаружении вероятного на­ рушения безопасности, адресованную администратору; • генерация данных аудита безопасности ( F A U G E N . 1 ) . Обязательно¬ му протоколированию подлежат запуск и завершение регистрацион¬ ных ф у н к ц и й , а также все события для базового уровня аудита. В каждой регистрационной записи д о л ж н ы присутствовать дата и вре¬ мя события, тип события, идентификатор субъекта и результат (ус­ пех или неудача) события; • анализ аудита безопасности ( F A U SAA.1.2). С целью выявления ве­ роятных нарушений д о л ж н ы производиться по крайней мере н а к о п ­ ление и / и л и объединение неуспешных результатов использования механизмов аутентификации, а также неуспешных результатов вы¬ полнения криптографических операций; • просмотр аудита безопасности ( F A U S A R ) . Администратору предо­ ставляется возможность читать всю регистрационную и н ф о р м а ц и ю . П р о ч и м пользователям доступ к ней закрыт, за исключением я в н о с п е ц и ф и ц и р о в а н н ы х случаев; • выбор событий аудита безопасности ( F A U S E L . 1 ) . Избирательность регистрации событий должна основываться хотя бы на м и н и м а л ь н о необходимом наборе атрибутов, состоящем из идентификатора объ­ екта, идентификатора субъекта, адреса узла сети, типа события, да­ ты и времени события; • хранение данных аудита безопасности ( F A U S T G . 1 . 2 ) . Регистраци¬ онную и н ф о р м а ц и ю следует защитить от н е с а н к ц и о н и р о в а н н о й мо¬ дификации. М н о г и е сервисы безопасности прямо или косвенно нуждаются в криптографической поддержке, поэтому соответствующие требования класса F C S целесообразно трактовать как общие: • управление криптографическими ключами ( F C S C K M ) . Д о л ж н ы поддерживаться генерация криптографических ключей ( F C S _ C K M . 1), распределение криптографических ключей ( F C S C K M . 2 ) , управление 75

Курс

Информационная безопасность: основные стандарты и спецификации

доступом к криптографическим ключам ( F C S C K M . 3 ) , уничтожение криптографических ключей ( F C S C K M . 4 ) ; • криптографические операции ( F C S C O P . 1 ) . Всю и н ф о р м а ц и ю , пе¬ редаваемую по доверенному каналу, необходимо шифровать и кон¬ тролировать ее целостность согласно требованиям стандартов и дру¬ гих нормативных документов. Любой сервис безопасности содержит д а н н ы е пользователей (напри­ мер, и н ф о р м а ц и ю для идентификации и аутентификации), поэтому об­ щ и м и являются и требования класса F D P (защита данных пользователя): • политика управления доступом ( F D P ACC.1.1). Д о л ж н о осуществ­ ляться разграничение доступа для пользователей, прямо или косвен­ но в ы п о л н я ю щ и х операции с сервисом безопасности; • ф у н к ц и и управления доступом ( F D P ACF.1.1). П р и м е н е н и е ф у н к ­ ций разграничения доступа основывается на следующих атрибутах безопасности: идентификаторы субъектов доступа, идентификаторы объектов доступа, адреса субъектов доступа, адреса объектов досту¬ па, права доступа субъектов; • базовая защита внутренней передачи ( F D P ITT.1). Следует осуще­ ствлять заданную политику управления доступом и / и л и информа¬ ц и о н н ы м и потоками, чтобы предотвратить раскрытие, модифика¬ цию и / и л и недоступность данных пользователя при их передаче между ф и з и ч е с к и р а з д е л е н н ы м и частями сервиса безопасности (FDP_ITT.1.1); • защита остаточной и н ф о р м а ц и и ( F D P RIP.2.1). Для всех объектов должна обеспечиваться полная защита остаточной и н ф о р м а ц и и , то есть недоступность предыдущего состояния при освобождении ре¬ сурса. Необходимость и д е н т и ф и к а ц и и и аутентификации пользователей сервисов безопасности (класс FIA) стала следствием общего требования подотчетности: • отказы аутентификации ( F I A A F L . 1 . 2 ) . П р и достижении определен¬ ного администратором числа неуспешных п о п ы т о к аутентификации необходимо отказать субъекту в доступе, сгенерировать запись реги¬ страционного журнала и сигнализировать администратору о вероят¬ ном нарушении безопасности; • определение атрибутов пользователя ( F I A ATD.1.1). Для каждого пользователя поддерживаются идентификатор, пароль и права д о ­ ступа (роль). К р о м е того, если используются криптографические операции, требуется поддержка открытых и секретных ключей; • идентификация ( F I A U I D ) и аутентификация ( F I A U A U ) пользова­ теля. Каждый пользователь должен быть успешно идентифицирован ( F I A U I D . 2 . 1 ) и аутентифицирован ( F I A U A U . 2 . 1 ) до разрешения 76

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

любого действия, выполняемого сервисом безопасности от его име¬ ни. Необходимо предотвращать применение аутентификационных данных, которые были подделаны или скопированы у другого поль¬ зователя ( F I A U A U . 3 ) . Следует аутентифицировать любой представ­ л е н н ы й идентификатор пользователя ( F I A UAU.5.2) и повторно ау­ тентифицировать пользователя по истечении определенного адми­ нистратором интервала времени ( F I A U A U . 6 . 1 ) . Ф у н к ц и и безопас­ ности должны предоставлять пользователю только скрытую обрат­ ную связь во время выполнения аутентификации ( F I A U A U . 7 ) ; • связывание пользователь-субъект ( F I A U S B . 1 . 1 ) . Соответствующие атрибуты безопасности пользователя нужно ассоциировать с субъек­ тами, действующими от и м е н и этого пользователя. Управление — в а ж н е й ш и й аспект и н ф о р м а ц и о н н о й безопасности, а требования управления (класс F M T ) , несомненно, принадлежат к числу общих: • управление отдельными ф у н к ц и я м и безопасности ( F M T M O F . 1 . 1 ) . Только администратору позволяется определять режим ф у н к ц и о н и ­ рования, отключения, подключения, модифицировать режимы и д е н т и ф и к а ц и и и аутентификации, управлять правами доступа, протоколирования и аудита; • управление атрибутами безопасности ( F M T _ M S A ) . Только админи¬ стратору предоставляется право изменения подразумеваемых значе­ н и й , а также опроса, и з м е н е н и я , удаления, создания атрибутов безо­ пасности и правил управления потоками информации ( F M T M S A . 1 . 1 ) . Следует обеспечить присваивание атрибутам безо¬ пасности исключительно безопасных значений ( F M T _ M S A . 2 . 1 ) ; • управление д а н н ы м и ф у н к ц и й безопасности ( F M T _ M T D ) . Только администратор должен иметь возможность и з м е н е н и я подразумева­ емых значений, опроса, изменения, удаления, очистки, определения типов регистрируемых событий, размеров регистрационных журна¬ лов, прав доступа субъектов, сроков действия учетных записей субъ¬ ектов доступа, паролей, криптографических ключей ( F M T MTD.1.1). Только он определяет ограничения размеров реги­ страционных журналов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей, числа неудачных по¬ п ы т о к а у т е н т и ф и к а ц и и , и н т е р в а л о в бездействия пользователей ( F M T _ M T D . 2 . 1 ) . П р и выходе за допустимые границы должны вы¬ полняться установленные действия: передача уведомления админи¬ стратору, блокирование или удаление учетной записи, запрос на сме¬ ну пароля или ключа и т.д. ( F M T M T D . 2 . 2 ) . Следует обеспечить присваивание данным функциям лишь безопасных значений (FMT_MTD.3.1); 77

Курс

Информационная безопасность: основные стандарты и спецификации

• отмена ( F M T REV.1). Только уполномоченным администраторам разрешено выполнять отмену атрибутов безопасности, ассоцииро­ ванных с пользователями. Важные для безопасности полномочия должны отменяться немедленно ( F M T R E V . 1 . 2 ) ; • роли управления безопасностью ( F M T S M R ) . Поддерживаются сле¬ дующие роли: уполномоченный пользователь, удаленный пользова¬ тель, администратор ( F M T S M R . 1 . 1 ) . Получение ролей удаленного пользователя и администратора может производиться только по яв¬ ному запросу ( F M T _ S M R . 3 . 1 ) . Приватность (класс F P R ) — специфический аспект информацион¬ ной безопасности, однако требование открытости для уполномоченного пользователя носит о б щ и й характер: • скрытность ( F P R _ U N O ) . Администратору необходимо иметь воз¬ можность наблюдать за использованием ресурсов сервиса безопас¬ ности ( F P R _ U N O . 4 . 1 ) . Собственная защищенность (класс FPT) — важная характеристика л ю ­ бого сервиса безопасности. В число общих входят следующие требования: • тестирование абстрактной м а ш и н ы ( F P T AMT.1). Для демонстра­ ции в ы п о л н е н и я предположений безопасности, обеспечиваемых аб¬ страктной м а ш и н о й , положенной в основу сервиса безопасности, при запуске и / и л и по запросу администратора выполняется пакет тестовых программ (FPT_AMT.1.1); • безопасность при сбое ( F P T F L S ) . Сервис должен сохранять безо­ пасное состояние при аппаратных сбоях (вызванных, например, п е ­ ребоями электропитания) ( F P T F L S . 1 . 1 ) ; • целостность экспортируемых данных (FPT_ITI). Сервис предостав¬ ляет возможность верифицировать целостность всех данных в мо¬ мент их передачи между н и м и удаленным доверенным изделием ИТ, выполняет повторную передачу и н ф о р м а ц и и , а также генерирует за¬ пись регистрационного журнала, если м о д и ф и к а ц и и обнаружены (FPT_ITI.1.2); • надежное восстановление ( F P T _ R C V ) . Когда автоматическое восста¬ новление после сбоя или прерывания обслуживания невозможно, следует обеспечить переход сервиса в режим аварийной поддержки, позволяющий вернуться к безопасному состоянию ( F P T R C V . 2 . 1 ) . После аппаратных сбоев требуется возврат к безопасному состоянию с использованием автоматических процедур ( F P T R C V . 2 . 2 ) ; • обнаружение повторного использования ( F P T R P L ) . Сервис дол¬ ж е н обнаруживать повторное использование аутентификационных данных ( F P T R P L . 1 . 1 ) , отказывать в доступе, генерировать запись регистрационного журнала и сигнализировать администратору о ве¬ роятном нарушении безопасности ( F P T R P L . 1 . 2 ) ; 78

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

• посредничество при обращениях ( F P T R V M ) . Ф у н к ц и и , осуществ­ л я ю щ и е политику безопасности сервиса, вызываются и успешно в ы ­ полняются прежде, чем разрешается в ы п о л н е н и е любой другой ф у н к ц и и сервиса ( F P T R V M . 1 . 1 ) . К о м п о н е н т F P T R V M . 1 направ¬ лен на обеспечение невозможности обхода защитных средств; • разделение доменов ( F P T SEP). Ф у н к ц и и безопасности д о л ж н ы поддерживать отдельный домен для собственного в ы п о л н е н и я , к о ­ торый защищает их от вмешательства и искажения недоверенными субъектами ( F P T S E P . 1 . 1 ) ; • метки времени ( F P T S T M ) . Ф у н к ц и я м безопасности нужно предо­ ставлять надежные метки времени ( F P T S T M . 1 . 1 ) ; • согласованность данных между функциями безопасности ( F P T T D C ) . Необходима согласованная интерпретация регистраци¬ о н н о й и н ф о р м а ц и и , а также параметров используемых криптогра¬ фических операций ( F P T T D C . 1 . 1 ) ; • согласованность перечисленных ф у н к ц и й безопасности при дубли¬ ровании в пределах объекта о ц е н к и ( F P T T R C ) . Должна обеспечи­ ваться согласованность ф у н к ц и й безопасности при дублировании их в различных частях объекта о ц е н к и ( F P T T R C . 1 . 1 ) . Когда части, с о ­ держащие дублируемые д а н н ы е , разъединены, она выполняется п о ­ сле восстановления соединения перед обработкой любых запросов к заданным ф у н к ц и я м безопасности ( F P T T R C . 1 . 2 ) ; • самотестирование ф у н к ц и й безопасности ( F P T T S T ) . Для демонст¬ рации правильности работы ф у н к ц и й безопасности в процессе нор¬ мального ф у н к ц и о н и р о в а н и я и / и л и по запросу администратора при запуске периодически должен выполняться пакет программ самоте­ стирования ( F P T T S T . 1 . 1 ) , а администратор верифицирует целост­ ность данных ( F P T T S T . 1 . 2 ) и выполняемого кода ф у н к ц и й безопас­ ности ( F P T T S T . 1 . 3 ) . Требования класса F T A (доступ к объекту оценки) направлены на обеспечение з а щ и щ е н н о с т и от агрессивного потребления ресурсов: • ограничение на параллельные сеансы ( F T A M C S ) . Ограничение максимального числа параллельных сеансов, предоставляемых од­ ному пользователю ( F T A M C S . 1 . 1 ) . У этой величины должно быть п о д р а з у м е в а е м о е з н а ч е н и е , устанавливаемое а д м и н и с т р а т о р о м (FTAMCS.1.2); • блокирование сеанса ( F T A S S L ) . П о истечении установленного ад­ министратором значения длительности бездействия пользователя сеанс работы принудительно завершается ( F T A SSL.3.1); • открытие сеанса с объектом оценки ( F T A T S E ) . Сервис должен быть способен отказать в открытии сеанса, основываясь на идентификато­ ре субъекта, пароле субъекта, правах доступа субъекта ( F T A T S E . 1 . 1 ) . 79

Курс

Информационная безопасность: основные стандарты и спецификации

Обеспечение защищенного взаимодействия сервисов безопасности в распределенной среде (класс F T P (доверенный маршрут/канал)) — одно из важнейших общих требований: • д о в е р е н н ы й к а н а л передачи между ф у н к ц и я м и б е з о п а с н о с т и ( F T P ITC). Для связи с удаленным доверенным изделием И Т ф у н к ­ ции безопасности д о л ж н ы предоставлять канал, который логически отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту д а н н ы х от м о д и ф и к а ц и и и р а с к р ы т и я ( F T P ITC.1.1). Обеим сторонам необходимо иметь возможность и н и ц и и р о в а н и я связи ч е р е з д о в е р е н н ы й к а н а л ( F T P ITC.1.2, FTPITC.1.3); • доверенный маршрут ( F T P T R P ) . Для связи с удаленным пользова­ телем функции безопасности предоставляют маршрут, который логи¬ чески отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту данных от м о д и ф и к а ц и и и раскрытия ( F T P TRP.1.1). Пользователю позволяется инициировать связь через доверенный маршрут ( F T P TRP.1.2). Для начальной аутентифика­ ции удаленного пользователя и удаленного управления использова­ ние доверенного маршрута является обязательным ( F T P TRP.1.3).

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

Лекция 5

Профили защиты. Часть 1. Общие требования к сервисам безопасности

• • • •

анализ подмножества реализации; п р и м е н е н и е неформальной модели политики безопасности; независимый анализ уязвимостей; автоматизация управления конфигурацией. Вероятно, это самый высокий уровень, который м о ж н о достичь при существующей технологии программирования и разумных затратах мате¬ риальных и временных ресурсов. М ы завершаем изложение общих требований к сервисам безопасно­ сти. Н а наш взгляд, знакомство с н и м и необходимо для усвоения и после­ дующего практического использования «Общих критериев».

81

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 6. П р о ф и л и з а щ и т ы , р а з р а б о т а н н ы е на о с н о в е «Общих к р и т е р и е в » . Часть 2 . Ч а с т н ы е т р е б о в а н и я к сервисам безопасности Описываются предположения и цели безопасности, функциональные требования и требования доверия, специфичные для конкретных сервисов безопасности. Основное внимание уделено функциональным требованиям, как наиболее важным для обеспечения безопасности.

Ключевые слова: б и о м е т р и я , и д е н т и ф и к а ц и я , а у т е н т и ф и к а ц и я , о ш и б к а первого рода, о ш и б к а второго рода, м и м и к р и я , артефакт, п р о и з в о л ь н о е управление доступом, д и с к р е ц и о н н о е управление доступом, атрибут пользователя, статический атрибут, и д е н т и ф и ­ катор пользователя, в е р и ф и к а ц и я секретов, принудительное у п ­ равление доступом, мандатное управление доступом, экспорт д а н ­ ных пользователя, и м п о р т д а н н ы х пользователя, иерархические ат¬ рибуты безопасности, метка безопасности, уровень, набор катего¬ р и й , роли безопасности, н е ф о р м а л ь н а я модель п о л и т и к и безопас­ ности, ролевое управление доступом, разделение обязанностей, и е ­ рархия ролей, база д а н н ы х ролей, межсетевой э к р а н , пакетная фильтрация, к о м п л е к с н о е э к р а н и р о в а н и е , сервер-посредник, од¬ норазовые пароли, а н о н и м н о с т ь , псевдонимность, невозможность а с с о ц и а ц и и , т р а н с л я ц и я адресов, а к т и в н ы й аудит, подозрительная активность, автоматическое реагирование, масштабируемость, ме¬ неджер, агент, сенсор, сигнатура атаки, пороговый анализ, статис¬ тический а н а л и з , сигнатурный анализ, соответствие п о л и т и к е бе¬ зопасности, решатель, м о н и т о р , к о р р е л я ц и о н н ы й а н а л и з , п р о ­ г р а м м н о е обеспечение промежуточного слоя, безопасность и н т е р ­ ф е й с о в , к л а с с и ф и к а ц и о н н а я схема, ф у н к ц и о н а л ь н ы й пакет, а н о н и м и з а т о р , приватность, многоаспектная и н ф о р м а ц и о н н а я безо­ пасность, распределение д о в е р и я , с е р т и ф и к а т ы открытых к л ю ч е й , выпуск с е р т и ф и к а т о в , а н н у л и р о в а н и е с е р т и ф и к а т о в , управление с е р т и ф и к а т а м и , центр выпуска и а н н у л и р о в а н и я с е р т и ф и к а т о в , к р и п т о г р а ф и ч е с к и й модуль, анализ з а щ и щ е н н о с т и , уязвимость, автообнаружение, и м и т а ц и я атаки.

82

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

Биометрическая идентификация и аутентификация Системы биометрической идентификации и аутентификации, об­ щ и е сведения о которых м о ж н о найти в курсе [3] «Основы и н ф о р м а ц и о н ­ н о й безопасности», весьма актуальны и интересны с точки зрения о ц е н ­ ки их безопасности. В д а н н о м разделе рассматривается профиль защиты [36], разработанный специалистами Министерства обороны С Ш А для о ц е н к и коммерческих продуктов, применяемых в среде со средними тре­ бованиями к безопасности. Наиболее интересная (и самая большая по объему) часть в этом п р о ­ ф и л е — описание угроз, которым подвержены системы биометрической и д е н т и ф и к а ц и и и аутентификации, что наводит на определенные размы¬ шления. Первой упомянута угроза случайного прохождения злоумышленни¬ ком чисто биометрической процедуры и д е н т и ф и к а ц и и и аутентифика¬ ц и и . Если база биометрических шаблонов велика, то уже этот метод ата¬ к и , не требующий ничего, кроме нахальства, может принести успех. Во¬ обще говоря, биометрические системы подвержены о ш и б к а м первого (успешная и д е н т и ф и к а ц и я и аутентификация лица, не являющегося уполномоченным пользователем) и второго (неправомерный отказ в до¬ ступе уполномоченному пользователю) рода. Величины допустимых рас¬ хождений эталонного и представленного биометрических шаблонов вхо¬ дят в число параметров безопасности. Н е к в а л и ф и ц и р о в а н н ы й админист­ ратор, желая уменьшить число отказов уполномоченным пользователям, способен чрезмерно повысить вероятность о ш и б к и первого рода. Вторая угроза — м и м и к р и я под атакуемого субъекта (подражание его голосу, попытки воспроизвести подпись и т.п.). Биометрические д а н н ы е трудно скрыть, поэтому лучше изначально предполагать, что они общеиз¬ вестны, и строить защиту, исходя из этого предположения. Для компрометации биометрических систем могут применяться и с ­ кусственные средства идентификации (например, желатиновые муляжи глаз). В контролируемой среде подобным артефактом воспользоваться трудно, однако контроль возможен не всегда. В биометрической базе данных некоторые элементы могут быть «слабее» остальных, т. е. их легче атаковать. Нередко п р и ч и н а заключает¬ ся в н и з к о м качестве биометрического шаблона в сочетании с высокой вероятностью о ш и б к и первого рода. Н а п р и м е р , м о ж н о использовать как эталонные несколько образцов подписи, имеющих существенные разли¬ ч и я . Другой пример — с л и ш к о м тихая, с паузами речь при з а п о м и н а н и и голоса пользователя. «Зашумление» биометрических шаблонов — косвен­ ная угроза, способствующая появлению слабых элементов. Для защиты рекомендуется выявление и удаление (замена) подобных шаблонов. 83

Курс

Информационная безопасность: основные стандарты и спецификации

З л о у м ы ш л е н н и к с п о м о щ ь ю технических средств способен зашумлять каналы связи между частями биометрической системы, чтобы заста­ вить администратора увеличить вероятность о ш и б о к первого рода. «Атака на близнеца» — угроза, реализуемая в том случае, если в био­ метрической базе оказываются д а н н ы е о людях с похожими характерис­ тиками (это могут быть и настоящие близнецы, один из которых — зло¬ умышленник). Возможно использование «остаточных» биометрических данных от предыдущего пользователя, а также воспроизведение подобных данных. Н е к в а л и ф и ц и р о в а н н ы е действия штатного администратора и зло­ у м ы ш л е н н ы е — уполномоченного пользователя, не являющегося адми¬ нистратором, могут привести к и з м е н е н и ю значений разного рода пара¬ метров безопасности и ослаблению защиты, в частности, и з м е н е н и ю или порче базы биометрических данных. Возможные недостатки в протоколировании и аудите биометричес¬ кой системы повышают ее уязвимость, поскольку некоторые атаки д л и ­ тельное время остаются незамеченными. Выделим ряд специфических функциональных требований: • мониторинг целостности данных функций безопасности ( F P T ITT.3). Требуется обнаружение м о д и ф и к а ц и и данных, переда­ ваемых между разделенными частями объекта оценки; при обнару¬ ж е н и и о ш и б к и целостности следует уведомить администратора и за¬ протоколировать это событие; • противодействие физическому нападению ( F P T PHP.3). Ф у н к ц и и безопасности должны противодействовать нарушению физической целостности объекта о ц е н к и , а также п р и м е н е н и ю электромагнит¬ ных и иных зашумляющих устройств. Для мер доверия выбран четвертый о ц е н о ч н ы й уровень, что м о ж н о считать стандартным (общим) решением.

Требования к произвольному (дискреционному) управлению доступом Дальнейшее изложение основано на первой редакции проекта [7] Руководящего документа Гостехкомиссии России «Безопасность и н ф о р ­ м а ц и о н н ы х технологий. Контролируемый доступ. П р о ф и л ь защиты» ( П З К Д ) , подготовленной в Центре безопасности и н ф о р м а ц и и . Его прототип [44], базирующийся на версии 2.0 «Общих критериев», был разработан в 1999 году в Агентстве национальной безопасности С Ш А . В п р и н ц и п е , П З К Д соответствует классу безопасности C2 « О р а н ­ ж е в о й книги» [47] или пятому классу з а щ и щ е н н о с т и по к л а с с и ф и к а ц и и Гостехкомиссии Р о с с и и для средств вычислительной техники [23], од84

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

н а к о п р и м е н е н и е методологии и о б ш и р н о г о набора требования безо¬ пасности из «Общих критериев» позволило сделать п р о ф и л ь , по сравне¬ н и ю с у п о м я н у т ы м и д о к у м е н т а м и , существенно более детальным и обоснованным. И з соответствия классу безопасности C2 следует, что в П З К Д рассма­ тривается только дискреционное (произвольное) управление доступом. Требования, включенные в профиль, направлены на достижение базового уровня безопасности в условиях невраждебного и хорошо управляемого сообщества пользователей при наличии л и ш ь непреднамеренных угроз. И з числа частных функциональных требований П З К Д выделим на¬ иболее важные: • ассоциация идентификатора пользователя ( F A U G E N . 2 ) . Ф у н к ц и и безопасности д о л ж н ы ассоциировать каждое потенциально прото¬ колируемое событие с идентификатором пользователя — и н и ц и а т о ­ ра этого события (на первый взгляд кажется, что из данного требова­ н и я есть очевидные исключения, например, неудачные попытки и д е н т и ф и к а ц и и / а у т е н т и ф и к а ц и и , однако на этой стадии средства контролируемого доступа еще не используются, а за и д е н т и ф и к а ц и ю и аутентификацию отвечает другой сервис безопасности); • выборочный просмотр аудита ( F A U S A R . 3 ) . Необходимо предоста­ вить возможность поиска, сортировки, упорядочения регистрацион­ ных данных, основываясь на идентификаторах пользователей и, быть может, других с п е ц и ф и ц и р о в а н н ы х атрибутах; • у п р а в л е н и е д о с т у п о м , о с н о в а н н о е на атрибутах б е з о п а с н о с т и ( F D P A C F . 1 ) . Проводимая политика дискреционного управления д о с т у п о м д о л ж н а о с н о в ы в а т ь с я на таких атрибутах, к а к и д е н т и ­ ф и к а т о р пользователя и п р и н а д л е ж н о с т ь к группе (группам), а т а к ж е атрибутах, а с с о ц и и р о в а н н ы х с о б ъ е к т а м и . П о с л е д н и е дают в о з м о ж н о с т ь с о п о с т а в л е н и я р а з р е ш е н н ы х и з а п р е щ е н н ы х опера¬ ц и й с и д е н т и ф и к а т о р а м и одного и л и более пользователей и / и л и групп, з а д а н и я р а з р е ш е н н ы х и л и з а п р е щ е н н ы х по у м о л ч а н и ю операций; • определение атрибутов пользователя ( F I A A T D . 1 ) . Для каждого пользователя должен поддерживаться следующий список атрибутов безопасности: и д е н т и ф и к а т о р пользователя, п р и н а д л е ж н о с т ь к группе, д а н н ы е аутентификации, допустимые роли; • в е р и ф и к а ц и я секретов ( F I A SOS.1). П р и однократной попытке и с ­ пользования механизма аутентификации или при неоднократных попытках в течение одной минуты вероятность случайного доступа должна быть м е н ь ш е 1:1000000. Любая обратная связь при попытках использования механизма аутентификации не должна приводить к п р е в ы ш е н и ю указанного уровня вероятности; 85

Курс

Информационная безопасность: основные стандарты и спецификации

• связывание пользователь-субъект ( F I A U S B . 1 ) . Ф у н к ц и и безопас¬ ности д о л ж н ы ассоциировать следующие атрибуты безопасности пользователя с субъектами, действующими от и м е н и этого пользова­ теля: идентификатор пользователя, который ассоциируется с собы­ тиями аудита; идентификаторы пользователя, п р и м е н я е м ы е для осу­ ществления политики дискреционного управления доступом; п р и ­ надлежность к группам, используемая для осуществления политики дискреционного управления доступом; • и н и ц и а л и з а ц и я статических атрибутов ( F M T M S A . 3 ) . Д о л ж н ы обеспечиваться ограничительные подразумеваемые значения для ат­ рибутов безопасности, при п о м о щ и которых осуществляется п о л и ­ тика дискреционного управления доступом ( F M T MSA.3.1). Д о л ж ­ на предоставляться возможность определения альтернативных н а ­ чальных значений для отмены подразумеваемых значений при с о ­ здании объектов ( F M T M S A . 3 . 2 ) ; • отмена ( F M T R E V . 1 ) . Право отмены атрибутов безопасности, ассо­ циированных с объектами, необходимо предоставлять только поль­ зователям, уполномоченным на это политикой дискреционного уп­ равления доступом ( F M T R E V . 1 . 1 ) . Рассмотренный проект п р о ф и л я показывает, что выделение общих требований к сервисам безопасности значительно сокращает специфиче¬ скую часть, облегчает ее изучение и верификацию.

Требования к принудительному (мандатному) управлению доступом В д а н н о м разделе рассматривается первая редакция проекта [8] Ру­ ководящего документа Гостехкомиссии России «Безопасность и н ф о р м а ­ ц и о н н ы х технологий. Меточная защита. П р о ф и л ь защиты» ( П З М З ) , подготовленная в Центре безопасности и н ф о р м а ц и и (см. также [71]). П З М З соответствует классу безопасности B1 «Оранжевой книги» [47] или четвертому классу защищенности по к л а с с и ф и к а ц и и Гостехкомиссии России для средств вычислительной техники [23]. П р о ф и л ь защиты для мандатного (принудительного) управления до¬ ступом имеет много общего с рассмотренным в предыдущем разделе про¬ филем П З КД. Некоторые отличия носят очевидный характер; например, включение меток безопасности в записи регистрационного журнала (се¬ мейство функциональных требований F A U G E N ) , выборочный п р о ­ смотр аудита на основании меток безопасности ( F A U S A R ) или включе­ н и е данных о допуске ( F I A A T D ) в число атрибутов безопасности поль­ зователя. Н и на общих свойствах этих двух п р о ф и л е й , н и на рутинных от­ личиях м ы останавливаться не будем. 86

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

Перечислим с п е ц и ф и ч н ы е для П З М З ф у н к ц и о н а л ь н ы е требования: • экспорт данных пользователя ( F D P E T C ) . П р и экспорте назначен­ ных данных пользователя должна осуществляться политика мандат­ ного управления доступом ( F D P ETC.1.1, F D P E T C . 2 . 1 ) . Н е п о м е ­ ч е н н ы е д а н н ы е э к с п о р т и р у ю т с я без атрибутов б е з о п а с н о с т и ( F D P E T C . 1 . 2 ) , помеченные — с однозначно ассоциированными ат­ рибутами ( F D P E T C . 2 . 2 , F D P E T C . 2 . 3 ) . Устройства, используемые для экспорта данных без атрибутов безопасности, не могут употреб­ ляться для экспорта с атрибутами за исключением ситуации, когда изменение в состоянии устройства выполнено вручную и может быть запротоколировано ( F D P E T C . 2 . 4 ) . Отметим, что в О К в к о м ­ поненте F D P ETC.1 отсутствует элемент, необходимый для назна­ чения правил управления экспортом непомеченных данных; • ограниченное управление информационными потоками ( F D P IFC.1). Для назначенных субъектов и объектов и всех опера­ ц и й над этими субъектами и объектами осуществляется политика мандатного управления доступом ( F D P IFC.1.1); • иерархические атрибуты безопасности ( F D P I F F . 2 ) . Политика м а н ­ датного управления доступом должна основываться на метках безо­ пасности субъектов и объектов ( F D P I F F . 2 . 1 ) . Метка безопасности составляется из иерархического уровня и набора неиерархических категорий. На множестве допустимых меток безопасности должно быть определено отношение частичного порядка с указанными да­ лее свойствами ( F D P IFF.2.7). Метки равны, если совпадают их уровни и наборы категорий. Метка A больше метки B , если уровень A больше уровня B и набор категорий B является подмножеством на­ бора A ; если уровень A равен уровню B и набор категорий B являет­ ся собственным подмножеством набора A . Метки несравнимы, если они не равны и н и одна из меток не больше другой. Для любых двух допустимых меток существует н а и м е н ь ш а я верхняя грань, которая больше или равна этим меткам, а также наибольшая н и ж н я я грань, которая не больше обеих меток. Д о л ж н о поддерживаться по крайней мере 16 уровней и 64 категории. И н ф о р м а ц и о н н ы й поток между уп­ равляемыми субъектами и объектами посредством управляемой опе¬ рации разрешен, если метка источника больше или равна метке це¬ левого субъекта или объекта ( F D P I F F . 2 . 2 ) ; • импорт данных пользователя ( F D P ITC). Это семейство требований симметрично э к с п о р т н ы м требованиям F D P E T C ; • управление атрибутами безопасности ( F M T M S A . 1 ) . Ф у н к ц и и безо­ пасности д о л ж н ы осуществлять политику мандатного управления доступом, чтобы ограничить право м о д и ф и к а ц и и меток безопаснос¬ ти, ассоциированных с объектами; 87

Курс

Информационная безопасность: основные стандарты и спецификации

• роли безопасности ( F M T S M R . 1 ) . В число поддерживаемых должна входить роль, дающая право изменять атрибуты безопасности объектов. Для требований доверия безопасности рассматриваемый профиль предписывает оценочный уровень 3, усиленный компонентом A D V S P M . 1 (неформальная модель политики безопасности объекта оценки).

Ролевое у п р а в л е н и е д о с т у п о м Ролевое управление доступом (Role-Based Access Control, R B A C ) представляет собой универсальный каркас, нейтральный по о т н о ш е н и ю к конкретной д и с ц и п л и н е разграничения доступа и предназначенный в первую очередь для упрощения администрирования И С с большим чис¬ лом пользователей и различных ресурсов. Ниже рассматриваются специфические требования для профиля R B A C [83], [81], основанного на версии 2.0 «Общих критериев». Разделение обязанностей — существенная и с п е ц и ф и ч н а я для роле­ вого управления доступом цель безопасности. Возможность ее достиже­ н и я — важное достоинство ролевого доступа. Е щ е одна особая и методологически важная цель безопасности — о р ­ ганизация иерархии ролей с наследованием прав доступа. П р и м е н е н и е идей и методов объектно-ориентированного подхода необходимо для ус¬ п е ш н о й работы с большими системами. Для ролевого управления доступом характерны следующие функции: • создание и удаление ролей; создание, удаление и м о д и ф и к а ц и я ат­ рибутов ролей и о т н о ш е н и й между ролями; • формирование и поддержка ассоциаций между пользователями и ролями; • формирование и поддержка ассоциаций между правами доступа и ролями. Эти ф у н к ц и и обслуживаются тремя классами функциональных тре­ бований, на которых м ы и остановимся: • ограниченное управление доступом ( F D P A C C . 1 . 1 ) . П о крайней м е ­ ре для части операций субъектов над объектами должно действовать ролевое управление доступом, которое в общем случае может суще¬ ствовать с другими д и с ц и п л и н а м и разграничения доступа; • у п р а в л е н и е д о с т у п о м , о с н о в а н н о е на атрибутах б е з о п а с н о с т и ( F D P A C F . 1 . 1 ) . В число учитываемых атрибутов безопасности сле¬ дует включить, п о м и м о прочих, присвоенные субъекту роли и права доступа этих ролей; • управление д а н н ы м и ф у н к ц и й безопасности ( F M T M T D ) . Только администратор должен иметь возможность определения и измене­ н и я ролей, их атрибутов, связей между н и м и и ограничений на п о 88

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

добные связи ( F M T M T D . 1 . 1 ) . Необходимы и другие требования класса F M T , но они в данном случае носят п р я м о л и н е й н ы й характер и рассматриваться не будут. Требования безопасности при сбое (семейство F P T F L S ) имеют тех­ нический характер. Д о л ж н о сохраняться безопасное состояние в ситуаци­ ях, когда база данных ролей недоступна или повреждена ( F P T F L S . 1 . 1 ) . К а к и в случае управления безопасностью, другие требования этого клас­ са необходимы, но не нуждаются в детальном рассмотрении. М о ж н о видеть, что ф у н к ц и о н а л ь н ы е т р е б о в а н и я «Общих к р и т е ­ риев» п о л е з н ы для д о с т и ж е н и я тактических целей безопасности. Стра­ тегические ц е л и , н о с я щ и е к о н ц е п т у а л ь н ы й и л и архитектурный харак­ тер, — о р г а н и з а ц и я иерархии ролей с н е б о л ь ш и м ч и с л о м сущностей на к а ж д о м уровне и л и следование п р и н ц и п у р а з д е л е н и я о б я з а н н о с т е й — приходится ф о р м у л и р о в а т ь отдельно, без с т а н д а р т и з о в а н н о й понятий¬ н о й базы.

Межсетевое экранирование Для межсетевых экранов ( М Э ) разработан целый ряд профилей за­ щ и т ы и проектов подобных п р о ф и л е й (см. [49], [66], [65], [29], [30]). От¬ метим, что экранирование — это, видимо, единственный сервис безопас¬ ности, для которого Гостехкомиссия России одной из первых в мире раз­ работала и ввела в действие Руководящий документ [24], его основные идеи получили международное п р и з н а н и е и фигурируют в профилях за­ щ и т ы , и м е ю щ и х о ф и ц и а л ь н ы й статус в таких странах, как С Ш А . Межсетевые э к р а н ы классифицируются на основании уровней эта­ л о н н о й семиуровневой модели, на которых осуществляется фильтрация потоков данных. Далее рассматриваются специфические требования двух видов п р о ф и л е й , соответствующих фильтрации на уровнях вплоть до транспортного (пакетная фильтрация) и на всех уровнях, включая при¬ кладной (комплексное экранирование). И з л о ж е н и е вопросов пакетной фильтрации основывается на п р о ф и ­ ле [49], наиболее представительном среди документов аналогичного на­ значения. В общем случае рассматривается м н о г о к о м п о н е н т н ы й межсетевой экран. Политика безопасности М Э базируется на п р и н ц и п е «все, что не разрешено, запрещено». И н ф о р м а ц и я , поступающая в М Э , может предназначаться для фильтрации или для изменения параметров самого М Э . В первом случае идентификация/аутентификация не требуется, во втором она обязатель­ на, причем используются одноразовые пароли (идентифицироваться и аутентифицироваться д о л ж н ы как операторы, осуществляющие удален89

Курс

Информационная безопасность: основные стандарты и спецификации

ное администрирование, так и устройства, в частности маршрутизаторы, п о с ы л а ю щ и е и н ф о р м а ц и ю для М Э , например, и з м е н е н н ы е таблицы м а р ­ шрутизации). Для формального описания перечисленных требований применяются к о м п о н е н т ы F M T M S A . 1 (управление атрибутами безо­ п а с н о с т и ) , F M T M S A . 3 (статическая и н и ц и а л и з а ц и я атрибутов) и F I A U A U . 5 (сочетание механизмов аутентификации). Поскольку «Общие критерии» не предназначены для о ц е н к и специ¬ ф и ч е с к и х качеств к р и п т о г р а ф и ч е с к и х алгоритмов, рассматриваемый профиль ссылается на федеральный стандарт С Ш А FIPS P U B 140-1, тре­ буя согласованности с н и м для средств аутентификации, ш и ф р о в а н и я и контроля целостности. Формальной оболочкой для данного требования является компонент О К F C S COP.1. Решения по фильтрации потоков данных принимаются на основе набора правил, в которых могут фигурировать исходный и целевой сете¬ вые адреса, протокол транспортного уровня, исходный и целевой порты, а также входной и выходной сетевой интерфейс. Формально ограничен¬ ное управление и н ф о р м а ц и о н н ы м и потоками между неаутентифицируем ы м и сущностями описывается компонентом F D P I F C . 1 , а используе¬ м ы е п р и этом п р о с т ы е атрибуты б е з о п а с н о с т и — к о м п о н е н т о м F D P IFF.1. В ы б о р о ч н ы й п р о с м о т р р е г и с т р а ц и о н н о й и н ф о р м а ц и и ( F A U SAR.3.1) может основываться на адресах, диапазонах адресов, но¬ мерах портов, диапазонах дат и времени. В плане требований доверия безопасности рассматриваемый п р о ­ филь ограничивается о ц е н о ч н ы м уровнем 2. На наш взгляд, этого недо­ статочно для защиты критически важных систем, ф у н к ц и о н и р у ю щ и х в среде со средним уровнем риска. Отметим, что за пределами рассмотрения в п р о ф и л е остались такие технологические аспекты, как согласованность базы правил фильтрации для многокомпонентных конфигураций, удобство административного интерфейса (необходимое условие уменьшения числа о ш и б о к админист­ рирования), защита от атак на доступность. Переходя к вопросам комплексного э к р а н и р о в а н и я , отметим, что современные комплексные межсетевые э к р а н ы , осуществляющие фильт­ р а ц и ю на всех уровнях, включая прикладной, по сравнению с пакетными фильтрами обеспечивают более надежную защиту, что н а ш л о отражение в дополнительных требованиях безопасности, включенных в п р о ф и л и [65] и [29, 30]. В состав комплексных межсетевых экранов могут входить серверыпосредники, они требуют от пользователей соответствующих сетевых ус¬ луг (таких, например, как F T P или Telnet) и д е н т и ф и к а ц и и и аутентифи¬ кации (с п о м о щ ь ю механизмов, основанных на данных одноразового ис¬ пользования и соответствующих компоненту F I A U A U . 4 ) . 90

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

В правилах фильтрации могут фигурировать команды протоколов прикладного уровня и параметры команд. В проекте п р о ф и л я [29] предписывается организация полного уп­ равления межсетевым доступом (компонент F D P A C C . 2 ) , а также пре­ дотвращение угроз доступности ( F D P I F C . 2 . 1 ) . Важным моментом проекта [29] являются требования анонимности ( F P R A N O . 1 . 1 ) , псевдонимности ( F P R P S E . 1 ) и невозможности ассоци­ ации ( F P R U N L . 1 . 1 ) межсетевого доступа для сущностей, ассоциирован¬ ных с защищаемой сетью или самим межсетевым экраном. Эти требова¬ н и я могут быть в ы п о л н е н ы на основе использования механизма трансля­ ц и и адресов и п р и м е н е н и я серверов-посредников. П р и м е р проекта [29] показывает, что в российских условиях м о ж н о обойти формальные, но не содержательные, проблемы, связанные с криптографией. В любом случае криптографические аппаратные и про¬ граммные модули необходимо разрабатывать и / и л и оценивать, даже если само слово «криптография» в п р о ф и л е защиты отсутствует. Ш и ф р о в а н и е и контроль целостности необходимы для организа­ ции доверенного канала с целью обеспечения безопасности удаленно­ го а д м и н и с т р и р о в а н и я ( с о о т в е т с т в у ю щ и е т р е б о в а н и я б ы л и р а с с м о т ­ р е н ы р а н е е в ч и с л е о б щ и х д л я р а з л и ч н ы х с е р в и с о в ) . Д л я н и х сущест­ вуют р о с с и й с к и е Г О С Т ы , к о т о р ы м и м о ж н о в о с п о л ь з о в а т ь с я п р и п о с т ­ р о е н и и а н а л о г о в п р о ф и л е й [49] и [65]. А у т е н т и ф и к а ц и я , устойчивая к сетевым угрозам, также обязательна, однако национальный крипто­ г р а ф и ч е с к и й Г О С Т д л я н е е н е принят. П р и х о д и т с я , к а к это с д е л а н о в [29], о г р а н и ч и в а т ь с я о б щ и м и т р е б о в а н и я м и в е р и ф и к а ц и и с е к р е т о в ( F I A S O S . 1 ) и з а щ и щ е н н о с т и от п о д д е л к и ( F I A U A U . 3 ) . В п р о ч е м , в л ю б о м случае п р и в л е ч е н и е н а ц и о н а л ь н ы х (а н е м е ж д у н а р о д н ы х ) с т а н д а р т о в создает п р о б л е м ы в з а и м о д е й с т в и я с и н о с т р а н н ы м и п а р т ­ нерами и осложняет взаимное признание сертификатов разными странами.

Системы активного аудита В работе [12] приведен набросок семейства п р о ф и л е й защиты для к л а с с и ф и к а ц и и систем активного аудита, а также соображения по расши¬ р е н и ю набора функциональных требований «Общих критериев». Проек¬ ты П З для важнейших компонентов подобных систем — анализатора и сенсора — представлены в [63], [64]. П о д подозрительной активностью понимается поведение пользова­ теля или компонента и н ф о р м а ц и о н н о й системы — злоумышленное (в со¬ ответствии с заранее определенной политикой безопасности) или нети¬ пичное (согласно п р и н я т ы м критериям). 91

Курс

Информационная безопасность: основные стандарты и спецификации

Назначение активного аудита — оперативно выявлять подозритель­ ную активность и предоставлять средства для автоматического реагирова­ н и я на нее. П о целому ряду п р и ч и н , из числа которых м ы выделим обеспечение масштабируемости, средства активного аудита строятся в архитектуре м е ­ неджер/агент. О с н о в н ы м и агентскими компонентами являются к о м п о ­ ненты извлечения регистрационной и н ф о р м а ц и и (сенсоры). Анализ, п р и н я т и е р е ш е н и й — ф у н к ц и и менеджеров. Очевидно, между менеджера¬ ми и агентами д о л ж н ы быть с ф о р м и р о в а н ы доверенные каналы. В число ф у н к ц и й безопасности, с п е ц и ф и ч н ы х для средств активно­ го аудита, входят генерация и извлечение регистрационной и н ф о р м а ц и и , ее анализ и реагирование на подозрительную активность. Отметим, что такой универсальный аспект, как безопасное админи¬ стрирование, для средств активного аудита приобретает особое значе¬ ние, если включить в него автоматическую к о р р е к ц и ю (в первую очередь — пополнение) базы сигнатур атак. Тем не менее, соответствующие тре¬ бования целесообразно отнести к числу общих, поскольку аналогичная возможность нужна, н а п р и м е р , другому сервису безопасности — анализу защищенности. И з существенных для активного аудита компонентов класса F A U «Аудит безопасности» в «Общих критериях» отсутствуют анализ на соот¬ ветствие политике безопасности (пороговый, статистический и сигнатур¬ н ы й анализы в семействе F A U S A A предусмотрены), хранилища для о п и с а н и й контролируемых объектов и для анализируемой и н ф о р м а ц и и , а также все и н т е р ф е й с н ы е компоненты. Слабо отражена возможность вы¬ бора рассматриваемых событий как сенсорами (агентами), так и анализа¬ торами (менеджерами). С целью адекватного отражения с п е ц и ф и к и средств активного ауди­ та в [12] предложен ряд добавлений к стандартному набору функциональ¬ ных требований. В семейство F A U G E N (генерация данных аудита безопасности) предлагается включить два новых компонента. F A U G E N . 3 — а с с о ц и и р о в а н и е вызвавшего событие объекта с включением в регистрационные записи и м е н и (идентификатора) этого объекта. Н а м и н и м а л ь н о м уровне д о л ж н ы протоколироваться о т к р ы ­ тие/закрытие объекта (установление/разрыв соединения и т.п.), на базо¬ вом — все промежуточные операции. На детальном уровне в регистраци¬ о н н ы е записи д о л ж н ы входить все операнды операции с объектом. Компонент F A U G E N . 3 добавлен по двум причинам. Во-первых, должна соблюдаться симметрия между субъектами и объектами. Во-вторых, статистические профили целесообразно строить не для субъектов, а для объектов, но для этого нужно располагать соответствующей информацией. 92

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

Е щ е один предлагаемый компонент — F A U G E N . 4 — предназначен для обеспечения неотказуемости сервиса, пользующегося услугами се­ мейства F A U G E N , от регистрации события. Вообще говоря, неотказуемость реализуется, даже если не были востребованы к о м м у н и к а ц и и , п о ­ этому здесь нельзя прибегнуть к классу F C O . Стандартный компонент F A U S A R . 3 дает возможность осуществ­ лять поиск и сортировку регистрационной и н ф о р м а ц и и , задавая в каче­ стве критериев логические выражения. П о д о б н ы е выражения полезны также для задания фильтров, управляющих работой сенсоров. Автоматический анализ регистрационной и н ф о р м а ц и и с целью вы¬ я в л е н и я подозрительной активности представлен в «Общих критериях» четырьмя компонентами семейства F A U S A A . F A U S A A . 1 ориентирован на обнаружение п р е в ы ш е н и я порогов, за¬ данных ф и к с и р о в а н н ы м набором правил. F A U S A A . 2 служит для выявления нетипичной активности путем анализа п р о ф и л е й поведения. В «Общих критериях» предлагаются п р о ­ ф и л и для субъектов, хотя п р о ф и л и объектов могут оказаться предпочти тельными. «Общие критерии» допускают анализ и в реальном времени, и пост¬ фактум; поддержку анализа в реальном времени следует рассматривать к а к важнейшую отличительную особенность средств активного аудита. F A U S A A . 3 направлен на обнаружение простых атак путем проведе­ н и я сигнатурного анализа. F A U S A A . 4 позволяет выявлять сложные, многоэтапные атаки, осу­ ществляемые группой злоумышленников. Предусматривается возможность настройки всех четырех к о м п о н е н ­ тов путем добавления, м о д и ф и к а ц и и или удаления правил, отслеживае¬ мых субъектов и сигнатур. В [12] вводится еще один компонент, F A U SAA.5, ф и к с и р у ю щ и й нарушения политики безопасности. Задавать политики предлагается с п о м о щ ь ю предикатов первого порядка. Ч т о касается автоматического реагирования на подозрительную активность, то «Общие критерии», по сути, ограничились констатацией п о д о б н о й возможности. В [12] рассматривается более с л о ж н а я сущ¬ ность — решатель, к о т о р ы й , получив р е к о м е н д а ц и и от к о м п о н е н т о в анализа, определяет, действительно ли имеет место подозрительная ак¬ тивность, и, п р и необходимости, н а д л е ж а щ и м образом реагирует (выби¬ рая ф о р м у р е а к ц и и в зависимости от серьезности в ы я в л е н н ы х наруше¬ ний). Это значит, что решатель должен уметь: • ранжировать подозрительную активность; • реагировать в соответствии с рангом нарушения. 93

Курс

Информационная безопасность: основные стандарты и спецификации

Управление обоими аспектами поручено администратору безопас¬ ности. В качестве отдельной возможности, присущей системам высокого класса, фигурирует проведение корреляционного анализа и н ф о р м а ц и и . О п и с а н и е к о н т р о л и р у е м ы х о б ъ е к т о в и х р а н е н и е соответствую¬ щ е й и н ф о р м а ц и и — в а ж н е й ш а я составная часть средств а к т и в н о г о ау­ дита, п р и д а ю щ а я и м свойства р а с ш и р я е м о с т и и н а с т р а и в а е м о с т и . К этому к о м п о н е н т у п р е д ъ я в л я ю т с я г л а в н ы м о б р а з о м т е х н о л о г и ч е с к и е требования. М о н и т о р ы , организующие оболочки для менеджеров средств актив­ ного аудита, д о л ж н ы обладать двумя группами свойств: • обеспечивать защиту процессов, составляющих менеджер, от зло¬ умышленных воздействий; • обеспечивать высокую доступность этих процессов. Первая группа обслуживается семейством F P T SEP. Вторая группа свойств поддерживается такими техническими р е ш е ­ н и я м и , как программное обеспечение (ПО) промежуточного слоя, клас­ терные конфигурации и т.д. В плане безопасности целесообразно следо­ вать требованиям F P T F L S . 1 (невозможность перехода в небезопасное состояние в случае сбоя или отказа), а также F P T RCV.2, F P T RCV.3, F P T R C V . 4 (надежное восстановление в автоматическом режиме, без по¬ тери данных, с точностью до ф у н к ц и и безопасности). Безопасность интерфейсов монитора (с другими мониторами, сен­ сорами, администратором безопасности) может обеспечиваться к о м п о ­ нентами F P T I T I . 1 , F P T I T I . 2 (обнаружение и исправление м о д и ф и к а ­ ц и и экспортируемых данных), F P T I T C . 1 (конфиденциальность э к с п о р ­ тируемых данных), F P T I T A . 1 (доступность экспортируемых данных). На рабочем месте администратора безопасности необходимо иметь стандартные для средств управления функции: графический интерфейс, возможность настройки способа визуализации, уровня детализации и от¬ бора отображаемых событий. С п е ц и ф и ч н о й для средств активного аудита является возможность получения объяснений от анализаторов и решателей по поводу обнару­ ж е н н о й подозрительной активности. Такие объяснения помогают в ы ­ брать адекватный способ реагирования. П р и ф о р м и р о в а н и и к л а с с и ф и к а ц и о н н о й схемы средств активного аудита в [12] предлагается выделить базовый (минимальный) П З , а допол­ нительные требования компоновать в ф у н к ц и о н а л ь н ы е пакеты. П р о ф и л и защиты, соответствующие классам з а щ и щ е н н о с т и , стро¬ ятся на основе базового П З и соответствующих к о м б и н а ц и й Ф П . В [12] предлагается зафиксировать п р о ф и л и для следующих разно¬ видностей средств активного аудита: 94

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

• класс 5 — защита одного и н ф о р м а ц и о н н о г о сервиса с отслеживани¬ ем фиксированного набора характеристик и пороговым анализом (базовый П З ) ; • класс 4 — защита однохостовой конфигурации с произвольным на¬ бором и н ф о р м а ц и о н н ы х сервисов, отслеживанием сетевого трафи¬ ка, системных и прикладных событий, пороговым и простым сигна¬ турным анализом в реальном масштабе времени; • класс 3 — защита сегмента локальной сети от многоэтапных атак при сохранении остальных предположений класса 4; • класс 2 — защита произвольной конфигурации с выявлением нетипич­ ного поведения при сохранении остальных предположений класса 3; • класс 1 — наложение всех требований с возможностью обеспечения заданного соотношения между о ш и б к а м и первого и второго рода. В контексте «Общих критериев» важным и сложным является подня­ тый в [12] вопрос о целесообразности разработки и применения жестких классификационных схем для сервисов безопасности. С одной стороны, гибкость требований О К такова, что на их основе можно разработать множе­ ство профилей защиты с минимальными требованиями, учитывающими специфику информационных систем и их окружения и позволяющими до­ биться необходимого уровня безопасности с минимальными затратами. С другой стороны, едва ли не все И С имеют тенденцию к частым и многочис¬ ленным изменениям, способным нарушить истинность сделанных в П З предположений безопасности. Слишком точная подгонка профилей защиты (равно как и характеристик ИС) опасна, у них должен быть запас прочности. В приведенной выше классификации предусмотрено изменение защищае¬ мой конфигурации, поэтому заказчик может выбрать класс «на вырост». К л а с с и ф и к а ц и о н н а я схема показывает способы усиления ф у н к ц и й безопасности (для средств активного аудита это в первую очередь расши¬ рение спектра отслеживаемых параметров, п о в ы ш е н и е оперативности и усложнение методов анализа регистрационной и н ф о р м а ц и и ) , что важно при выборе подходящей реализации сервиса безопасности из большого числа доступных вариантов. Н а к о н е ц , наличие большого числа несравнимых между собой мини¬ мальных профилей создает проблемы и для производителей сервисов бе¬ зопасности, поскольку вовлекает их в многочисленные процедуры серти¬ ф и к а ц и и . К о н е ч н о , при этом могут быть использованы результаты пре¬ дыдущих испытаний, но у каждой процедуры все равно остается сущест­ венная постоянная часть (финансовая и временная). М о ж н о сделать вывод, что для совокупности п р о ф и л е й з а щ и т ы це¬ лесообразно с самого начала планировать п о с т р о е н и е иерархии насле¬ д о в а н и я с п р и м е н е н и е м соответствующих ф у н к ц и о н а л ь н ы х пакетов. Часть узлов в этой иерархии ( н а п р и м е р , о б щ и е требования к сервисам 95

Курс

Информационная безопасность: основные стандарты и спецификации

безопасности) могут быть ф и к т и в н ы м и в том смысле, что и м н е соответ¬ ствуют п р о ф и л и для з а к о н ч е н н ы х изделий ИТ, однако о н и столь ж е не¬ обходимы, к а к и ( о б о б щ е н н ы е ) и н т е р ф е й с ы в объектно-ориентирован¬ н ы х системах.

Анонимизаторы Анонимизаторы предназначены для выполнения функциональных требований приватности (класс F P R «Общих критериев»). В д а н н о м раз¬ деле, основываясь на статье [80] и п р о ф и л е защиты [54], м ы рассмотрим одну из разновидностей анонимизаторов — сеть серверов пересылки, обеспечивающую приватность пользователей электронной почты. Вероятно, приватность — это единственный класс функциональных требований ОК, направленных не на обеспечение безопасности иерархиче¬ ски организованных, жестко администрируемых систем, а на защиту специ¬ фических интересов пользователей информационных сервисов. В «Оран¬ жевой книге» Министерства обороны С Ш А и Руководящих документах Гостехкомиссии России подобных требований не было, поэтому необходи¬ мо накапливать опыт по их применению, что придает работам [80] и [54] особую ценность. Происходит становление так называемой многоаспект¬ ной информационной безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих между собой) всех субъектов ин¬ формационных отношений, а также все виды конфигураций И С , в том чис¬ ле децентрализованные, не имеющие единого центра управления. Напомним, что класс F P R содержит четыре семейства: F P R A N O (анонимность — возможность совершать действия, не раскрывая иденти­ фикационных данных пользователя), F P R P S E (псевдонимность — а н о ­ нимность с сохранением подотчетности), F P R U N L (невозможность ассо­ циации — анонимность с сокрытием связи между действиями одного поль­ зователя), F P R U N O (скрытность, или ненаблюдаемость — сокрытие са­ мого факта использования ресурса или услуги). Псевдонимность полезна, например, когда за многократное обращение к каким-то специфическим платным услугам полагаются скидки. Невозможность ассоциации позволя­ ет защититься от раскрытия личности пользователя путем анализа п р о ф и ­ ля его поведения. Назначение семейств F P R A N O и F P R U N O очевидно. Сеть серверов пересылки почты состоит из независимо администрируемых узлов. Отправитель определяет в ней путь сообщения, которое шифруется таким образом, что каждому серверу известны только преды­ дущий и следующий узлы. В результате достигается невозможность уста­ новления ассоциации между отправителем и получателем. Если в сооб­ щ е н и и отсутствуют и д е н т и ф и к а ц и о н н ы е д а н н ы е отправителя, то обеспе­ чиваются анонимность, невозможность ассоциации и, отчасти, скрыт96

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

ность. Псевдонимность может быть реализована путем п р и м е н е н и я осо¬ бым образом заданных обратных адресов. Отметим, что на тех ж е прин¬ ципах организуется работа анонимизаторов для других и н ф о р м а ц и о н н ы х сервисов, в частности, для Web-доступа. Существуют свободно распрост­ р а н я е м ы е (Mixmaster) и к о м м е р ч е с к и е ( к о м п а н и и Zero Knowledge Systems) реализации сетей серверов пересылки. Сеть серверов п е р е с ы л к и м о ж н о рассматривать д в о я к о : изнутри и извне. Т р а д и ц и о н н ы й взгляд изнутри, с точки зрения гипотетического администратора сети, обязанного обеспечить ее безопасность и высо¬ кую доступность, ведет к т р а д и ц и о н н о м у ж е п р о ф и л ю з а щ и т ы , требова¬ н и я которого противоречат приватности. Действительно, д л я з а щ и т ы сети от атак на доступность необходимо выявлять подозрительную а к ­ тивность путем н а к о п л е н и я и анализа р е г и с т р а ц и о н н о й и н ф о р м а ц и и , уметь прослеживать пользователей и т.п. В силу указанных п р и ч и н в д а н н о м разделе м ы будем придерживаться взгляда извне, с точки зрения пользователя сервиса а н о н и м и з а ц и и ; с этих п о з и ц и й и разработан про¬ ф и л ь [54]. Для сети серверов пересылки сообщений выделяются следующие специфические угрозы безопасности: • возможность установления ассоциации между отправителем и полу­ чателем, если путь сообщения проходит только через один сервер пересылки; • установление контроля над несколькими серверами пересылки и проведение совместного анализа их регистрационной и н ф о р м а ц и и . Отметим также, что многие общие угрозы (маскарад сервера с целью распространения поддельных криптографических ключей, установление контроля над одним и з серверов пересылки для извлечения необходимой к о н ф и д е н ц и а л ь н о й и н ф о р м а ц и и , перенаправление потоков данных с це¬ лью подмены части сети пересылки, анализ потоков данных между поль¬ зовательской системой и сетью пересылки и т.п.) приобретают в указан¬ н о м контексте специфический характер, так к а к направлены на наруше¬ н и е приватности пользователей. Формулируются два специфических положения политики безопас¬ ности: • обеспечение анонимности сообщений, т. е. получатель н е может уз¬ нать и д е н т и ф и к а ц и о н н ы х данных отправителя, если последний сам не поместил их в сообщение в я в н о м виде; • обеспечение невозможности прослеживать сообщения, т. е. в резуль­ тате перехвата нельзя одновременно узнать отправителя и получателя. Перечислим специфические цели безопасности: • серверы пересылки должны принимать и обрабатывать сообщения, не опираясь на какую-либо и н ф о р м а ц и ю об отправителе; 97

Курс

Информационная безопасность: основные стандарты и спецификации

• содержание сообщений на всем пути следования скрыто от сторон¬ них наблюдателей; • сеть серверов пересылки необходимо построить таким образом, что¬ бы успешно противостоять попыткам анализа потоков данных, в ча¬ стности, потоков между пользовательской системой и сетью; • сеть серверов пересылки следует построить с учетом того, чтобы пользователь мог (и, более того, был обязан) корректно распреде­ лять между узлами сети д а н н ы е , существенные для невозможности прослеживания адресатов сообщения, а также выбирать узлы, участ­ вующие в обработке сообщения. Сеть пересылки обязана реализо¬ вать пользовательский выбор; • пользователи и узлы сети пересылки должны однозначно идентифи¬ цироваться, а сообщения — доставляться в нужные узлы с сохране¬ нием конфиденциальности соответствующих данных; • сеть серверов пересылки должна быть построена так, чтобы исполь¬ зование, распространение и интервал времени доступности данных, влияющих на возможность ассоциации пользователей, были мини¬ мальными; • н и одному субъекту (пользователю, администратору, злоумышлен­ нику) нельзя предоставлять возможность получения и н ф о р м а ц и и , достаточной для прослеживания отправителей сообщений. С п е ц и ф и ч е с к и е цели безопасности для среды: • узлы сети пересылки д о л ж н ы администрироваться независимо и, более того, антагонистично; • сеть пересылки должна быть топологически распределенной. Чтобы лучше понять приведенные н и ж е специфические ф у н к ц и о ­ нальные требования, целесообразно помнить, что рассматриваемый п р о ­ филь защиты сформирован с п о з и ц и й пользователя, так что в объект о ц е н к и (ОО) входят как серверы пересылки, так и клиентские системы. Все потоки данных контролируются ф у н к ц и я м и безопасности О О ; экс¬ порта или импорта данных не происходит. В пределах области действия ф у н к ц и й безопасности имеют место следующие виды операций: • передача сообщения клиентской системой серверу пересылки; • пересылка сообщений, а также управляющей и н ф о р м а ц и и (в том числе ключевой), между серверами; • доставка сообщения с сервера на клиентскую систему; • обработка сервером пересылки (транзитных) сообщений; • операции, выполняемые сервером с криптографическими ключами: г е н е р а ц и я , р а с п р о с т р а н е н и е , х р а н е н и е , доступ, и с п о л ь з о в а н и е , уничтожение; • порождение сервером пересылки ф и к т и в н ы х сообщений. 98

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

Для отправки сообщения пользователь должен задать целевой адрес и цепочку серверов пересылки. П р и получении почты требуется аутенти­ ф и к а ц и я , так к а к входящие сообщения нуждаются в р а с ш и ф р о в а н и и . В пределах объекта о ц е н к и действует специфическая форма полити­ ки принудительного управления доступом, состоящая в том, что каждый элемент пользовательских данных приписывается определенному субъ¬ екту, и только этот субъект получает право на доступ к п р и п и с а н н ы м ему д а н н ы м . Далее провозглашается политика борьбы со скрытыми канала­ м и , чтобы противостоять попыткам анализа потоков данных. С п е ц и ф и ч е с к и е ф у н к ц и о н а л ь н ы е требования состоят в следующем. • полное управление доступом ( F D P A C C . 2 ) . Политика принудитель­ ного управления доступом должна распространяться на всех субъек¬ тов (серверы пересылки, клиентское П О , пользователи, админист¬ раторы), все объекты (в том числе на содержание и маршрутную ин¬ ф о р м а ц и ю сообщений) и все операции; • ограниченное управление информационными потоками ( F D P I F C . 1). Должна проводиться в ж и з н ь политика борьбы со скры¬ тыми каналами применительно к серверам пересылки, клиентскому П О , сообщениям, передаче и приему сообщений ( F D P I F C . 1 . 1 ) ; • частичное устранение неразрешенных и н ф о р м а ц и о н н ы х потоков ( F D P IFF.4). Политику борьбы со скрытыми каналами необходимо внедрять, чтобы уменьшить до заданных пределов утечку информации о работе пользователей с сетью пересылки, возникающую за счет ана¬ лиза периферийных потоков данных ( F D P I F F . 4 . 1 ) . Получение про­ филей поведения компонентов сети пересылки путем анализа перифе­ рийных потоков данных должно быть невозможным ( F D P I F F . 4 . 2 ) ; • полное управление временем хранения данных ( F D P IRC.2). Все объекты, нужные для нормальной работы сети пересылки, удаляют­ ся сразу после завершения операций с н и м и . Отметим, что это не просто специфическое, но новое функциональное требование, пред¬ ложенное автором п р о ф и л я защиты; • управление атрибутами безопасности ( F M T M S A . 1 ) . Согласно п о ­ литике принудительного управления доступом, только пользова­ тель, сгенерировавший д а н н ы е , может выполнять операции над их атрибутами безопасности, в число которых входят маршрут сообще­ н и я и его рандомизация, м и н и м а л ь н о е число пересылок, число от­ правляемых избыточных сообщений, параметры потоков данных и криптографических алгоритмов и т.п. ( F M T M S A . 1 . 1 ) ; • анонимность без запроса и н ф о р м а ц и и ( F P R A N O . 2 ) . Д о л ж н ы обес­ печиваться невозможность определения подлинного и м е н и отпра­ вителя с о о б щ е н и я , обрабатываемого сетью серверов пересылки ( F P R ANO.2.1), а также невозможность отслеживания и а н о н и м 99

Курс

Информационная безопасность: основные стандарты и спецификации

ность пересылки сообщений для всех пользователей без запроса ка­ кой-либо ссылки на подлинное имя пользователя ( F P R A N O . 2 . 2 ) ; • размещение информационных ресурсов ( F P R T R D . 2 ) . Сеть пересыл­ ки должна состоять из отдельных взаимодействующих частей, в каж­ дой из которых реализуются свои правила аутентификации и управле­ ния доступом ( F P R T R D . 2 . 1 ) . Доступ к данным другой части предо­ ставляется только по явному запросу ( F P R T R D . 2 . 2 ) . Данные, критич­ ные для невозможности ассоциации (маршрут, время и т.п.), должны храниться в виде, исключающем их полное чтение одной частью сети, чтобы обеспечить невозможность прослеживания всей цепочки между отправителем и получателем сообщения ( F P R T R D . 2 . 3 ) . Этот и два последующих компонента предложены автором профиля защиты; • распределение обработки сообщений ( F P R T R D . 3 ) . П о своей сути этот компонент аналогичен предыдущему с точностью до замены слова «храниться» на «обрабатываться»; • невозможность ассоциации пользователей ( F P R U N L . 2 ) . Должна обеспечиваться невозможность установления факта отправки сооб¬ щ е н и й одним и тем ж е пользователем. Для мер доверия безопасности предлагается о ц е н о ч н ы й уровень 5. Н а п о м н и м , что его характерными особенностями являются п р и м е н е н и е формальной модели политики безопасности, полуформальных функцио¬ нальной с п е ц и ф и к а ц и и и проекта верхнего уровня с демонстрацией соот­ ветствия между н и м и , а также проведение анализа скрытых каналов раз¬ работчиками и о ц е н щ и к а м и . Это очень высокий уровень, но в д а н н о м случае его выбор представляется оправданным, поскольку, с одной сторо¬ н ы , объект оценки относительно прост, с легко формализуемой полити¬ кой безопасности, а с другой, в функциональных требованиях предусмо¬ трен анализ скрытых каналов. Рассмотренный профиль защиты, на н а ш взгляд, весьма поучителен. О н демонстрирует как достоинства, так и недостатки «Общих критериев». К числу достоинств м о ж н о отнести богатый набор современных ф у н к ц и ­ ональных требований, особо выделив требования приватности. К сожале­ н и ю , к а к м ы уже отмечали, они носят «точечный», а не концептуальный или архитектурный характер. Для требования распределенности архитек­ туры пришлось вводить новое семейство — F P R T R D . Отметим, в свою очередь, что отнесение его к классу приватности не кажется нам оправ­ д а н н ы м . Распределенность п р и н ц и п и а л ь н о важна для целого ряда сис¬ тем, но если в системах электронных платежей, как и в сети серверов пе¬ ресылки, это необходимое условие приватности (в п р о ф и л е новое семей¬ ство получило наименование «распределения доверия»), то во многих других случаях она играет инфраструктурную роль, обеспечивая живу­ честь (устойчивость к отказам) и / и л и масштабируемость (в сочетании с 100

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

архитектурой менеджер/агент). Очевидно, архитектурные требования за¬ служивают отдельного класса. Требования безопасности повторного использования, безусловно, д о л ж н ы быть д о п о л н е н ы требованиями м и н и м и з а ц и и времени хранения объектов, что и сделано в рассмотренном профиле. Это важно, п о м и м о приватности, практически для всех приложений криптографии, в ситуа­ циях, когда образуются временные ф а й л ы с и н ф о р м а ц и е й ограниченного доступа и т.п. Авторы работ [80], [54] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкрет¬ н ы е п р о ф и л и получаются проще, естественнее, однако их сравнение с н е ­ стандартными компонентами усложняется. Возможный выход подсказы­ вает технология программирования, предусматривающая п р о б л е м н о ориентированные р а с ш и р е н и я базовых интерфейсов, к а к это выполнено, например, в Java-системах [33]. П о д о б н ы е р а с ш и р е н и я м о ж н о разрабо¬ тать и стандартизовать быстрее, ч е м п о л н ы й набор требований, посколь¬ ку о н и затрагивают более узкий круг специалистов, объединенных к тому ж е общностью интересов.

Выпуск и управление сертификатами В документе [72] предлагается упорядоченное семейство из четырех п р о ф и л е й защиты для аппаратно-программных компонентов, реализую¬ щ и х выпуск, аннулирование и управление сертификатами открытых клю¬ чей (удовлетворяющими, например, с п е ц и ф и к а ц и я м X.509) (Certificate Issuing and Management Components, C I M C ) . Таким образом, перед нами жесткая классификационная схема, рас­ считанная на применение в разнообразных средах. Каждый заказчик, учи­ тывая степень критичности И С и реальные риски, сам выбирает необхо¬ д и м ы й уровень защищенности и соответствующий ему профиль. Н а ниж¬ нем (первом) уровне потенциал злоумышленников и риски предполагают¬ ся н и з к и м и , прежде всего обеспечивается защита от случайных ошибок авторизованных пользователей (например, за счет использования п р и н ­ ципа разделения обязанностей). П р и переходе на более высокие уровни угрозы нарастают, а требования ужесточаются. Н а верхнем (четвертом) уровне злоумышленниками могут быть и авторизованные пользователи, а требования безопасности оказываются настолько жесткими, что удовле­ творить и м могут только перспективные изделия ИТ. Это разумный под¬ ход, снабжающий ориентирами и заказчиков, и разработчиков. Объект о ц е н к и в профилях и з [72] является элементом инфраструк¬ туры открытых ключей и в общем случае включает нижеследующие функ¬ циональные компоненты: 101

Курс

Информационная безопасность: основные стандарты и спецификации

• центр выпуска и аннулирования сертификатов (именуемый также удостоверяющим центром, У Ц ) . Это — ядро ОО. Сгенерированная и н ф о р м а ц и я помещается в хранилище (см. далее). Между различны­ ми У Ц могут существовать отношения доверия; • центры приема пользовательских запросов на создание сертификатов или изменение их статуса. Обязательные компоненты объекта оцен¬ ки, которые верифицируют представленные пользователем данные; • серверы, обслуживающие протокол оперативной выдачи статуса сертификатов. Этот компонент может отсутствовать или находиться за пределами О О ; • серверы восстановления и / и л и распространения секретного ключе­ вого материала — дополнительная ф у н к ц и я . Отметим, что хранилище сертификатов и и н ф о р м а ц и и об их статусе, обслуживающее запросы приложений, находится вне р а м о к ОО. П о м и м о функциональных, в объект оценки входят инфраструктур н ы е компоненты: • криптографический модуль. Он подписывает сертификаты и списки их аннулирования, при необходимости генерирует криптографичес­ кие ключи. Требования безопасности, предъявляемые к криптогра­ фическим модулям, изложены в федеральном стандарте С Ш А FIPS P U B 140-2 [50], заменившем FIPS P U B 140-1 (см. [45]); • модуль администрирования; • модуль идентификации и аутентификации; • модуль ролевого управления доступом; • модуль протоколирования и аудита. Представленная в ы ш е логическая к о м п о н е н т н а я архитектура не обязательно совпадает с физической структурой объекта оценки. В п р и н ­ ц и п е возможна монолитная реализация О О , объединение/расщепление компонентов и т.д. Переходя к специфическим ф у н к ц и о н а л ь н ы м требованиям безопас­ ности для среды, отметим выделение в [72] четырех ролей: • администратор (отвечает за установку, конфигурирование, обслужи¬ вание нужд пользователей и т.п.); • оператор (выполняет резервное копирование и восстановление); • инспектора (ведает запросами и утверждением сертификатов и их статуса); • аудитор (анализирует регистрационную и н ф о р м а ц и ю ) . В соответствии с компонентом F M T S M R . 2 (ограничения на роли безопасности), один пользователь не может выступать более чем в одной из перечисленных в ы ш е ролей ( F M T S M R . 2 . 3 ) . Среда д о л ж н а обеспечить защиту к о н ф и д е н ц и а л ь н о с т и д а н н ы х пользователя при передаче между ф у н к ц и я м и безопасности ( F D P U C T ) . 102

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

Более точно, надо обеспечить базовую конфиденциальность обмена д а н ­ н ы м и ( F D P UCT.1). Аналогичная защита необходима для к о н ф и д е н ц и ­ альных данных самой среды ( F P T I T C . 1 , F P T I T T . 1 ) . К р о м е того, требу­ ется контроль целостности данных. Криптографическими методами контролируется целостность (в ча¬ стности, аутентичность) программного кода, присутствующего в системе, и кода, который в п р и н ц и п е может быть загружен (дополнительные тре¬ бования п р о ф и л я F P T T S T C I M C . 2 и F P T T S T C I M C . 3 ) . Среди специфических (более того, дополнительных, по сравнению с «Общими критериями») функциональных требований безопасности для объекта о ц е н к и выделим наиболее значимые: • и н и ц и и р о в а н и е и обработка события подписывания регистрацион­ ного журнала ( F P T C I M C T S P . 1 ) , выполняемого с конфигурируе¬ мой периодичностью. Подпись должна контролировать целостность по крайней мере тех регистрационных записей, которые появились после предыдущего подписывания. В регистрационной записи о са­ мом событии подписывания присутствуют электронная цифровая подпись, значение х э ш - ф у н к ц и и или имитовставка аналогичного назначения; • и н и ц и и р о в а н и е и обработка события постановки третьей стороной подписанных меток времени ( F P T C I M C T S P . 2 ) . Этот компонент аналогичен предыдущему и обеспечивает дополнительный контроль целостности регистрационных данных (например, на случай ком¬ прометации объекта оценки); • резервное копирование и восстановление ( F D P C I M C B K P . 1 ) , с дополнительными (криптографическими) мерами контроля целост­ ности и обеспечения конфиденциальности ( F D P C I M C B K P . 2 ) , с точностью до последней завершенной транзакции ( F D P C I M C B K P . 3 ) . Н а з в а н н ы е к о м п о н е н т ы направлены на безо­ пасное (в том числе свободное от внедрения вредоносного кода) вос­ становление. Отметим, что подобные требования полезны также для СУБД и других систем с транзакциями; • принудительные доказательство и в е р и ф и к а ц и я подлинности источ¬ ника данных о статусе сертификатов и других данных, критичных для безопасности ( F C O N R O C I M C . 3 ) . Аналогично д о л ж н ы к о н ­ тролироваться заявки на регистрацию сертификатов. Предпочти¬ тельный способ доказательства подлинности — ц и ф р о в ы е подписи (FCONROCIMC.4).; • экспортируемая и н ф о р м а ц и я об и з м е н е н и и статуса сертификатов должна иметь формат, о п и с а н н ы й в с п е ц и ф и к а ц и я х X.509 для с п и с ­ ков аннулирования или R F C 2560 для протокола оперативной выда­ ч и статуса сертификатов ( F D P C I M C C S E . 1 ) ; 103

Курс

Информационная безопасность: основные стандарты и спецификации

• защита к о н ф и д е н ц и а л ь н о с т и секретных ключей пользователей ( F D P A C F C I M C . 2 ) и функций безопасности ( F M T M T D C I M C . 4 ) . Секретные ключи обслуживающего персонала и функций безопаснос¬ ти объекта оценки должны храниться в стандартном криптографичес­ ком модуле или шифроваться стандартными методами. Секретные ключи пользователей шифруются с помощью долговременных ключей защиты. Аналогичные требования предъявляются к хранению секрет­ ных ключей симметричных методов шифрования ( F D P A C F C I M C . 3 и FMTMTDCIMC.5); • секретные ключи д о л ж н ы экспортироваться либо в з а ш и ф р о в а н н о м виде, л и б о с и с п о л ь з о в а н и е м процедур р а з д е л е н и я з н а н и й (FDP_ETC_CIMC.4, FDP_ETC_CIMC.5, FMTMTDCIMC.6, FMTMTDCIMC.7); • контроль целостности хранимых открытых ключей ( F D P _ D S I _ C I M C . 3 ) . Открытые ключи, хранимые в объекте о ц е н к и вне криптографического модуля, нужно защитить от н е с а н к ц и о н и ­ рованного изменения стандартными криптографическими метода­ ми. Проверку целостности требуется производить при каждом досту¬ пе к ключу; • обнуление секретных ключей ( F C S C K M C I M C . 5 ) . Ф у н к ц и и безо­ пасности д о л ж н ы обеспечить обнуление открытого представления секретных ключей в криптографическом модуле; • контроль допустимости значений полей сертификатов ( F M T _ M O F _ C I M C . 3 ) . Ф у н к ц и и безопасности контролируют значе­ н и я полей сертификатов в соответствии с правилами, заданными ад¬ министратором. Аналогичные проверки необходимо производить для списков аннулированных сертификатов ( F M T _ M O F _ C I M C . 5 ) и сообщений протокола оперативной выдачи статуса сертификатов (FMT_MOF_CIMC.6); • генерация сертификатов ( F D P C I M C CER.1). Генерируются только корректные сертификаты, удовлетворяющие требованиям стандарта (X.509) и правилам, заданным администратором. Такие же требования должны выполняться для списков аннулированных сертификатов ( F D P _ C I M C _ C R L . 1) и сообщений протокола оперативной выдачи ста­ туса сертификатов ( F D P C I M C O C S P . 1 ) . До выпуска сертификата не­ обходимо убедиться, что его предполагаемый владелец обладает секрет¬ ным ключом, ассоциированным с открытым ключом из сертификата. Требования доверия безопасности усиливаются параллельно с возра­ станием выбранного уровня п р о ф и л я защиты. Для верхнего, четвертого уровня используются в основном требования ОУД4 и, частично, ОУД5, а также требование A L C F L R . 3 (систематическое устранение недостат­ ков), не входящее н и в один ОУД. 104

Лекция 6

Профили защиты. Часть 2. Частные требования к сервисам безопасности

На наш взгляд, рассмотренное семейство профилей может служить примером при построении к л а с с и ф и к а ц и о н н ы х схем в Руководящих до¬ кументах Гостехкомиссии России.

Анализ защищенности Анализ защищенности — сравнительно н о в ы й , но весьма популяр¬ н ы й сервис безопасности, помогающий реализовать профилактический подход к обеспечению защиты и н ф о р м а ц и о н н ы х систем. Суть его весьма проста, но «Общими критериями» он поддержан крайне слабо. Посмот¬ р и м , как м о ж н о изменить это положение. Предлагается ввести новый класс функциональных требований — F P A : анализ защищенности. В нем может быть три семейства: • F P A H L P : описание уязвимости, выдача рекомендаций по ее устра¬ нению; • F P A _ R A D : автообнаружение контролируемых объектов; • F P A _ S P A : анализ характеристик защищенности. Семейство F P A H L P может состоять из одного компонента: • F P A H L P . 1 — описание, выдача (возможно, с заданным уровнем де­ тализации) сведений об уязвимостях, и н ф о р м а ц и я о которых содер­ жится в базе данных системы анализа з а щ и щ е н н о с т и (эта база дан¬ ных аналогична базе правил в компоненте анализа регистрационной информации FAU_SAA.1). Д л я семейства F P A H L P предусмотрено м н о г о к р а т н о е и с п о л ь з о ­ в а н и е ( н а п р и м е р , д л я выдачи с в е д е н и й об атаках средствами а к т и в н о ­ го аудита). Его роль с р а в н и м а с р о л ь ю к о м м е н т а р и е в в я з ы к а х п р о ­ г р а м м и р о в а н и я ; отсутствие п о д о б н о г о семейства, на н а ш взгляд, я в л я ­ ется м е т о д о л о г и ч е с к о й н е д о р а б о т к о й а в т о р о в « О б щ и х критериев». Выдача п о я с н е н и й п о л е з н а н е т о л ь к о д л я а н а л и з а з а щ и щ е н н о с т и , н о и д л я в ы б о р а р е а к ц и и на о б н а р у ж е н н у ю атаку. ( П о ч е м у система анализа р е ш и л а , что атака имеет место? К а к и е п р а в и л а п р и э т о м сработали? Н а с к о л ь к о серьезна о б н а р у ж е н н а я атака? Н а все эти в о п р о с ы админи¬ стратор б е з о п а с н о с т и д о л ж е н получить о п е р а т и в н ы е , и н ф о р м а т и в н ы е ответы.) Семейство F P A _ R A D может располагать одним компонентом: • F P A _ R A D . 1 — автообнаружение компонентов анализируемой И С , описание которых содержится в базе данных системы анализа защи¬ щенности. В семействе F P A _ S P A возможно присутствие трех компонентов: • F P A SPA.1 — проверка наличия в системе и / и л и сети сущностей, указанных в базе данных системы анализа з а щ и щ е н н о с т и (имеются в виду небезопасные сервисы, такие, например, как T F T P ) ; 105

Курс

Информационная безопасность: основные стандарты и спецификации

• F P A S P A . 2 — анализ характеристик выявленных сущностей (номе¬ ров версий, конфигурационных параметров, атрибутов доступа, сла¬ бых паролей — и здесь анализируется то, что перечислено в базе д а н ­ ных). Правила для анализа могут быть с л о ж н ы м и , охватывающими несколько характеристик; • FPA_SPA.3 — проверка реакции объекта на в ы п о л н е н и е определен¬ ных действий (имитация атак, перечисленных в базе). Надеемся, что предлагаемый класс функциональных требований бе­ зопасности поможет в разработке п р о ф и л я защиты для систем анализа за¬ щищенности.

106

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

Л е к ц и я 7. П р о ф и л и з а щ и т ы , р а з р а б о т а н н ы е на о с н о в е «Общих к р и т е р и е в » . Часть 3. Ч а с т н ы е т р е б о в а н и я к к о м б и н а ц и я м и приложениям сервисов безопасности Описываются предположения и цели безопасности, функциональные требования и требования доверия, специфичные для конкретных комбинаций и приложений сервисов безопасности. Наиболее подробно рассматриваются частные функциональные требования.

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

Операционные системы О п е р а ц и о н н ы е системы (ОС) — классический объект о ц е н к и по тре¬ бованиям безопасности еще со времен «Оранжевой книги». Более того, до сих пор остается весьма распространенным м н е н и е о том, что это важ¬ нейшее, едва ли не единственное защитное средство. С современных по¬ з и ц и й О С м о ж н о рассматривать как к о м б и н а ц и ю сервисов идентифика¬ ц и и и аутентификации, управления доступом и протоколирования/ауди¬ та. К р о м е того, операционные системы обеспечивают базовые, инфраст¬ руктурные свойства безопасности, в том числе разделение доменов и по¬ средничество при обращениях. Для операционных систем разработан целый ряд п р о ф и л е й защиты (см. [78], [79], [89], [90], [9], [10]). К этой ж е группе документов м о ж н о от­ нести руководство по разработке п р о ф и л е й для перспективных к о м м е р 107

Курс

Информационная безопасность: основные стандарты и спецификации

ческих продуктов И Т [88], поскольку оно, к а к и [79], [89], [90], [10]), ори¬ ентировано на класс безопасности C2 «Оранжевой книги». М ы , однако, рассмотрим проект [9] (адаптированный вариант про¬ ф и л я [78]), в целом соответствующий четвертому классу защищенности по к л а с с и ф и к а ц и и Гостехкомиссии России для средств вычислительной техники, поскольку о н более представителен с точки зрения требований безопасности. О п е р а ц и о н н ы е системы, удовлетворяющие проекту П З , должны обеспечивать д и с к р е ц и о н н о е и мандатное управление доступом, мандат¬ ное управление целостностью и предоставлять криптографические сер­ висы. Всем пользователям необходим ассоциированный уровень допуска, определяющий максимальный уровень чувствительности данных, к кото­ р ы м о н и могут обращаться (см. в ы ш е раздел «Требования к принудитель¬ ному (мандатному) управлению доступом»). Вероятно, единственная специфическая угроза для рассматриваемого класса О С заключается в неадекватной классификации данных на основе их меток, что способствует осуществлению несанкционированного доступа к (помеченным) данным. В качестве контрмеры провозглашается специфи­ ческая цель безопасности: «Операционная система должна предоставлять возможность расставлять точные метки чувствительности и целостности». Е щ е одна очевидная цель состоит в том, что операционная система обязана поддерживать домен для своего собственного в ы п о л н е н и я , это защитит ее и принадлежащие ей ресурсы от внешнего вмешательства, ис¬ кажения или несанкционированного раскрытия. Для борьбы с маскарадом сервера операционная система должна выде­ лять средства, предотвращающие связь пользователя с некоторой сущнос­ тью, выдающей себя за операционную систему, но не являющейся таковой. И з числа специфических функциональных требований наибольший интерес представляют криптографические компоненты. Остановимся на них подробнее: • генерация криптографических ключей (FCS C K M . 1 ) . Симметричные криптографические ключи должны генерироваться в соответствии с согласованным с Ф А П С И алгоритмом, реализуемым аппаратным или программным генератором случайных чисел (см. далее компонент F C S C O P E X P . 2 ) и / и л и схемой генерации ключей, которая основана на криптографии с открытым ключом, использует программный и / и л и аппаратный генератор случайных чисел, определенный в F C S C O P E X P . 2 , и хэш-функцию по ГОСТ Р 34.11-94. Асимметрич­ ные криптографические ключи должны генерироваться, согласуясь с параметрами криптографического преобразования, применяя генера­ тор случайного числа и/или генератор простых чисел и удовлетворяя ГОСТ Р 34.10-2001 в части генерации простых чисел, ГОСТ Р 34.10108

Лекция 7

•

•

•

•

•

Профили защиты. Часть 2. Частные требования к комбинациям...

2001 для реализации процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического ал¬ горитма, ГОСТ 28147-89 для реализации процедур зашифрования и расшифрования данных, а также требованиям из этого проекта П З : F P T _ C T S T _ E X P , F C S _ C O P _ E X P . 2 и документации разработчика. Д о ­ полнительное требование упомянутого проекта П З состоит в том, что к каждому сгенерированному симметричному ключу должна добав¬ ляться имитовставка алгоритма ГОСТ 28147-89 или контрольная сум¬ ма другого аттестованного алгоритма ( F C S _ C K M _ E X P . 1 ) ; распределение криптографических ключей ( F C S _ C K M . 2 ) . Согласно проекту профиля [9], ключи должны распределяться (вручную или ав­ томатически) в соответствии с требованиями Ф А П С И и действующих нормативных документов. Н е предусматривается автоматическое рас¬ пределение секретных ключей асимметричных криптосистем; доступ к криптографическим ключам ( F C S C K M . 3 ) . Ключи д о л ж н ы храниться только в з а ш и ф р о в а н н о м виде в соответствии с требова­ ниями Ф А П С И и действующих нормативных документов ( F C S C K M . 3 . 1 ) . Дополнительное требование: и н ф о р м а ц и ю , позво­ ляющую однозначно идентифицировать ключ ( F C S _ C K M _ E X P . 3 . 1 ) , хранить нельзя; уничтожение криптографических ключей ( F C S _ C K M . 4 ) . Криптогра¬ фические ключи должны уничтожаться в соответствии с требования­ ми Ф А П С И и действующих нормативных документов. Удалять ключи и другие критичные параметры необходимо немедленно, полностью и таким образом, чтобы поверх ключа/критичной области памяти запи­ сывались три или более различных шаблонов ( F C S C K M . 4 . 1 ) ; криптографические операции ( F C S C O P . 1 ) . Операции зашифрова­ н и я / р а с ш и ф р о в а н и я данных д о л ж н ы выполняться в соответствии с алгоритмом криптографического преобразования по ГОСТ 28147-89 или другим аттестованным алгоритмом, а операции вычисления ци¬ фровой подписи — в соответствии с алгоритмом выработки и про¬ верки электронной ц и ф р о в о й подписи на базе асимметричного криптографического алгоритма по ГОСТ Р 34.10-2001 или другим аттестованным алгоритмом. Операции хэширования выполняются согласно определенному ГОСТ Р 34.11-94 или другому аттестован¬ ному алгоритму, операции обмена криптографическими ключами — в соответствии с требованиями Ф А П С И и действующих норматив¬ ных документов. (FCS_COP.1.1); генерация случайных чисел ( F C S C O P EXP.2 — дополнительный компонент, предложенный в д а н н о м проекте П З ) . Генерация слу­ чайных чисел должна выполняться множеством независимых аппа­ ратных и / и л и программных датчиков, выходы которых объединяют 109

Курс

Информационная безопасность: основные стандарты и спецификации

ся с использованием х э ш - ф у н к ц и и по ГОСТ Р 34.11-94 или другого аттестованного алгоритма ( F C S _ C O P _ E X P . 2 . 1 ) . Д а т ч и к и случай­ ных/псевдослучайных чисел необходимо защитить от нарушения алгоритмов (режимов) их ф у н к ц и о н и р о в а н и я ( F C S _ C O P _ E X P . 2 . 2 ) ; • защита остаточной и н ф о р м а ц и и криптографического ключа (FDP_RIP_EXP.2 — дополнительный компонент). Любой ресурс, содер¬ жащий критичные параметры безопасности, при освобождении этого ресурса должен быть очищен от всей информации путем перезаписи по¬ верх его содержимого, как определено процедурой уничтожения ключа; • отделение домена функций безопасности (FPT_SEP_EXP.1 — дополни¬ тельный компонент). Поддерживается криптографический домен, отде¬ ленный от остальных функций безопасности, защищенный от вмеша¬ тельства и искажения недоверенными субъектами (FPT_SEP_EXP. 1.1); • тестирование криптографического модуля ( F P T _ C T S T _ E X P — допол­ нительное семейство). Для проверки правильности функционирова­ ния криптографического модуля необходимо реализовывать возмож­ ность его тестирования путем выполнения набора встроенных тестов при начальном запуске, по запросу администратора по криптографии и периодически (FPT_CTST_EXP.1.1). Тесты должны обеспечивать проверку и документирование статистических характеристик генера¬ торов случайных/псевдослучайных чисел и отображение результатов тестирования (FPT_CTST_EXP.1.2). Предписывается выполнение те­ стов обнаружения ошибок в ключе при начальном запуске и по запро­ су администратора по криптографии (FPT_CTST_EXP.1.3), а также немедленное (сразу после генерации ключа) самотестирование каж¬ дого участвующего в генерации ключей компонента для верификации его ф у н к ц и о н и р о в а н и я в соответствии с F C S C K M . 1 . 1 и F C S _ C O P _ E X P . 2 (FPT_CTST_EXP.1.4). Сгенерированный ключ не должен использоваться, если самотестирование какого-либо компо¬ нента завершилось неудачей (FPT_CTST_EXP.1.5); • доверенный маршрут ( F T P _ T R P _ E X P . 1 — дополнительный компо¬ нент). Криптографический модуль должен обеспечивать маршрут связи между собой и локальными пользователями, который логиче­ ски отличим от других маршрутов и предоставляет уверенную иден­ т и ф и к а ц и ю самого себя (FTP_TRP_EXP.1.1). Для обслуживания криптографических средств в рассматриваемом проекте П З предусмотрен дополнительный компонент требований дове¬ р и я безопасности: • анализ скрытых каналов криптографического модуля (AVA C C A EXP.1). Для криптографического модуля разработчику следует провести поиск скрытых каналов утечки критичных парамет¬ ров безопасности (AVA_CCA_EXP.1.1D) и представить документацию 110

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

анализа скрытых каналов (AVA_CCA_EXP.1.2D), которая идентифи¬ цирует скрытые каналы в криптографическом модуле и содержит оценку их пропускной способности (AVA_CCA_EXP.1.1C). Докумен¬ тация должна содержать описание процедур, используемых для заклю­ чения о существовании скрытых каналов в криптографическом моду­ ле, и информацию, необходимую для проведения анализа скрытых ка­ налов (AVA_CCA_EXP.1.2C). Кроме того, в ней описываются все пред­ положения, сделанные в процессе анализа (AVA_CCA_EXP.1.3C), ме­ тод, применяемый для оценки пропускной способности канала в слу­ чае наиболее опасного сценария (AVA_CCA_EXP.1.4C), и сам наибо­ лее опасный сценарий использования каждого идентифицированного скрытого канала (AVA_CCA_EXP.1.5C). Оценщик обязан подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств (AVA_CCA_EXP.1.1E), а результаты анализа скрытых каналов показывают, что криптографиче¬ ский модуль удовлетворяет функциональным требованиям (AVA_CCA_EXP.1.2E). Наконец, произведя тестирование, он выбороч¬ но подтверждает правильность результатов анализа скрытых каналов (AVA_CCA_EXP.1.3E). М о ж н о видеть, что в проекте п р о ф и л я [9] вопросы криптографии изложены весьма пространно, однако смысл всех требований предельно прост: соответствие н а ц и о н а л ь н ы м стандартам (их три). Многократно упоминаемое соответствие требованиям Ф А П С И и действующих норма¬ тивных документов — условие туманное, допускающее неоднозначное толкование. (Заметим, что ссылка на требования определенного ведомст­ ва — вещь рискованная, так как последнее может прекратить свое сущест­ вование.) Небесспорно и введение дополнительных, по сравнению с «Об­ щ и м и критериями», требований (функциональных и доверия). Н а п о м н и м , что в рассмотренном в ы ш е П З для межсетевых экранов [49] криптография используется, п о м и м о ш и ф р о в а н и я и контроля цело­ стности, также и для аутентификации, однако ссылки на национальный стандарт и привлечения стандартных требований оказалось достаточно. Н е я с н о , почему следует особо оговаривать отделение криптографическо¬ го домена или проведение анализа скрытых каналов криптографического модуля — другие ф у н к ц и и безопасности не менее критичны и д о л ж н ы об­ ладать не меньшей собственной защищенностью. Целесообразно выде­ лить требования к криптографическим модулям в отдельный документ, к а к это сделано в федеральном стандарте С Ш А FIPS P U B 140-2 [50], а не перегружать и м и профиль защиты ОС. Далее, в рассматриваемом проекте П З предусмотрена возможность удаленного администрирования, но отсутствует у п о м и н а н и е об аутенти¬ ф и к а ц и и с использованием криптографических методов, а также о з а щ и 111

Курс

Информационная безопасность: основные стандарты и спецификации

те от подделки и / и л и воспроизведения аутентификационных данных (компоненты F I A U A U . 3 и F I A U A U . 4 «Общих критериев»). В результа­ те остаются без противодействия стандартные сетевые угрозы. Е щ е одна специфическая особенность О С — возможность управле­ н и я использованием ресурсов, их распределением между пользователя­ ми. Для этого уместно применить механизм квотирования. • максимальные квоты ( F R U R S A . 1 ) . Пользователям д о л ж н ы выде­ ляться квоты долговременной и оперативной памяти, а также про¬ цессорного времени ( F R U _ R S A . 1 . 1 ) . Рассмотренный проект профиля защиты для операционных систем показывает, как важно соблюдать определенный уровень формализации изложения, а также единый уровень детализации. Неоднородность П З чре¬ вата несистематичностью, завышением или занижением требований. К со¬ жалению, «Общие критерии» не регламентируют этот аспект разработки профилей защиты, заданий по безопасности и функциональных пакетов. Отдельного рассмотрения заслуживают специфические функциональ­ ные требования, присутствующие в проекте [89]. Выше, в разделе «Системы активного аудита», мы отмечали важность требований к интерфейсам и их бе¬ зопасности. В [89] предложен дополнительный элемент F A U G E N . 1 - C S P P . 3 , предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов. Для управления экспортом данных пользователя в соответствии с п о ­ литикой безопасности введен элемент F D P E T C . 1 - C S P P . 3 , предусматрива¬ ющий выделение отдельного пула выходных каналов (например, путем ре¬ зервирования номеров TCP-портов), недоступных обычным приложениям. Поддержка распределенных конфигураций регламентируется целым ря¬ дом дополнительных требований, направленных на обеспечение конфиден¬ циальности ( F P T I T C . 1 . 1 - C S P P ) , целостности (FPTITI.1.1-CSPP), согласо­ ванности ( F P T S Y N - C S P P . 1 . 1 ) критичных данных функций безопасности. В заключение раздела следует отметить, что в Центре безопасности и н ф о р м а ц и и создан проект базового п р о ф и л я защиты для О С и разраба­ тывается профиль защиты О С в средах, нуждающихся в высокой робастности (защищенности), с тем чтобы иметь завершенное семейство про¬ филей защиты операционных систем.

Системы управления базами данных Системы управления базами данных (СУБД), к а к и операционные системы, содержат к о м б и н а ц и ю сервисов безопасности, однако, в отли¬ ч и е от О С , не являются самодостаточными. СУБД используют механиз­ м ы и ф у н к ц и и О С . Такая двухуровневость ведет к появлению с п е ц и ф и ч е 112

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

ских угроз и требует привлечения соответствующих средств противодей­ ствия. Н а п р и м е р , базы данных располагаются в файлах или на дисках, уп­ равляемых О С ; следовательно, к объектам БД м о ж н о обратиться как штатными средствами СУБД, так и с п о м о щ ь ю механизмов О С , получив доступ к файлу или устройству. П о д о б н ы е возможности д о л ж н ы учиты¬ ваться в п р о ф и л е защиты для СУБД. Дальнейшее изложение основано на проекте П З [11] (его прототип [87] соответствует классу безопасности C2 «Оранжевой книги»). Здесь вводится понятие аутентификационного пакета, который предо­ ставляет для СУБД механизм подтверждения подлинности заявляемого идентификатора пользователя. В рассматриваемом проекте профиля защиты для этого необходим хотя бы один из двух механизмов: внешний (аутентифи­ кация средствами ОС) или внутренний (аутентификация средствами СУБД). Е щ е одно проявление упомянутой в ы ш е двухуровневости — предпо­ ложение безопасности базовой конфигурации, состоящее в том, что базо­ вая система (операционная система, и / и л и сетевые сервисы безопаснос¬ ти, и / и л и специальное программное обеспечение) установлены, сконфи¬ гурированы и управляются безопасным образом. Аналогичную направленность имеют цели безопасности для среды, предусматривающие, что базовая система должна обеспечить механизмы управления доступом, которые позволят защитить от несанкционирован­ ного доступа все связанные с СУБД файлы; кроме того, О С предоставит средства для изоляции ф у н к ц и й безопасности и защиты процессов СУБД. Отметим, что в распределенной среде управление доступом и изоляция могут поддерживаться не только средствами базовой ОС, но и архитектур­ но, путем разнесения компонентов СУБД по узлам сети и использования межсетевых экранов. Эта возможность в проекте [11] не рассматривается. Переходя к функциональным требованиям безопасности, укажем на важность требований согласованности данных между функциями безопас¬ ности ( F P T _ T D C ) , а также согласованности данных функций безопаснос¬ ти п р и дублировании в пределах распределенного объекта о ц е н к и (FPT T R C ) . Согласованность достигается с помощью некоторой ф о р м ы обработки распределенных транзакций или путем обновления дублируе¬ мых данных с применением какого-либо протокола синхронизации. К со¬ жалению, требования этих семейств в проекте [11] не представлены, равно как и требования распределенности хранения и обработки для повышения устойчивости к отказам. Конечно, в «Оранжевой книге» ничего подобного не было, однако в наше время, как показывает профиль [54], следование определенным архитектурным принципам является обязательным. Для защиты от атак на доступность в рассматриваемом проекте пре­ дусмотрены реализация квот, выделяемых пользователям ( F R U RSA.1), а также базовые ограничения на параллельные сеансы ( F T A M C S . 1 ) . 113

Курс

Информационная безопасность: основные стандарты и спецификации

В целом, на н а ш взгляд, проект [11] нуждается в доработке. Необхо­ д и м о учесть специфику современных СУБД, в частности, требования обеспечения динамической целостности данных, реализуемые механиз­ мом транзакций. Требования безопасного восстановления носят слиш¬ ком о б щ и й характер. Защита от стандартных угроз, существующих в сете¬ вой среде, целиком переложена на базовую систему. Н е учтены специфи¬ ческие для СУБД угрозы, описанные, например, в главе « И н ф о р м а ц и о н ­ ная безопасность систем управления базами данных» книги [1].

Виртуальные частные сети Туннелирование и ш и ф р о в а н и е (наряду с необходимой криптогра¬ фической инфраструктурой) на выделенных шлюзах в к о м б и н а ц и и с эк¬ ранированием на маршрутизаторах поставщиков сетевых услуг (для раз­ деления пространств «своих» и «чужих» сетевых адресов в духе виртуаль­ ных локальных сетей) позволяют реализовать такое важное в н ы н е ш н и х условиях защитное средство, к а к виртуальные частные сети. П о д о б н ы е сети, наложенные обычно поверх Internet, существенно дешевле и гораз¬ до безопаснее, ч е м действительно собственные сети организации, пост¬ р о е н н ы е на выделенных каналах. К о м м у н и к а ц и и на всем их протяжении физически защитить невозможно, поэтому лучше изначально исходить из предположения об уязвимости и соответствующим образом обеспечи¬ вать защиту. Современные протоколы, поддерживающие с п е ц и ф и к а ц и и IPsec (см., например, [15]), позволяют сделать это. На концах туннелей, реализующих виртуальные частные сети, целе¬ сообразно установить межсетевые э к р а н ы , обслуживающие подключение организаций к в н е ш н и м сетям. В таком случае туннелирование и ш и ф р о ­ вание становятся дополнительными преобразованиями, в ы п о л н я е м ы м и в процессе фильтрации потоков данных наряду с трансляцией адресов. П о м и м о корпоративных межсетевых экранов, в роли конечных устройств могут выступать мобильные компьютеры сотрудников (точнее, их персо¬ нальные М Э ) . Далее соответствующие узлы сети м ы будем называть опорными. В качестве основы последующего изложения выбран проект п р о ф и ­ ля защиты [32], где объект о ц е н к и — совокупность опорных узлов. Требо­ вания к перспективным средствам аналогичного назначения представле­ н ы в документе [85]. Поскольку реализация виртуальных частных сетей в значительной степени основывается на криптографических механизмах, в число специ­ фических угроз входят п р и м е н е н и е злоумышленником методов и средств криптографического анализа, а также компрометация криптографичес­ ких ключей. Упомянем и угрозы доступности каналов связи. 114

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

Для нейтрализации угроз д о л ж н ы быть в ы п о л н е н ы ф у н к ц и о н а л ь ­ н ы е требования безопасности, относящиеся к криптографии. Необходи­ м о осуществление к о н т р о л я доступа к к р и п т о г р а ф и ч е с к и м к л ю ч а м ( F C S C K M . 3 . 1 ) , ш и ф р о в а н и е ( F C S C O P . 1 . 1 ) и п р и м е н е н и е механизмов контроля целостности ( F C S C O P . 1 . 1 ) и н ф о р м а ц и и , передаваемой в рам¬ ках доверенного канала. В виртуальной частной сети управление и н ф о р м а ц и о н н ы м и пото¬ к а м и ограничивается ( F D P I F C . 1 . 1 ) . В о о б щ е говоря, через о п о р н ы е уз­ л ы проходят н е только п о т о к и данных, п р е д н а з н а ч е н н ы е для виртуаль­ н о й частной сети, н о и д а н н ы е для в н е ш н и х адресатов. Эти потоки д о л ж н ы различаться и обрабатываться п о - р а з н о м у ( н а п р и м е р , п е р в ы е необходимо ш и ф р о в а т ь , а вторые — нет). П о сути, д о л ж н о быть реализо¬ вано межсетевое э к р а н и р о в а н и е , только одна из сетей является вирту¬ альной. От виртуальных частных сетей требуется реализация некоторых ас¬ пектов приватности. О н и не д о л ж н ы допустить, чтобы извне м о ж н о было определить подлинное и м я пользователя, связанного с передаваемой в рамках доверенного канала и н ф о р м а ц и е й ( F P R A N O . 1 . 1 ) . В то ж е время, администратору необходимо предоставить возможность наблюдения за использованием ресурсов и функционированием процессов (FPR_UNO.4.1). О п о р н ы е узлы д о л ж н ы обладать определенной отказоустойчивос¬ тью, обеспечивая возврат к безопасному состоянию, генерацию записи журнала аудита, сигнализацию администратору, когда происходит сбой в системе электропитания или нарушение безопасности ( F R U FLT.1.1). Таковы специфические ф у н к ц и о н а л ь н ы е требования безопасности для виртуальных частных сетей. В «Общих критериях» в я в н о м виде не представлены требования к туннелированию; нет их и в рассмотренном проекте. Возможно, туннелирование трактуется л и ш ь как механизм обес­ печения анонимности.

Виртуальные локальные сети П о д виртуальной локальной сетью в проекте п р о ф и л я защиты [31] понимается такое логическое объединение узлов локальной сети, при ко¬ тором обмен д а н н ы м и на канальном уровне эталонной семиуровневой модели возможен только между этими узлами. Использование виртуальных локальных сетей позволяет: • повысить производительность (и доступность) сети за счет локали¬ зации потоков данных; • обеспечить защиту передаваемых данных посредством логического разделения среды передачи; 115

Курс

Информационная безопасность: основные стандарты и спецификации

• реализовать управление доступом пользователей к сетевым ресурсам. Разграничение потоков данных обеспечивается путем фильтрации кадров данных. Таким образом, объект оценки оказывается межсетевым э к р а н о м канального уровня. В проекте [31] рассматриваются два способа построения виртуаль¬ ных локальных сетей: • группировка портов объекта оценки. В этом случае каждый порт поддерживает только одну виртуальную сеть; • использование специальной метрики для определения принадлеж¬ ности к конкретной виртуальной локальной сети. Впрочем, предлагаемые в проекте требования безопасности в равной степени п р и м е н и м ы к обоим вариантам. От рассмотренных ранее межсетевых экранов объект о ц е н к и отлича¬ ется ограниченностью ресурсов и меньшей функциональностью. В част­ ности, вся работа с регистрационной и н ф о р м а ц и е й (начиная с хранения) возлагается на среду, точнее, на так называемое средство анализа собы­ тий. Это освобождает объект оценки от ряда стандартных требований протоколирования и аудита, но ведет к необходимости организации дове¬ ренного канала.

Смарт-карты П р о ф и л ь защиты для смарт-карт [86] интересен необычностью объ­ екта оценки. О н позволяет оценить гибкость и разнообразие требований «Общих критериев». Эта необычность заключается в следующем: • м и н и м у м аппаратных ресурсов (интегральная схема, включающая процессор; оперативная и постоянная память относительно неболь¬ шого объема; порты ввода/вывода) в сочетании с программным обеспечением ограниченной функциональности (в п р о ф и л е [86] рассматривается базовое П О ) ; • принадлежность неконтролируемой среде, когда карта может ока¬ заться в руках злоумышленника, располагающего специальным обо¬ рудованием. В защите (обеспечении конфиденциальности и целостности) нужда¬ ются хранящиеся на карте пользовательские д а н н ы е , программное обес¬ печение (прикладное и базовое), а также аппаратные компоненты. Отметим, что п р и е м н о е устройство, снабжающее смарт-карту элек¬ тропитанием и связью с в н е ш н и м миром, не входит в объект оценки. Учитывая ограниченность ресурсов и потенциально враждебную среду, сервисы безопасности для смарт-карт д о л ж н ы быть отобраны и ре¬ ализованы с особой тщательностью. 116

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

Сформулируем предположения безопасности для среды: • после установления доверенного канала с п р и е м н ы м устройством последнее предполагается достаточно безопасным, чтобы поддер¬ живать доверенные к о м м у н и к а ц и и ; • предполагается, что обеспечена конфиденциальность и целостность и н ф о р м а ц и и , хранящейся вне карты и существенной для ее безопас­ ности. Имеются в виду как пользовательские д а н н ы е , так и крипто­ графические ключи, загружаемые приложения и т.п. С большинством возможных угроз смарт-карта должна справляться самостоятельно, без п о м о щ и среды. Выделим специфические (а также специфически реализуемые и отражаемые) угрозы: • осуществление доступа к смарт-карте с п о м о щ ь ю специального обо¬ рудования, когда преследуется цель выяснить определенные аппа­ ратные и / и л и программные характеристики (применяемые крипто¬ графические механизмы, используемые ключи, хранимые д а н н ы е и программы и т.п.). Н е исключены попытки изменить аппаратнопрограммную к о н ф и г у р а ц и ю и / и л и д а н н ы е , а также перевести смарт-карту в небезопасное состояние, поместив ее в стрессовые ус­ ловия (например, температурные или электромагнитные); • логические атаки: отслеживание зависимостей между входными д а н н ы м и операций, выполняемых смарт-картой, и результатами; попытки перевести карту в небезопасное состояние искусственно и н и ц и и р о в а н н ы м сбросом или загрузить вредоносные программы; использование некорректных входных данных; воспроизведение данных аутентификации; переборные атаки (на криптографические компоненты). К этой ж е категории угроз м о ж н о отнести попытки организовать нештатное взаимодействие прикладных ф у н к ц и й и выполнить действия (например, отладочные), предусмотренные для особых этапов жизненного цикла смарт-карты. Одновременное про¬ ведение нескольких атак; • н е с а н к ц и о н и р о в а н н ы й доступ: попытки злоупотребления п о л н о м о ­ ч и я м и при доступе к пользовательским д а н н ы м или д а н н ы м функ­ ц и й безопасности, а также использования н о в о й , н е до к о н ц а о ф о р м л е н н о й смарт-карты; • попытки выявления и анализа утечек и н ф о р м а ц и и во время нор¬ мальной работы смарт-карты, совместный анализ результатов мно¬ гих наблюдений. • попытки изготовления к о п и й (клонирование) компонентов смарткарты для детального изучения их поведения. С п е ц и ф и ч е с к о й угрозой для среды является замена интегральной схемы, установленной в смарт-карте, с целью несанкционированного до¬ ступа к д а н н ы м пользователя или ф у н к ц и й безопасности. 117

Курс

Информационная безопасность: основные стандарты и спецификации

И з специфических положений политики безопасности прежде всего отметим наличие уникальных и д е н т и ф и к а ц и о н н ы х данных для каждого объекта о ц е н к и , а также (как н и странно) накопление регистрационной и н ф о р м а ц и и , которое необходимо производить, несмотря на ограничен­ ность ресурсов. Аудит может выполняться во время сервисного обслужи­ вания смарт-карты. Цели безопасности формулируются таким образом, чтобы обес­ п е ч и т ь н е й т р а л и з а ц и ю угроз и в ы п о л н и т ь п о л о ж е н и я п о л и т и к и б е з о ­ п а с н о с т и : и н т е г р а л ь н а я схема д о л ж н а р а б о т а т ь в л ю б ы х , в т о м ч и с л е с т р е с с о в ы х , условиях; о с у щ е с т в л я е т с я з а щ и т а от м н о г о к р а т н о г о и с ­ п о л ь з о в а н и я р е с у р с о в п р и п е р е б о р н ы х атаках; и з у ч е н и е передавае¬ м ы х д а н н ы х н е д о л ж н о давать д о п о л н и т е л ь н о й и н ф о р м а ц и и п о срав¬ нению с анализом содержимого памяти; нормальное (безопасное) со­ с т о я н и е у с т а н а в л и в а е т с я сразу п о с л е п о д а ч и п и т а н и я и л и с б р о с а ; п р и з а м е н е и н т е г р а л ь н о й с х е м ы на к а р т е о б я з а т е л ь н о д о л ж н ы о с т а в а т ь с я с л е д ы и т. п. Перейдем к рассмотрению специфических функциональных требований: • автоматическая реакция аудита безопасности ( F A U A R P ) при обна­ ружении возможного нарушения безопасности. Предписываются м и н и м а л ь н ы е необратимые последствия реакции. Подчеркнем, что в силу с п е ц и ф и к и объекта оценки оперативное и н ф о р м и р о в а н и е ад¬ министратора безопасности в общем случае невозможно; с опаснос¬ тью приходится бороться самостоятельно; • генерация списка регистрационных данных ( F A U L S T — дополни¬ тельное семейство). На интегральной схеме, устанавливаемой в смарт-карте, нет часов; время указывает только п р и е м н о е устройст­ во, которое не считается доверенным. Следовательно, события мож­ но л и ш ь упорядочить по мере их появления, но с н и м и нельзя ассо­ циировать дату и время. В регистрационную и н ф о р м а ц и ю должны включаться и д е н т и ф и к а ц и о н н ы е д а н н ы е аппаратных и программ¬ ных компонентов; • противодействие физическому нападению ( F P T PHP.3). Ф у н к ц и и безопасности обязаны противодействовать попыткам эксплуатации в стрессовых условиях, отслеживанию и н ф о р м а ц и и , другим ф и з и ч е ­ ским атакам, автоматически реагируя таким образом, чтобы предот¬ вратить нарушение политики безопасности (FPT_PHP.3.1); • надежное восстановление ( F P T R C V ) . Автоматическое восстанов­ ление без недопустимой потери ( F P T R C V . 3 ) , восстановление функ¬ ции (FPT_RCV.4). Для требований доверия безопасности в [86] используется усилен¬ н ы й о ц е н о ч н ы й уровень 4. Усиление о б е с п е ч и в а ю т к о м п о н е н т ы 118

Лекция 7

Профили защиты. Часть 2. Частные требования к комбинациям...

A V A V L A . 3 (систематический п о и с к уязвимостей, обеспечение стойкости к нападениям, в ы п о л н я е м ы м нарушителем с умеренным потенциалом) и A D V I N T . 1 (модульность). Важным достоинством работы [86] является выделение двух ф у н к ц и ­ ональных пакетов: для интегральной схемы и базового П О . Эти части м о ­ гут разрабатываться независимыми производителями, поэтому целесооб¬ разно, чтобы они проводили такую же независимую сертификацию, а ин¬ тегратор (производитель смарт-карт) выбирал поставщиков и осуществлял интегральную сертификацию. В части функциональных требований пакет для базового П О аналогичен рассмотренному профилю; к аппаратуре предъявляется меньшее число требований. Например, в функциональном пакете для интегральной схемы отсутствуют компоненты F A U SAA.1 (ана­ лиз потенциального нарушения) и F P T R P L . 1 (обнаружение повторного использования), что представляется вполне естественным.

Некоторые выводы «Общие критерии» — исключительно м о щ н о е , гибкое средство раз¬ работки требований безопасности для изделий и н ф о р м а ц и о н н ы х техно­ логий. В частности, могут быть выделены общие требования к сервисам безопасности, а также учтена с п е ц и ф и к а конкретных сервисов, фигури¬ рующих по отдельности или в различных комбинациях. В то ж е время, сама гибкость «Общих критериев» — источник слож­ ных проблем, в первую очередь относящихся к методологии разработки п р о ф и л е й защиты. М о ж н о провести аналогию с я з ы к а м и и технологией программирования, когда владение передовым я з ы к о м программирова­ н и я вовсе не означает умения проектировать и создавать большие про¬ граммные комплексы. Вопросы технологии «программирования» профилей защиты носят разнообразный характер и затрагивают все этапы жизненного цикла П З . Какой подход выбрать при разработке П З : «снизу вверх» или «сверху вниз»? Сами «Общие критерии», имеющие библиотечную (не объектную) струк¬ туру, подталкивают к применению подхода «снизу вверх», от отдельных требований к общей функциональности. Однако, как показывает опыт раз­ работчиков профиля [54] (равно как и технология программирования), на¬ иболее предпочтителен подход «сверху вниз», от требуемой функциональ¬ ности объекта оценки к базовым механизмам безопасности. Е щ е один технологический аспект — модульность П З . Выделение функциональных пакетов для составных частей объекта о ц е н к и , реализо­ ванное в [86], дает больше свободы и разработчикам, и интеграторам, способствует раннему выявлению и устранению проблем, облегчает дея¬ тельность о ц е н щ и к о в . 119

Курс

Информационная безопасность: основные стандарты и спецификации

Следующий вопрос касается технологии сопровождения множества профилей защиты. К а к соотносить между собой отдельные ПЗ? К а к груп¬ пировать их, выстраивать иерархии и т.п.? П о к а зарегистрированных п р о ­ филей относительно немного (что само по себе является проблемой, н о , м о ж н о надеяться, временной), и все-таки очевидно, что их число будет расти, они станут поступать из различных источников, из разных стран, так что поддержание международного статуса «Общих критериев», несо¬ м н е н н о , потребует специальных усилий, которые целесообразно плани¬ ровать заранее (см. соглашение «О п р и з н а н и и сертификатов по О б щ и м критериям в области безопасности и н ф о р м а ц и о н н ы х технологий»). Очень серьезная проблема — неполнота функциональн^гх требований «Общих критериев». Как показывают рассмотренные профили, авторам П З приходится добавлять собственные нестандартные классы, семейства, компо¬ ненты и элементы, что ведет к несопоставимости разрабатываемых профилей, к усложнению процедур сертификации и взаимного признания сертификатов. П р и н ц и п и а л ь н ы й недостаток — отсутствие в «Общих критериях» ар¬ хитектурных и технологических требований. Такие свойства, как распре¬ деленность архитектуры, следование подходу менеджер/агент и т.п., н е ­ обходимы для успешной реализации ф у н к ц и й объекта о ц е н к и , о н и к р и ­ т и ч н ы для его безопасности. Таким образом, проведенный анализ позволяет наметить следующие направления дальнейших исследований и разработок: • создание новых профилей защиты, охватывающих все сервисы безо¬ пасности; • разработка методологии и соответствующих и н с т р у м е н т а л ь н ы х средств создания П З ; • разработка д и с ц и п л и н ы и инструментальных средств для использо­ вания множества п р о ф и л е й защиты; • развитие «Общих критериев», разработка новых стандартных требо¬ ваний безопасности, как «точечных», так и концептуальных, архи¬ тектурных; • разработка д и с ц и п л и н ы введения новых нестандартных требований с м и н и м и з а ц и е й проблем несопоставимости получающихся п р о ф и лей защиты. Для решения сформулированных проблем необходимо взаимодей¬ ствие специалистов, независимо от их национальной и, тем более, ведом¬ ственной принадлежности.

120

Лекция 8

Рекомендации семейства X.500

Л е к ц и я 8. Р е к о м е н д а ц и и с е м е й с т в а X . 5 0 0 Данные рекомендации очень важны в концептуальном плане. Служба директорий, формат сертификатов открытых ключей и атрибутов — это ба­ зовые элементы инфраструктуры программно-технического уровня инфор¬ мационной безопасности.

Ключевые слова: служба директорий, Директория, И н ф о р м а ц и о н н а я База Директории, И н ф о р м а ц и о н н о е Дерево Директории, элемент, различительное и м я , относительное различительное и м я , объект, класс, атрибут, с и н о н и м , опрос, чтение, сравнение, перечисление, поиск, фильтр, отказ от операции, м о д и ф и к а ц и я , управление досту­ пом, аутентификация, сертификат открытого ключа, удостоверяю¬ щ и й центр, субъект сертификата, пользователь сертификата, список отзыва сертификатов, поле р а с ш и р е н и я , кросс-сертификат, серти­ ф и к а ц и о н н ы й маршрут, п р я м ы е сертификаты, обратные сертифика¬ ты, политика сертификата, сертификат атрибутов, инфраструктура управления привилегиями, центр авторизации, главный центр авто­ ризации, делегирование привилегий, маршрут делегирования, пра­ вило д о м и н и р о в а н и я , предъявитель привилегий, верификатор п р и ­ вилегий, ролевое управление доступом, неотказуемость, простая ау­ т е н т и ф и к а ц и я , сильная аутентификация, токен безопасности, аутентификатор, временной штамп, односторонняя ф у н к ц и я , одно¬ сторонний обмен, двусторонний обмен, трехсторонний обмен, об¬ ратный с е р т и ф и к а ц и о н н ы й маршрут.

Основные понятия и идеи рекомендаций семейства X.500 Рекомендации семейства X.500 описывают службу директорий. Сре­ д и возможностей, предоставляемых этой службой, обычно выделяют дру¬ жественное именование (обращение к объектам по именам, удобным с точки зрения человека) и отображение и м е н в адреса (динамическое свя­ зывание объекта и его расположения — необходимое условие поддержки «самоконфигурируемости» сетевых систем). Основные понятия службы директорий зафиксированы в рекомен­ дациях X.501 «Служба директорий: модели» [56] и X.511 «Служба дирек¬ торий: абстрактное определение сервиса» [58]. Множество систем, обеспечивающих ф у н к ц и о н и р о в а н и е службы директорий, вместе с содержащейся в них и н ф о р м а ц и е й м о ж н о представ­ лять к а к единое целое — Директорию с большой буквы. 121

Курс

Информационная безопасность: основные стандарты и спецификации

Информация, доступ к которой возможен посредством Директории, называется Информационной Базой Директории. Она обычно используется для облегчения взаимодействия таких сущностей, как объекты прикладного уровня, люди, списки рассылки и т.д., а также для получения сведений о них. Предполагается, что И н ф о р м а ц и о н н а я База имеет древовидную структуру, называемую И н ф о р м а ц и о н н ы м Деревом Директории. Верши¬ н ы этого дерева, отличные от корня, составляют элементы Директории, в которых хранится и н ф о р м а ц и я об объектах. У каждого элемента есть однозначно идентифицирующее его разли­ чительное имя. В пределах поддеревьев И н ф о р м а ц и о н н о г о Дерева могут использоваться относительные различительные имена. Природа объектов, и н ф о р м а ц и я о которых хранится в Директории, произвольна. Единственное требование к н и м состоит в идентифицируе­ мости (возможности именования). Объекты объединяются в классы. К а ж д ы й объект должен принадле¬ жать по крайней мере одному классу. Элементы Директории могут быть составными, объединять подэлементы, содержащие и н ф о р м а ц и ю об отдельных аспектах объектов. Каждый элемент состоит из атрибутов, имеющих тип и одно или не¬ сколько значений. Набор атрибутов зависит от класса объекта. Некоторые из концевых узлов (листьев) И н ф о р м а ц и о н н о г о Дерева могут представлять собой с и н о н и м ы , содержащие альтернативное и м я и указатель на элемент с и н ф о р м а ц и е й об объекте. Служба директорий предоставляет две группы операций: • опрос; • модификацию. В число операций опроса входят: • чтение значений атрибутов элемента Директории; • сравнение значения атрибута элемента Директории с заданной вели­ ч и н о й (полезно, например, для проверки пароля без предоставления доступа к хранимому паролю); • выдача списка (перечисление) непосредственных преемников за¬ данного узла И н ф о р м а ц и о н н о г о Дерева; • поиск и чтение элементов, удовлетворяющих заданным фильтрам (условиям), в заданных частях И н ф о р м а ц и о н н о г о Дерева; • отказ от незавершенной операции опроса (например, если она вы¬ полняется с л и ш к о м долго). В группу операций м о д и ф и к а ц и и входят: • добавление нового (концевого) узла И н ф о р м а ц и о н н о г о Дерева; • удаление концевого узла И н ф о р м а ц и о н н о г о Дерева; • м о д и ф и к а ц и я элемента Д и р е к т о р и и с в о з м о ж н ы м добавлением и / и л и удалением атрибутов и их значений; 122

Лекция 8

Рекомендации семейства X.500

• м о д и ф и к а ц и я относительного различительного имени элемента или перемещение узла И н ф о р м а ц и о н н о г о Дерева к другому предшест¬ веннику. Рекомендации X.501 описывают три возможные схемы управления доступом к Директории: базовую, упрощенную и основанную на прави¬ лах; последняя может реализовывать принудительное (мандатное) управ­ л е н и е доступом с использованием меток безопасности. Решения о предо­ ставлении доступа принимаются с учетом существующей политики безо¬ пасности. Разумеется, предусмотрена аутентификация системных агентов и пользователей, а также источников данных Директории. Таковы основные понятия и идеи службы директорий, з а ф и к с и р о ­ в а н н ы е в семействе рекомендаций X.500 и необходимые нам для последу­ ющего изложения.

Каркас с е р т и ф и к а т о в о т к р ы т ы х к л ю ч е й М ы приступаем к изучению четвертой редакции рекомендаций X.509 [57], которая регламентирует следующие аспекты: • сертификаты открытых ключей; • сертификаты атрибутов; • сервисы аутентификации. И д е й н о й основой рекомендаций X.509 являются сертификаты от¬ крытых ключей, обслуживающие такие грани и н ф о р м а ц и о н н о й безопас¬ ности, как конфиденциальность и целостность, и такие сервисы, как ау¬ т е н т и ф и к а ц и я и неотказуемость. В курсе «Основы и н ф о р м а ц и о н н о й безопасности» [3] приведены н е ­ обходимые сведения о криптографии с открытыми ключами и механизме электронной ц и ф р о в о й подписи ( Э Ц П ) ; далее предполагается, что они уже известны. Сертификат открытого ключа — это структура данных, обеспечиваю¬ щ а я ассоциирование открытого ключа и его владельца. Надежность ассо­ ц и а ц и и , подлинность сертификата подтверждаются подписью удостове­ ряющего центра (УЦ). Сертификаты имеют конечный срок годности. Поддерживать акту¬ альность и н ф о р м а ц и и об их статусе помогают списки отзыва, подписыва¬ емые удостоверяющими центрами и содержащими перечни сертифика­ тов, переставших быть годными. Последнее может случиться как в ре­ зультате естественного окончания срока, так и досрочно, например, из-за компрометации секретного ключа владельца. Формат сертификата описан в курсе [3]. В простейшем случае он в ы ­ глядит так: 123

Курс

Информационная безопасность: основные стандарты и спецификации C A « A » =CA{V,SN,AI,CA,A,Ap,TA}

Здесь: A — и м я владельца сертификата; CA — имя удостоверяющего центра; CA<> — сертификат, выданный A центром C A ; CA{I} — д а н н ы е I, снабженные подписью C A ; V — версия сертификата (в настоящее время — версия 3); SN — порядковый номер сертификата; A I — идентификатор алгоритма, использованного при подписании сертификата; • Ap — и н ф о р м а ц и я об открытом ключе A ; • TA — даты начала и конца срока годности сертификата. Отметим, что в общем случае формат может быть существенно слож¬ нее. С п о м о щ ь ю механизма р а с ш и р е н и й его м о ж н о приспособить для нужд различных приложений и сообществ пользователей. В X.509 преду­ смотрены полезные р а с ш и р е н и я , н о с я щ и е универсальный характер. Каждое р а с ш и р е н и е включает и м я , флаг критичности и значение. Если при обработке (проверке) сертификата встречается неизвестное рас­ ш и р е н и е с флагом критичности F A L S E , о н о может быть проигнорирова­ но; если ж е у подобного р а с ш и р е н и я флаг равен T R U E , сертификат п р и ­ ходится считать некорректным. Сертификаты открытых ключей подразделяются на два основных вида: • сертификаты оконечных сущностей; • сертификаты удостоверяющих центров. Оконечные сущности не имеют права выпускать сертификаты. Удо¬ стоверяющие центры ведают выпуском и аннулированием сертификатов, которые относятся к одному из двух классов: • « с а м о в ы п у щ е н н ы е » с е р т и ф и к а т ы ( и з г о т о в л е н н ы е д л я себя с а м и м удостоверяющим центром). Они полезны, например, при смене к л ю ч е й У Ц , ч т о б ы о б е с п е ч и т ь д о в е р и е н о в ы м к л ю ч а м на основа¬ н и и д о в е р и я с т а р ы м . В а ж н ы м п о д к л а с с о м д а н н о г о класса я в л я ­ ются « с а м о п о д п и с а н н ы е » с е р т и ф и к а т ы , в к о т о р ы х с е к р е т н ы й к л ю ч , и с п о л ь з о в а н н ы й д л я г е н е р а ц и и Э Ц П , соответствует заве­ р я е м о м у о т к р ы т о м у ключу. Таким с п о с о б о м У Ц может а ф и ш и р о ¬ вать свой о т к р ы т ы й к л ю ч и л и и н у ю и н ф о р м а ц и ю о с о б с т в е н н о м функционировании; • кросс-сертификаты (выдаются одним У Ц другому). О н и п р и м е н я ­ ются и в иерархической структуре для авторизации нижестоящего УЦ вышестоящим, и в произвольной структуре «распределенного доверия» к а к факт п р и з н а н и я одним У Ц существования другого. • • • • • • •

124

Лекция 8

Рекомендации семейства X.500

Рассмотрим процесс получения и проверки пользователем A откры­ того ключа пользователя B. Элемент Директории, представляющий A, со¬ держит один или несколько сертификатов открытых ключей A, заверен¬ ных удостоверяющим центром, который м ы обозначим CA(A) (а серти­ фикат A — к а к CA(A)<>) и которому, разумеется, соответствует свой узел в И н ф о р м а ц и о н н о м Дереве. Предполагается, что пользователь дове­ ряет своему У Ц , поэтому, если существует сертификат CA(A)<>, п р о ­ цесс выяснения открытого ключа B м о ж н о считать завершенным. В п р о ­ тивном случае приходится строить так называемый с е р т и ф и к а ц и о н н ы й маршрут от A к B (обозначается A — B ) , н а ч и н а ю щ и й с я сертификатом C A (A)<<X1>>, который CA(A) выдал некоторому другому У Ц , X1, ставше­ му вследствие этого доверенным для A . Маршрут продолжается сертифи­ к а т о м вида X1<<X2>>, содержит п р о м е ж у т о ч н ы е звенья вида X i <<Xi + 1>> и завершается сертификатом Xn<>. Элемент Д и р е к т о р и и , соответствующий удостоверяющему центру, содержит с е р т и ф и к а т ы двух типов: п р я м ы е (сгенерированные д а н н ы м У Ц для других) и обратные ( в ы д а н н ы е д а н н о м у У Ц другими). Если, к р о ­ м е того, удостоверяющие ц е н т р ы образуют иерархию, соответствующую И н ф о р м а ц и о н н о м у Дереву, то с е р т и ф и к а ц и о н н ы й маршрут м о ж н о по¬ строить без п р и в л е ч е н и я д о п о л н и т е л ь н о й и н ф о р м а ц и и , только на осно¬ ве различительных и м е н A и B. Действительно, с п о м о щ ь ю обратных с е р т и ф и к а т о в в ы п о л н я е т с я подъем от CA (A) д о к о р н я поддерева, о б щ е ­ го д л я A и B, а затем, с п о м о щ ь ю п р я м ы х с е р т и ф и к а т о в осуществляется спуск д о C A ( B ) . В рассмотренном в ы ш е процессе A — пользователь сертификата, B — его владелец (субъект), CA(B) — удостоверяющий центр. Все три стороны несут друг перед другом определенные обязательства и, в свою очередь, пользуются предоставляемыми гарантиями. Обязательства и гарантии могут быть зафиксированы в политике сертификата, ссылка на которую хранится в одном и з полей р а с ш и р е н и й . Обычно политика — это о б щ е ­ п р и н я т ы й текст, н о в ней могут присутствовать и формальные условия, допускающие автоматическую проверку. П р и построении и использовании сертификационного маршрута проверяется согласованность политик, присутствующих в кросс-сертифи­ катах. Еще один пример употребления данного поля расширения — нало¬ ж е н и е и проверка ограничений на длину сертификационного маршрута (вообще говоря, чем длиннее маршрут, тем меньше доверия он вызывает). Другая группа д о п о л н и т е л ь н ы х п о л е й с е р т и ф и к а т о в обслуживает способы и срок действия ключей. Для шифрования и цифровой под­ п и с и п р и м е н я ю т р а з н ы е к л ю ч и ; с л е д о в а т е л ь н о , у одного субъекта мо¬ жет быть н е с к о л ь к о п а р к л ю ч е й и , с о о т в е т с т в е н н о , н е с к о л ь к о серти¬ ф и к а т о в . Ч т о б ы выбрать среди н и х н у ж н ы й , н е о б х о д и м о иметь в о з 125

Курс

Информационная безопасность: основные стандарты и спецификации

м о ж н о с т ь в ы я с н и т ь н а з н а ч е н и е п р е д с т а в л е н н о г о в с е р т и ф и к а т е от­ к р ы т о г о ключа. А н а л о г и ч н о , может потребоваться з н а н и е с р о к а год¬ н о с т и с е к р е т н о г о к л ю ч а , посредством к о т о р о г о ф о р м и р у ю т Э Ц П , по¬ с к о л ь к у этот с р о к о б ы ч н о м е н ь ш е , ч е м у открытого к л ю ч а , проверяю¬ щего п о д п и с ь . Значительная часть рекомендаций X.509 посвящена спискам отзыва сертификатов; м ы , однако, не будем останавливаться на этом сугубо тех¬ ническом вопросе.

Каркас с е р т и ф и к а т о в а т р и б у т о в Вероятно, развитие механизма р а с ш и р е н и й натолкнуло авторов р е ­ комендаций X.509 на мысль о том, что в заверенных сертификатах м о ж н о хранить не только открытые ключи, но и произвольные атрибуты субъек¬ тов — держателей (владельцев) сертификатов. Сертификат атрибутов — это структура данных, снабженная ц и ф р о ­ вой подписью соответствующего удостоверяющего центра и связываю­ щая значения некоторых атрибутов с и д е н т и ф и к а ц и о н н о й и н ф о р м а ц и е й держателя сертификата. Вообще говоря, сертификаты атрибутов имеют универсальный ха­ рактер, но в рекомендациях X.509 в н и м а н и е акцентируется на их п р и м е ­ н е н и и в качестве основы инфраструктуры управления привилегиями. У каркасов сертификатов открытых ключей и сертификатов атрибу­ тов немало общего. Это и система удостоверяющих центров, и списки от­ зыва, и многое другое. М ы , однако, сосредоточимся на с п е ц и ф и к е управ­ ления привилегиями. Отметим в первую очередь, что ж и з н е н н ы е ц и к л ы открытых ключей и привилегий устроены по-разному, имеют разную длительность. Приви¬ легии могут делегироваться вспомогательным сущностям на короткие промежутки времени (порядка минуты). Для управления привилегиями используются свои понятия и механизмы, например роли. Следователь­ но, хотя с синтаксической точки зрения для цели управления привилеги­ я м и м о ж н о использовать снабженные соответствующими р а с ш и р е н и я м и сертификаты открытых ключей, идейная и практическая сторона вопро­ са подразумевает разделение каркасов открытых ключей и управления привилегиями, что и сделано в рекомендациях X.509. В контексте управления привилегиями удостоверяющий центр н а ­ зывается центром авторизации. Выделяется главный центр авторизации, который может делегировать другим центрам права наделения привиле­ гиями и их дальнейшего делегирования. На протяжении маршрута делегирования должно действовать пра­ вило доминирования: промежуточный центр авторизации не вправе деле126

Лекция 8

Рекомендации семейства X.500

гировать больше привилегий, чем сам имеет (для каждой привилегии должно быть определено, что значит «не больше»). В о о б щ е говоря, и з в е с т н ы две схемы в ы д е л е н и я и п р о в е р к и при¬ вилегий: • удостоверяющий центр по собственной инициативе наделяет н е к о ­ торую сущность привилегиями, создав сертификат атрибутов и по¬ местив его в Директорию с предоставлением свободного доступа. В дальнейшем верификатору привилегий разрешается использовать этот сертификат при п р и н я т и и р е ш е н и я о предоставлении опреде­ ленного вида доступа. Перечисленные действия могут происходить без ведома и участия субъекта — держателя сертификата; • субъект запрашивает центр авторизации на предмет получения оп¬ ределенной привилегии. П р и положительном р е ш е н и и созданный сертификат атрибутов возвращается держателю и я в н ы м образом предъявляется последним при доступе к з а щ и щ е н н ы м ресурсам. Независимо от принятой схемы выделяются три основных понятия инфраструктуры управления привилегиями: • объект (точнее, метод объекта), к которому осуществляется доступ и который может быть снабжен такими атрибутами, как метка безо¬ пасности. • предъявитель привилегий; • в е р и ф и к а т о р п р и в и л е г и й , п р и н и м а ю щ и й р е ш е н и я (с учетом д е й ­ ствующей п о л и т и к и безопасности и существующего о к р у ж е н и я ) о д о с т а т о ч н о с т и п р е д ъ я в л е н н ы х п р и в и л е г и й для п р е д о с т а в л е н и я доступа. Верификатор привилегий — это какая-либо экранирующая сущ­ ность, логически располагающаяся между в ы з ы в а ю щ и м и вызываемым методами объектов; рекомендации X.509 не налагают ограничений на правила экранирования. Ролевое управление доступом может быть реализовано за счет введе¬ н и я дополнительного уровня косвенности, а также трактовки допусти­ мых ролей как атрибутов субъектов и ассоциирования привилегий с роля¬ м и путем выпуска соответствующих сертификатов. Отметим, что каркас сертификатов атрибутов может быть использо¬ ван не только для управления доступом, но и в контексте обеспечения н е отказуемости. П р и этом предъявитель привилегий выступает в качестве субъекта свидетельства, верификатор привилегий оказывается пользова­ телем свидетельства, а метод объекта трактуется как целевая сущность. М о ж н о видеть, что каркас сертификатов атрибутов обладает доста¬ точной гибкостью и выразительной силой, чтобы служить основой ин¬ фраструктуры управления привилегиями, поддерживать контроль досту¬ па и неотказуемость. 127

Курс

Информационная безопасность: основные стандарты и спецификации

Простая и с и л ь н а я а у т е н т и ф и к а ц и я Каркасы сертификатов открытых ключей и атрибутов — основа це¬ лого ряда сервисов безопасности, в число которых входят аутентифика­ ц и я , контроль целостности, управление доступом. О н и могут использо­ ваться как самой Директорией, так и произвольными приложениями. В этом разделе м ы рассмотрим простую и сильную аутентификации, вклю¬ ч е н н ы е в рекомендации X.509. Простая аутентификация предназначена только для локального и с ­ пользования. Д а н н ы е для нее могут вырабатываться и передаваться тремя способами: • имя и пароль пользователя передаются в открытом виде; • и м я , пароль, случайное число и, возможно, временной штамп (мет­ ка) подвергаются воздействию односторонней ф у н к ц и и , результат которой передается получателю для проверки; • к описанному в ы ш е результату добавляется случайное число и / и л и временной штамп и еще раз применяется односторонняя ф у н к ц и я (возможно, та ж е самая). Рассмотрим более подробно реализацию разновидности 2 простой аутентификации. Пользователь A сначала генерирует токен безопасности PT1: PT1=h1(t1A,r1A,A,passwdA) Токен PT1 используется для создания аутентификационного токена AT1 : AT1=t1A,r1A,A,PT1 (т. е. токен AT1 состоит из четырех компонентов). Пользователь A пере¬ сылает пользователю B токен AT1. Цель B — своими средствами создать аналог токена безопасности PT1 (реконструировать PT1) и сравнить его с оригиналом. О н запрашивает у службы директорий или извлекает само¬ стоятельно локальную к о п и ю пароля p a s s w d A (обозначим ее p a s s w d A B) и реконструирует PT1 : PT1-B=h1(t1A,r1A,A,passwdA-B) Если PT1 и PT1-B совпадут, подлинность пользователя A считается установленной. Сильная аутентификация основана на п р и м е н е н и и асимметричных методов ш и ф р о в а н и я , пригодных для генерации электронной подписи. Подлинность пользователя A считается установленной, если он проде128

Лекция 8

Рекомендации семейства X.500

монстрирует владение секретным ключом, ассоциированным с храня­ щ и м с я в сертификате на имя A открытым ключом. Рекомендации X.509 описывают три возможные процедуры сильной аутентификации: • односторонний обмен. От пользователя A пользователю B передает­ ся один токен. П р и этом подтверждается подлинность A и B, а также то, что токен сгенерирован A, предназначен B, не был изменен и я в ­ ляется «оригинальным» (т. е. не посылается повторно); • двусторонний обмен. Дополнительно от B к A направляется ответ, допускающий проверку того, что он был сгенерирован B, предназна¬ чен A, не был изменен и является «оригинальным»; • трехсторонний обмен. От A к B передается еще один токен. Обеспе­ чивает те же свойства, что и двусторонний, без использования вре¬ менных штампов. Предполагается, что независимо от выбранной процедуры и до в ы ­ п о л н е н и я обменов пользователь A выясняет открытый ключ B и обратный с е р т и ф и к а ц и о н н ы й маршрут B- A. Рассмотрим более подробно процедуру одностороннего обмена. В качестве первого шага пользователь A генерирует «уникальное» число r A , предназначенное для защиты от воспроизведения и подделки аутентификационного токена. После этого A направляет B сообщение следующей структуры: B—A,A{tA,rA,B} где t A — временной штамп, в общем случае представляющий собой пару (время генерации токена и срок его годности). ( Н а п о м н и м , что конструк­ ц и я вида A { I } обозначает и н ф о р м а ц и ю I , подписанную открытым клю¬ ч о м A.) Получив это сообщение, B предпринимает следующие действия: • по обратному сертификационному пути B — A выясняет открытый ключ A ( A p ) , попутно проверяя статус сертификата A; • проверяет подпись и, тем самым, целостность присланной инфор¬ мации; • проверяет, что в качестве получателя указан B; • удостоверяется, что временной штамп «свежий», а число r A ранее не использовалось. Двусторонний и трехсторонний обмены являются довольно очевид¬ н ы м развитием одностороннего. Н а этом м ы завершаем р а с с м о т р е н и е р е к о м е н д а ц и й семейства X.500.

129

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 9. С п е ц и ф и к а ц и и I n t e r n e t - с о о б щ е с т в а IPsec Данные спецификации имеют фундаментальное значение, описывая полный набор средств обеспечения конфиденциальности и целостности на сетевом уровне.

Ключевые слова: управление доступом, целостность в н е соединения, аутентификация источника данных, воспроизведение, конфиденци¬ альность, анализ трафика, протокол аутентифицирующего заголов¬ ка, протокол инкапсулирующей защиты содержимого, управление криптографическими ключами, домен интерпретации, контекст бе¬ зопасности, транспортный режим, туннельный режим, управляю¬ щ и й контекст, протокольный контекст, доверенный канал, однора¬ зовый номер, нелегальный посредник, атака на доступность, н а в я ­ зывание интенсивных вычислений, идентифицирующая цепочка, политика безопасности, база данных политики безопасности, база данных протокольных контекстов безопасности, селектор, индекс параметров безопасности, аутентификационные данные, и м и т о в ставка, инкапсулирующая оболочка, виртуальные частные сети, мо¬ бильные системы, защита прикладных потоков данных.

Архитектура средств безопасности IP -уровня В курсе «Основы и н ф о р м а ц и о н н о й безопасности» [3] указывалось, что практически все механизмы сетевой безопасности могут быть реали¬ зованы на третьем уровне эталонной модели ISO/OSI. Более того, IP-уро­ вень м о ж н о считать оптимальным для размещения защитных средств, п о ­ скольку п р и этом достигается удачный компромисс между з а щ и щ е н н о с ­ тью, эффективностью ф у н к ц и о н и р о в а н и я и прозрачностью для прило¬ жений. Стандартизованными механизмами IP-безопасности могут (и долж­ ны) пользоваться протоколы более высоких уровней и, в частности, уп­ р а в л я ю щ и е протоколы, протоколы конфигурирования и маршрутизации. Средства безопасности для IP описываются семейством с п е ц и ф и к а ­ ц и й IPsec, разработанных рабочей группой IP Security. Протоколы IPsec обеспечивают управление доступом, целостность вне соединения, аутентификацию источника данных, защиту от воспроиз­ ведения, конфиденциальность и частичную защиту от анализа трафика. 130

Лекция 9

Спецификации Internet-сообщества IPsec

Архитектура средств безопасности для IP-уровня специфицирована в документе [69]. Ее основные составляющие представлены на рис. 9.1. Это прежде всего протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка — Authentication Header, A H ) и к о н ф и д е н ­ циальности (протокол инкапсулирующей защиты содержимого — Encapsulating Security Payload, E S P ) , а также механизмы управления к р и п ­ тографическими ключами. Н а более н и з к о м архитектурном уровне рас­ полагаются конкретные алгоритмы ш и ф р о в а н и я , контроля целостности и аутентичности. Н а к о н е ц , роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, D O I ) , я в л я ю щ и й с я , по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах и т.п. Протокол инкапсулирующей защиты ы содержимого (ESP)

Протокол управления уп ключами

Т Алгоритмы шифрования

Алгоритмы аутентификации

J

L Домен интерпретации

Рис. 9.1. Основные элементы архитектуры средств безопасности IP-уровня. Деление на уровни важно для всех аспектов и н ф о р м а ц и о н н ы х тех­ нологий. Там ж е , где участвует еще и криптография, важность возрастает вдвойне, поскольку приходится считаться не только с чисто технически­ м и факторами, но и с особенностями законодательства различных стран, с ограничениями на экспорт и / и л и импорт криптосредств (см. курс «Ос­ н о в ы и н ф о р м а ц и о н н о й безопасности» [3]). Протоколы обеспечения аутентичности и конфиденциальности в IPsec не зависят от конкретных криптографических алгоритмов. (Более того, само деление на аутентичность и конфиденциальность предоставля­ ет и разработчикам, и пользователям дополнительную степень свободы в ситуации, когда к криптографическим относят только ш и ф р о в а л ь н ы е средства.) В каждой стране могут применяться свои алгоритмы, соответ131

Курс

Информационная безопасность: основные стандарты и спецификации

ствующие н а ц и о н а л ь н ы м стандартам, н о для этого, к а к м и н и м у м , нужно позаботиться об их регистрации в домене интерпретации. Алгоритмическая независимость протоколов, к сожалению, имеет и оборотную сторону, состоящую в необходимости предварительного с о ­ гласования набора применяемых алгоритмов и их параметров, поддержи­ ваемых о б щ а ю щ и м и с я сторонами. И н ы м и словами, стороны д о л ж н ы вы¬ работать о б щ и й контекст безопасности (Security Association, SA) и затем использовать такие его элементы, к а к алгоритмы и их ключи. За форми¬ рование контекстов безопасности в IPsec отвечает особое семейство про¬ токолов, которое будет рассмотрено в последующих разделах. Протоколы обеспечения аутентичности и конфиденциальности м о ­ гут применяться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и, быть может, некоторые поля заголовков. К а к правило, транспортный режим используется хоста­ ми. В туннельном режиме защищается весь пакет — о н инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах (в роли которых могут выступать маршру­ тизаторы и л и межсетевые э к р а н ы , см. курс «Основы и н ф о р м а ц и о н н о й безопасности» [3]). В последующих разделах м ы подробно рассмотрим основные эле¬ менты IPsec.

Контексты безопасности и управление ключами Ф о р м и р о в а н и е контекстов безопасности в IPsec разделено на две фазы. Сначала создается управляющий контекст, назначение которого — предоставить доверенный канал (в терминологии «Общих критериев», см., например, [2]), т. е. аутентифицированный, з а щ и щ е н н ы й канал для выработки (в рамках второй фазы) протокольных контекстов и, в частно¬ сти, для ф о р м и р о в а н и я криптографических ключей, используемых про¬ токолами A H и ESP. В п р и н ц и п е , для ф у н к ц и о н и р о в а н и я механизмов IPsec необходимы только протокольные контексты; управляющий играет вспомогательную роль. Более того, я в н о е выделение двух ф а з утяжеляет и усложняет фор¬ мирование ключей, если рассматривать последнее к а к однократное дей¬ ствие. Тем н е менее, из архитектурных соображений управляющие кон¬ тексты н е только могут, н о и должны существовать, поскольку обслужи¬ вают все протокольные уровни стека T C P / I P , концентрируя в одном мес­ те необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны н е имеют общих секретов (общих ключей) и н е уверены в аутентичности друг друга. Если с самого начала н е 132

Лекция 9

Спецификации Internet-сообщества IPsec

создать доверенный канал, то для выполнения каждого управляющего действия с ключами (их м о д и ф и к а ц и я , выдача диагностических сообще­ н и й и т.п.) в каждом протоколе ( A H , ESP, T L S и т.д.) этот канал придется формировать заново. Общие вопросы формирования контекстов безопасности и управле­ н и я ключами освещаются в спецификации [76] — «Контексты безопасно­ сти и управление ключами в Internet» (Internet Security Association and Key Management Protocol, I S A K M P ) . Здесь вводятся две фазы выработки п р о ­ токольных ключей, определяются виды управляющих и н ф о р м а ц и о н н ы х обменов и используемые форматы заголовков и данных. И н ы м и словами, в [76] строится протокольно-независимый каркас. Существует несколько способов ф о р м и р о в а н и я управляющего к о н ­ текста. О н и различаются двумя показателями: • используемым механизмом выработки общего секретного ключа; • степенью защиты идентификаторов общающихся сторон. В простейшем случае секретные ключи задаются заранее (ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, н о о н н е является масштабируемым. Последнее свойст¬ во может быть обеспечено п р и автоматической выработке и распределе¬ н и и секретных ключей в рамках протоколов, основанных на алгоритме Д и ф ф и - Х е л м а н а (см. [3]). П р и м е р тому — «Протокол для обмена ключа­ м и в Internet « (The Internet Key Exchange, I K E , [52]). П р и формировании управляющего контекста идентификаторы о б ­ щающихся сторон (например, IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку I S A K M P предусматривает ф у н к ц и о н и ­ рование в режиме клиент/сервер (т. е. ISAKMP-сервер может ф о р м и р о ­ вать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети. Последовательность передаваемых сообщений, позволяющих с ф о р ­ мировать управляющий контекст и обеспечивающих защиту и д е н т и ф и ­ каторов, выглядит следующим образом (см. рис. 9.2). В первом сообщении (1) инициатор направляет предложения по на¬ бору защитных алгоритмов и конкретных механизмов их реализации. Предложения упорядочиваются по степени предпочтительности (для инициатора). В ответном сообщении (2) партнер информирует о сделан¬ н о м выборе — какие алгоритмы и механизмы его устраивают. Д л я каждо­ го класса защитных средств (генерация ключей, аутентификация, ш и ф ­ рование) выбирается только один элемент. В сообщениях (3) и (4) и н и ц и а т о р и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа (мы опускаем детали, с п е ц и ф и ч н ы е для алгоритма Д и ф ф и - Х е л м а -

133

Курс

Информационная безопасность: основные стандарты и спецификации

Инициатор (1)

Партнер

Заявка на контекст (предлагаемые алгоритмы и их параметры)

(2)

(3)

П р и н и м а е м ы е алгоритмы и параметры Ключевой материал инициатора, одноразовый номер инициатора Ключевой материал партнера, одноразовый номер партнера

(4)

(5)

З а ш и ф р о в а н н о е сообщение, содержащее идентификатор инициатора и подписанное ~*~ его секретным ключом З а ш и ф р о в а н н о е сообщение, содержащее идентификатор партнера и подписанное его секретным ключом

(6)

Рис. 9.2. Ф о р м и р о в а н и е управляющего контекста. на). Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений. Посредством сообщений (5) и (6) происходит обмен идентификаци¬ о н н о й и н ф о р м а ц и е й , подписанной (с целью аутентификации) секретным ключом отправителя и з а ш и ф р о в а н н о й выработанным на предыдущих шагах о б щ и м секретным ключом. Для аутентификации предполагается использование сертификатов открытых ключей. Отметим, что в число подписываемых данных входят одноразовые номера. В представленном виде протокол ф о р м и р о в а н и я управляющего кон¬ текста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на д о ­ ступность, для которых характерно прежде всего навязывание интенсив¬ ных вычислений, присущих криптографии с открытым ключом, приме¬ няются так называемые и д е н т и ф и ц и р у ю щ и е цепочки (cookies). Эти це¬ почки, формируемые инициатором и его партнером с использованием те¬ кущего времени (для защиты от воспроизведения), на самом деле присут134

Лекция 9

Спецификации Internet-сообщества IPsec

ствуют во всех I S A K M P - с о о б щ е н и я х и в совокупности идентифицируют управляющий контекст (в первом сообщении, по п о н я т н ы м п р и ч и н а м , фигурирует только цепочка инициатора). Согласно с п е ц и ф и к а ц и я м [76], заголовок I S A K M P - с о о б щ е н и я имеет вид, изображенный на рис. 9.3. Е с ­ ли злоумышленник пытается «завалить» кого-либо запросами на созда­ н и е управляющего контекста, подделывая п р и этом свой IP-адрес, то в сообщении (3) (см. в ы ш е рис. 9.2) о н н е сможет предъявить идентифици¬ рующую цепочку партнера, поэтому до выработки общего секретного ключа и, тем более, электронной подписи и полномасштабной проверки аутентичности дело попросту н е дойдет.

'

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 И д е н т и ф и ц и р у ю щ а я цепочка инициатора И д е н т и ф и ц и р у ю щ а я цепочка партнера След. заголовок Н о м е р версии Тип обмена Флаги Идентификатор сообщения Длина

'

Рис. 9.3. Формат заголовка I S A K M P - с о о б щ е н и я . Управляющие контексты являются двунаправленными в том с м ы с ­ ле, что любая из общающихся сторон может инициировать с их п о м о щ ь ю выработку новых протокольных контекстов или и н ы е действия. Д л я п е ­ редачи I S A K M P - с о о б щ е н и й используется любой протокол, однако в ка­ честве стандартного принят U D P с номером порта 500.

Протокольные контексты и политика безопасности Системы, реализующие IPsec, должны поддерживать две базы данных: • базу данных политики безопасности (Security Policy Database, S P D ) ; • базу д а н н ы х п р о т о к о л ь н ы х к о н т е к с т о в б е з о п а с н о с т и (Security Association Database, S A D ) . Все IP-пакеты (входящие и исходящие) сопоставляются с упорядо¬ ч е н н ы м набором правил политики безопасности. П р и сопоставлении ис¬ пользуется фигурирующий в каждом правиле селектор — совокупность ана­ лизируемых полей сетевого уровня и более высоких протокольных уров­ ней. Первое подходящее правило определяет дальнейшую судьбу пакета: • пакет может быть ликвидирован; • пакет может быть обработан без участия средств IPsec; 135

Курс

Информационная безопасность: основные стандарты и спецификации

• пакет должен быть обработан средствами IPsec с учетом набора про¬ токольных контекстов, ассоциированных с правилом. Таким образом, системы, реализующие IPsec, функционируют к а к межсетевые э к р а н ы , фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности. Далее мы детально рассмотрим контексты и политику безопасности, а также порядок обработки сетевых пакетов. П р о т о к о л ь н ы й контекст безопасности в IPsec — это однонаправ¬ л е н н о е «соединение» (от источника к получателю), предоставляющее об¬ служиваемым потокам данных набор з а щ и т н ы х сервисов в рамках како¬ го-то одного протокола ( A H или E S P ) . В случае симметричного в з а и м о ­ действия партнерам придется организовать два контекста (по одному в каждом направлении). Если используются и A H , и ESP, потребуется че¬ тыре контекста. Элементы базы данных протокольных контекстов содержат следую¬ щ и е поля (в каждом конкретном случае некоторые значения полей будут пустыми): • используемый в протоколе A H алгоритм аутентификации, его ключи и т.п.; • используемый в протоколе E S P алгоритм ш и ф р о в а н и я , его ключи, начальный вектор и т.п.; • используемый в протоколе E S P алгоритм аутентификации, его клю¬ чи и т.п.; • время ж и з н и контекста; • режим работы IPsec: транспортный или туннельный; • максимальный размер пакетов; • группа полей (счетчик, о к н о , флаги) для защиты от воспроизведения пакетов. Пользователями протокольных контекстов, как правило, являют­ ся п р и к л а д н ы е п р о ц е с с ы . В о о б щ е г о в о р я , между двумя узлами сети может существовать п р о и з в о л ь н о е ч и с л о п р о т о к о л ь н ы х к о н т е к с т о в , т а к к а к ч и с л о п р и л о ж е н и й в узлах п р о и з в о л ь н о . О т м е т и м , ч т о в каче¬ стве пользователей у п р а в л я ю щ и х к о н т е к с т о в о б ы ч н о выступают узлы сети ( п о с к о л ь к у в этих к о н т е к с т а х ж е л а т е л ь н о сосредоточить о б щ у ю ф у н к ц и о н а л ь н о с т ь , необходимую с е р в и с а м б е з о п а с н о с т и всех прото¬ к о л ь н ы х у р о в н е й э т а л о н н о й модели д л я у п р а в л е н и я криптографичес¬ кими ключами). Управляющие контексты — двусторонние, т. е. любой из партнеров может инициировать н о в ы й ключевой обмен. Пара узлов может одновре¬ м е н н о поддерживать несколько активных управляющих контекстов, если имеются приложения с существенно р а з н ы м и криптографическими тре­ бованиями. Н а п р и м е р , допустима выработка части ключей на основе 136

Лекция 9

Спецификации Internet-сообщества IPsec

предварительно распределенного материала, в то время к а к другая часть порождается п о алгоритму Д и ф ф и - Х е л м а н а . П р о т о к о л ь н ы й к о н т е к с т д л я IPsec и д е н т и ф и ц и р у е т с я ц е л е в ы м I P адресом, п р о т о к о л о м ( A H и л и E S P ) , а т а к ж е д о п о л н и т е л ь н о й в е л и ч и ­ н о й — и н д е к с о м п а р а м е т р о в безопасности (Security Parameter Index, SPI). П о с л е д н я я в е л и ч и н а необходима, п о с к о л ь к у могут существовать несколько контекстов с одинаковыми IP-адресами и протоколами. Да­ лее будет п о к а з а н о , к а к используются и н д е к с ы SPI п р и обработке вхо­ д я щ и х пакетов. IPsec обязывает поддерживать ручное и автоматическое управле¬ н и е к о н т е к с т а м и безопасности и к р и п т о г р а ф и ч е с к и м и к л ю ч а м и . В п е р в о м случае все с и с т е м ы заранее снабжаются к л ю ч е в ы м материалом и и н ы м и д а н н ы м и , н е о б х о д и м ы м и д л я з а щ и щ е н н о г о взаимодействия с другими системами. Во втором — материал и д а н н ы е вырабатываются д и н а м и ч е с к и , на о с н о в е определенного протокола — I K E [52], п о д ­ д е р ж к а которого обязательна. Протокольный контекст создается на базе управляющего с исполь­ зованием ключевого материала и средств аутентификации и ш и ф р о в а н и я последнего. В простейшем случае, когда протокольные ключи генериру¬ ются на основе существующих, последовательность передаваемых сооб¬ щ е н и й выгладит так, к а к показано на рис. 9.4.

Инициатор

Партнер

З а ш и ф р о в а н н ы е результат х э ш - ф у н к ц и и , заявка на контекст (предлагаемые (1) алгоритмы и их параметры), одноразовый номер инициатора Результат х э ш - ф у н к ц и и , п р и н и м а е м ы е алгоритмы и параметры, одноразовый номер партнера (все в з а ш и ф р о в а н н о м виде)

(2)

З а ш и ф р о в а н н ы й результат х э ш - ф у н к ц и и , среди (3) аргументов которой — оба одноразовых номера

Рис. 9.4. Ф о р м и р о в а н и е протокольного контекста. 137

Курс

Информационная безопасность: основные стандарты и спецификации

Когда вырабатывался управляющий контекст, для него было создано три вида ключей: • S K E Y I D d — ключевой материал, используемый для генерации про¬ токольных ключей; • S K E Y I D a — ключевой материал для аутентификации; • S K E Y I D e — ключевой материал для ш и ф р о в а н и я . Все перечисленные виды ключей задействованы в обмене, показан¬ н о м на р и с . 9.4. К л ю ч о м S K E Y I D e ш и ф р у ю т с я с о о б щ е н и я . К л ю ч S K E Y I D a служит аргументом х э ш - ф у н к ц и й и тем самым аутентифицирует сообщения. Н а к о н е ц , протокольные ключи — результат п р и м е н е н и я псевдослучайной (хэш) ф у н к ц и и к S K E Y I D d с дополнительными пара­ метрами, в число которых входят одноразовые номера инициатора и партнера. В результате создание протокольного контекста оказывается аутентифицированным, з а щ и щ е н н ы м от несанкционированного озна¬ комления, от воспроизведения сообщений и от перехвата соединения. С о о б щ е н и я (1) и (2) могут нести дополнительную нагрузку, н а п р и ­ мер, д а н н ы е для выработки «совсем новых» секретных ключей и л и и д е н ­ т и ф и к а т о р ы клиентов, от и м е н и которых I S A K M P - с е р в е р ы формируют протокольный контекст. В соответствии с протоколом I K E , за один об¬ м е н (состоящий и з трех п о к а з а н н ы х на рис. 9.4 с о о б щ е н и й ) формирует­ ся два однонаправленных контекста — по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SPI), п о м о г а ю щ и й находить контекст д л я обработки п р и н и м а е м ы х па¬ кетов IPsec. Строго говоря, протокольные контексты играют вспомогательную роль, будучи л и ш ь средством проведения в ж и з н ь политики безопаснос­ ти; она должна быть задана для каждого сетевого интерфейса с задейство­ в а н н ы м и средствами IPsec и для каждого направления потоков данных (входящие/исходящие). Согласно с п е ц и ф и к а ц и я м IPsec [69], политика рассчитывается на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных S P D , так ж е , к а к и средства администрирования базы правил межсетевого экрана, однако этот аспект н е входит в число стандартизуемых. С внешней точки зрения, база данных политики безопасности (SPD) представляет собой упорядоченный набор правил. Каждое правило зада­ ется к а к пара: • совокупность селекторов; • совокупность протокольных контекстов безопасности. Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, о н о должно содержать достаточную и н ф о р м а ц и ю для его (контекста) д и н а м и 138

Лекция 9

Спецификации Internet-сообщества IPsec

ческого создания. Очевидно, в этом случае требуется поддержка автомати­ ческого управления контекстами и ключами. В принципе, ф у н к ц и о н и р о ­ вание системы может начинаться с задания базы S P D при пустой базе к о н ­ текстов (SAD); последняя будет наполняться по мере необходимости. Дифференцированность политики безопасности определяется селек¬ торами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селек¬ торах фигурируют только IP-адреса; с другой стороны, набор может быть своим для каждого приложения, если анализируются номера T C P - и U D P портов. Аналогично, два защитных шлюза способны организовать единый туннель для всех обслуживаемых хостов или ж е расщепить его (путем орга¬ низации разных контекстов) по парам хостов или даже приложений. Все реализации IPsec д о л ж н ы поддерживать селекцию следующих элементов: • исходный и целевой IP-адреса (адреса могут быть индивидуальными и групповыми, в правилах допускаются диапазоны адресов и мета¬ символы «любой»; • и м я пользователя или узла в формате D N S или X.500; • транспортный протокол; • номера исходного и целевого портов (здесь также могут использо¬ ваться диапазоны и метасимволы). Обработка исходящего и входящего трафика, согласно [69], н е являет­ ся симметричной. Для исходящих пакетов просматривается база S P D , нахо­ дится подходящее правило, извлекаются ассоциированные с н и м прото­ кольные контексты и применяются соответствующие механизмы безопас­ ности. Во входящих пакетах для каждого защитного протокола уже простав­ лено значение SPI, однозначно определяющее контекст. Просмотр базы S P D в таком случае не требуется; можно считать, что политика безопаснос¬ ти учитывалась при формировании соответствующего контекста. (Практи¬ чески это означает, что ISAKMP-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SPD.) Отмеченная асимметрия, на н а ш взгляд, отражает определенную не¬ завершенность архитектуры IPsec. В более р а н н е м , п о сравнению с [69], документе R F C 1825 понятия базы данных политики безопасности и се¬ лекторов отсутствовали. В новой редакции сделано полшага вперед — с п е ц и ф и ц и р о в а н просмотр базы S P D к а к обязательный для каждого и с ­ ходящего пакета, н о н е изменена обработка входящих пакетов. К о н е ч н о , извлечение контекста п о индексу SPI э ф ф е к т и в н е е , ч е м просмотр набора правил, н о при таком подходе, по меньшей мере, затрудняется оператив­ н о е и з м е н е н и е политики безопасности. Ч т о касается эффективности просмотра правил, то ее м о ж н о повысить методами к э ш и р о в а н и я , широ¬ ко используемыми при реализации IP. 139

Курс

Информационная безопасность: основные стандарты и спецификации

Возможно, еще более серьезным недостатком является невозмож­ ность обобщения предложенных процедур ф о р м и р о в а н и я контекстов (управляющих и протокольных) на многоадресный случай. В текущих с п е ц и ф и к а ц и я х IPsec смешиваются две разные вещи — область действия контекста (сейчас это односторонний или двусторонний поток данных) и способ его идентификации (по индексу SPI или паре идентифицирующих цепочек). Получается, что способ идентификации (именования) навязы­ вает трактовку области действия, что представляется неверным. На н а ш взгляд, вопросы именования могут решаться локально, а область дейст­ вия контекста потенциально должна распространяться на произвольное число партнеров.

Обеспечение аутентичности IP-пакетов Протокол аутентифицирующего заголовка (Authentication Header, A H , см. [67]) служит в IPsec для обеспечения целостности пакетов и ау­ т е н т и ф и к а ц и и источника данных, а также для защиты от воспроизведе­ н и я ранее посланных пакетов. A H защищает д а н н ы е протоколов более высоких уровней и те поля IP-заголовков, которые не меняются на м а р ­ шруте доставки или меняются предсказуемым образом. (Отметим, что число «непредсказуемых» полей невелико — это Prio. (Traffic Class), Flow Label и Hop Limit. Предсказуемо меняется целевой адрес при наличии д о ­ полнительного заголовка исходящей маршрутизации.) Формат заголовка A H показан на рис. 9.5. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 След. заголовок Д л и н а загол. A H Резерв Индекс параметров безопасности (SPI) П о р я д к о в ы й номер . Аутентификационные д а н н ы е (поле переменной д л и н ы ) . .

.

.

.

J

Рис. 9.5. Формат заголовка A H . П о я с н и м смысл полей, с п е ц и ф и ч н ы х для A H : • индекс параметров безопасности (SPI) — 32-битное значение, в ы б и ­ раемое получателем пакетов с AH-заголовками в качестве иденти¬ фикатора протокольного контекста (см. в ы ш е раздел «Протоколь¬ ные контексты и политика безопасности»); • порядковый номер — беззнаковое 32-битное целое, наращиваемое от пакета к пакету. Отправитель обязан поддерживать этот счетчик, в то 140

Лекция 9

Спецификации Internet-сообщества IPsec

время к а к получатель может (но не обязан) использовать его для за­ щ и т ы от воспроизведения. П р и ф о р м и р о в а н и и протокольного кон¬ текста обе взаимодействующие стороны делают свои счетчики нуле¬ выми, а потом согласованным образом увеличивают их. Когда зна¬ чение порядкового номера становится максимально возможным, должен быть сформирован н о в ы й контекст безопасности; • аутентификационные д а н н ы е — поле переменной д л и н ы , содержа¬ щ е е и м и т о в с т а в к у ( к р и п т о г р а ф и ч е с к у ю к о н т р о л ь н у ю сумму, Integrity Check Value, ICV) пакета; способ его вычисления определя­ ется алгоритмом аутентификации. Для вычисления аутентифицированных имитовставок могут п р и м е ­ няться различные алгоритмы. С п е ц и ф и к а ц и я м и [67] предписывается обязательная поддержка двух алгоритмов, основанных на п р и м е н е н и и х э ш - ф у н к ц и й с секретными ключами: • H M A C - M D 5 (Hashed Message Authentication Code — Message Digest version 5, см. [74]); • H M A C - S H A - 1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1, см. [75]). М ы не будем описывать процесс вычисления х э ш - ф у н к ц и й , л и ш ь еще раз обратим в н и м а н и е на необходимость приведения национальных криптографических стандартов, нормативно-правовой базы и практичес­ ких работ в соответствие со сложившейся международной практикой.

Обеспечение конфиденциальности сетевого трафика Протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP, см. [68]) предоставляет три вида сервисов безопас¬ ности: • обеспечение конфиденциальности ( ш и ф р о в а н и е содержимого IPпакетов, а также частичная защита от анализа трафика путем п р и м е ­ н е н и я туннельного режима); • обеспечение целостности IP-пакетов и аутентификации источника данных; • обеспечение защиты от воспроизведения IP-пакетов. М о ж н о видеть, что функциональность E S P шире, чем у A H (добавля­ ется шифрование); взаимодействие этих протоколов м ы подробнее рас­ смотрим позже. Здесь же отметим, что E S P не обязательно предоставляет все сервисы, но либо конфиденциальность, либо аутентификация должны быть задействованы. Формат заголовка E S P выглядит несколько необыч­ но (см. рис. 9.6). П р и ч и н а в том, что это не столько заголовок, сколько обертка (инкапсулирующая оболочка) для зашифрованного содержимого. 141

Курс

Информационная безопасность: основные стандарты и спецификации

1 2 3 0 1234 56 78 90 123 456 78 90 123 45 678 90 1 i

Индекс параметров безопасности (SPI)

Аутентификационная часть

Порядковый номер . . .

.

Заполнитель (0-255 байт)

\

Д л и н а заполнит

.

.

.

..

Защищенное содержимое (поле переменной д л и н ы

)

и

Зашифро¬ ванная часть

След. заголовок

Аутентификационные д а н н ы е

\

(поле переменной длины)

.

.

.

Рис. 9.6. Формат заголовка ESP. Например, ссылку на следующий заголовок нельзя выносить в начало, в незашифрованную часть, так как она лишится конфиденциальности. Поля «Индекс параметров безопасности (SPI)», «Порядковый но¬ мер» и «Аутентификационные данные» (последнее присутствует только при включенной аутентификации) имеют тот ж е смысл, что и для A H . Правда, E S P аутентифицирует л и ш ь зашифрованную часть пакета (плюс два первых поля заголовка). П р и м е н е н и е протокола E S P к исходящим пакетам м о ж н о представ­ лять себе следующим образом. Назовем остатком пакета ту его часть, к о ­ торая помещается после предполагаемого места вставки заголовка ESP. П р и этом не важно, какой режим используется — транспортный или тун­ нельный. Ш а г и протокола таковы: • остаток пакета копируется в буфер; • к остатку приписываются д о п о л н я ю щ и е байты, их число и номер (тип) первого заголовка остатка, с тем чтобы номер был прижат к границе 32-битного слова, а размер буфера удовлетворял требовани­ я м алгоритма ш и ф р о в а н и я ; • текущее содержимое буфера шифруется; • в н а ч а л о буфера п р и п и с ы в а ю т с я п о л я « И н д е к с п а р а м е т р о в б е з о ­ п а с н о с т и (SPI)» и « П о р я д к о в ы й номер» с с о о т в е т с т в у ю щ и м и значениями; • пополненное содержимое буфера аутентифицируется, в его конец помещается поле «Аутентификационные данные»; • в новый пакет переписываются начальные заголовки старого пакета и конечное содержимое буфера. 142

Лекция 9

Спецификации Internet-сообщества IPsec

Таким образом, если в E S P в к л ю ч е н ы и ш и ф р о в а н и е , и аутентифи­ к а ц и я , то аутентифицируется з а ш и ф р о в а н н ы й пакет. Д л я входящих п а ­ кетов действия в ы п о л н я ю т с я в обратном п о р я д к е , т. е. сначала п р о и з в о ­ дится аутентификация. Это позволяет н е тратить ресурсы н а расшиф¬ ровку поддельных пакетов, что в к а к о й - т о степени з а щ и щ а е т от атак на доступность. Два з а щ и т н ы х протокола — A H и E S P — могут к о м б и н и р о в а т ь с я р а з н ы м и способами. П р и выборе транспортного р е ж и м а A H должен ис¬ пользоваться после E S P (аналогично тому, к а к в рамках E S P аутентифи­ к а ц и я идет следом за ш и ф р о в а н и е м ) . В туннельном р е ж и м е A H и E S P п р и м е н я ю т с я , строго говоря, к р а з н ы м ( в л о ж е н н ы м ) пакетам, ч и с л о д о ­ пустимых к о м б и н а ц и й здесь больше (хотя бы потому, что возможна м н о г о к р а т н а я вложенность туннелей с р а з л и ч н ы м и н а ч а л ь н ы м и и / и л и к о н е ч н ы м и точками). Совокупность механизмов, предлагаемая в рамках IPsec, является весьма м о щ н о й и гибкой. IPsec — это основа, на которой может строить¬ ся реализация виртуальных частных сетей, обеспечиваться з а щ и щ е н н о е взаимодействие мобильных систем с корпоративной сетью, защита при¬ кладных потоков данных и т.п.

143

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 10. С п е ц и ф и к а ц и я I n t e r n e t - с о о б щ е с т в а TLS Спецификация TLS развивает и уточняет популярный протокол Secure Socket Layer (SSL), используемый в большом числе программных продуктов. Она может служить основой обеспечения безопасности протоколов приклад­ ного уровня.

Ключевые слова: протокол безопасности транспортного уровня, п р о ­ токол передачи записей, протокол установления соединений, архи¬ тектура клиент/сервер, конфиденциальность, целостность, интероперабельность, цифровая подпись, потоковое ш и ф р о в а н и е , блочное ш и ф р о в а н и е , ш и ф р о в а н и е открытым ключом, к э ш и р о в а н и е , прото¬ кол о п о в е щ е н и я , протокол смены параметров, протокол передачи прикладных данных, аутентификационный код сообщения, началь­ н ы й вектор, сеанс, приветственное сообщение, возобновляемый се¬ анс, а н о н и м н ы й сеанс, предварительный мастер-секрет, предупреж¬ дение, сообщение об о ш и б к е , уведомление о завершении сеанса, уникальный идентификатор ресурсов.

О с н о в н ы е и д е и и п о н я т и я п р о т о к о л а TLS М ы приступаем к рассмотрению протокола безопасности транс¬ портного уровня (Transport Layer Security, T L S ) (см. [48]), в котором полу­ чили дальнейшее развитие п о н я т и я , и з л о ж е н н ы е в версии 3.0 популярно­ го протокола Secure Socket Layer (SSL) корпорации Netscape. Посредством протокола T L S приложения, построенные в архитекту­ ре клиент/сервер, могут защититься от пассивного и активного прослу­ ш и в а н и я сети и подделки сообщений. T L S имеет двухуровневую организацию. Н а первом (нижнем) уров¬ не, опирающемся н а надежный транспортный сервис, каковой предо­ ставляет, например, TCP, располагается протокол передачи записей (TLS Record Protocol), н а втором (верхнем) — протокол установления соедине­ н и й (TLS Handshake Protocol). Строго говоря, протокол безопасности транспортного уровня располагается между транспортным и прикладным уровнями. Его м о ж н о отнести к сеансовому уровню эталонной модели ISO/OSI. П р о т о к о л передачи з а п и с е й о б е с п е ч и в а е т к о н ф и д е н ц и а л ь н о с т ь и целостность передаваемых данных. Обеспечение конфиденциальнос­ ти д о с т и г а е т с я путем п р и м е н е н и я м е т о д о в с и м м е т р и ч н о г о ш и ф р о в а ­ н и я (см. [3]), п р и ч е м д л я каждого с о е д и н е н и я генерируется с в о й с е к ­ ретный ключ. Контроль целостности (и, в частности, аутентичности) 144

Лекция 10

Спецификация Internet-сообщества TLS

с о о б щ е н и й о с н о в а н на и с п о л ь з о в а н и и х э ш - ф у н к ц и й с с е к р е т н ы м и ключами. Протокол установления соединений позволяет серверу и клиенту провести взаимную аутентификацию, согласованно выбрать алгоритм ш и ф р о в а н и я и криптографические ключи перед тем, как прикладной протокол начнет передачу данных. Для аутентификации сторон п р и м е н я ­ ются методы криптографии с открытым ключом (см. [3]), при выработке совместных секретов обеспечивается к о н ф и д е н ц и а л ь н о с т ь и целост¬ ность, в том числе защита от нелегального посредника. В соответствии с уровневой организацией сетевых протоколов, T L S не зависит от протоколов прикладного уровня. К р о м е того, он обеспечи¬ вает интероперабельность использующих его независимо написанных приложений или компонентов приложений; последние могут успешно согласовывать криптографические параметры в д и н а м и к е , не располагая и н ф о р м а ц и е й о кодах друг друга. П о о т н о ш е н и ю к алгоритмам симметричного и асимметричного ши¬ фрования T L S представляет собой алгоритмически независимый, р а с ш и ­ р я е м ы й каркас, допускающий добавление новых криптографических ме¬ тодов и их реализаций. В с п е ц и ф и к а ц и я х T L S фигурируют четыре криптографические опе­ рации: цифровая подпись, потоковое ш и ф р о в а н и е , блочное ш и ф р о в а н и е и ш и ф р о в а н и е открытым ключом. Все о н и , особенно асимметричное ши¬ фрование, способны поглотить много процессорного времени. Для р е ш е ­ н и я этой проблемы определенное в н и м а н и е уделено вопросам э ф ф е к т и в ­ ности, м и н и м и з а ц и и нагрузки на процессор и сеть: предлагаемая схема к э ш и р о в а н и я в рамках сеанса уменьшает число соединений, устанавлива­ емых «с нуля». В последующих разделах подробно рассматриваются составляющие протокола T L S и их использование.

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

Курс

Информационная безопасность: основные стандарты и спецификации

С п е ц и ф и к а ц и я м и T L S предусмотрено четыре вышележащих клиен¬ та протокола передачи записей: • протокол установления соединений; • протокол о п о в е щ е н и я (alert protocol); • протокол смены параметров шифрования (change cipher spec protocol); • протокол передачи прикладных данных (application data protocol). Ф у н к ц и и этих протоколов будут рассмотрены в следующем разделе. С точки зрения протокола передачи записей, каждое соединение является двунаправленным и может находиться в одном и з двух состоя­ н и й : обработки (т. е. быть текущим) и о ж и д а н и я (быть отложенным). К р о м е того, состояние соединения характеризуется п р и м е н я е м ы м и а л ­ горитмами (сжатия, ш и ф р о в а н и я , вычисления имитовставки) и их пара¬ метрами (секретными ключами и начальными векторами). Н а к о н е ц , каждому соединению соответствуют четыре экземпляра состояния: п о два н а клиентской и серверной сторонах (любая и з них может передавать и п р и н и м а т ь данные). Перечислим и другие элементы состояния соединения: • мастер-секрет — 48-байтное значение, разделяемое партнерами по о б щ е н и ю и служащее для выработки других общих секретов (ключей ш и ф р о в а н и я и т.п.); • два 32-байтных случайных значения, одно из которых предоставля­ ется сервером, а другое — клиентом, н о оба участвуют в выработке ключей и начальных векторов; • два 64-битных п о р я д к о в ы х номера передаваемой записи (по о д н о ­ му на сторонах отправителя и получателя) с нулевым н а ч а л ь н ы м значением. Первоначальное состояние — ожидания — создает протокол установ­ ления соединений; он ж е ведает переводом отложенных соединений в те¬ кущие и наоборот. Формально процесс обработки данных протоколом передачи запи¬ сей м о ж н о описать к а к последовательность преобразований структур (в с п е ц и ф и к а ц и я х [48] для этой цели используется интуитивно п о н я т н ы й C подобный я з ы к ) . На первом шаге выполняется фрагментация (или объединение о д н о ­ т и п н ы х ) с о о б щ е н и й , п р е д н а з н а ч е н н ы х д л я передачи, в структуры T L S P l a i n t e x t размером н е более 16384 байт (см. листинг 10.1). enum { change_cipher_spec(2 0), a l e r t ( 2 1 ) , h a n d s h a k e ( 2 2 ) , a p p l i c a t i o n _ d a t a ( 2 3 ) , (255) } ContentType;

146

Лекция 10

Спецификация Internet-сообщества TLS

struct { ContentType type; ProtocolVersion version; uint16 length; opaque f r a g m e n t [ T L S P l a i n t e x t . l e n g t h ] ; } TLSPlaintext; Листинг 10.1. Начальная структура блока протокола передачи записей. Типы сообщений, поступающих с вышележащих уровней протоколу передачи записей, могут чередоваться, а сами сообщения — создавать оче¬ реди. В таком случае прикладные д а н н ы е имеют н а и м е н ь ш и й приоритет. На втором шаге выполняется сжатие данных (естественно, без поте­ р и и н ф о р м а ц и и ) . О н о приводит к появлению следующей структуры (см. листинг 10.2). struct { ContentType type; /* Тот же, что и T L S P l a i n t e x t . t y p e */ ProtocolVersion version; /* Та же, что и T L S P l a i n t e x t . v e r s i o n */ uint16 length; opaque f r a g m e n t [ T L S C o m p r e s s e d . l e n g t h ] ; } TLSCompressed; Листинг 10.2. Структура блока протокола передачи записей после сжатия. Далее следуют криптографические операции. К этому моменту на основе мастер-секрета и случайных значений, предоставленных сервером и клиентом, должен быть сгенерирован ключевой блок достаточной дли¬ н ы (см. листинг 10.3). k e y _ b l o c k = PRF (SecurityParameters.master_secret, "key e x p a n s i o n " , SecurityParameters.server_random + SecurityParameters.client_random); /* PRF - псевдослучайная функция */ /* "+" обозначает операцию конкатенации */ Листинг 10.3. Вычисление ключевого блока в протоколе передачи записей. 147

Курс

Информационная безопасность: основные стандарты и спецификации

Затем ключевой блок делится на п о р ц и и , служащие клиенту и серве­ ру ключами х э ш - ф у н к ц и й и ш и ф р о в а н и я , а также начальным вектором (см. листинг 10.4). client_write_MAC_secret [SecurityParameters.hash_size] server_write_MAC_secret [SecurityParameters.hash_size] client_write_key [SecurityParameters.key_material_length] server_write_key [SecurityParameters.key_material_length] client_write_IV [SecurityParameters.IV_size] server_write_IV [SecurityParameters.IV_size] /* MAC - M e s s a g e A u t h e n t i c a t i o n C o d e , аутентификационный код сообщения */ /* I V - I n i t i a l i z a t i o n V e c t o r , начальный вектор */ Листинг 10.4. Параметры криптографических операций протокола передачи записей. С п о м о щ ь ю сформированных параметров криптографических опе¬ р а ц и й выполняется третий шаг протокола передачи записи, состоящий в вычислении имитовставки (см. листинг 10.5). HMAC_hash ( M A C _ w r i t e _ s e c r e t , seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)); Листинг 10.5. Вычисление имитовставки в протоколе передачи за¬ писей. Обратим внимание, что в состав аргумента х э ш - ф у н к ц и и входит по¬ рядковый номер записи для защиты от кражи, дублирования и переупо­ рядочения сообщений. На четвертом шаге выполняется ш и ф р о в а н и е блока вместе с и м и т о вставкой (см. листинг 10.6). stream-ciphered struct { opaque c o n t e n t [ T L S C o m p r e s s e d . l e n g t h ] ; o p a q u e MAC [ C i p h e r S p e c . h a s h _ s i z e ] ; } GenericStreamCipher;

148

Лекция 10

Спецификация Internet-сообщества TLS

block-ciphered struct { opaque c o n t e n t [TLSCompressed.length]; o p a q u e MAC [ C i p h e r S p e c . h a s h _ s i z e ] ; u i n t 8 padding [GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case b l o c k : G e n e r i c B l o c k C i p h e r ; } fragment; } TLSCiphertext; Листинг 10.6. Ш и ф р о в а н и е блока вместе с имитовставкой в прото¬ коле передачи записей. На стороне получателя действия выполняются в обратном порядке: расшифрование; контроль целостности; декомпрессия; сборка сообщений. Разумеется, и здесь д о л ж н ы быть с ф о р м и р о в а н ы параметры крипто¬ графических операций. • • • •

Протокол установления соединений и ассоциированные протоколы Назначение протокола установления соединений — организовать се­ анс взаимодействия клиента и сервера (произвести аутентификацию сто­ р о н , согласовать п р и м е н я е м ы е алгоритмы — сжатия, выработки ключей, ш и ф р о в а н и я и вычисления имитовставки — и их параметры). Позднее, в рамках того ж е сеанса (при наличии флага возобновляемости), опираясь на согласованные параметры, новые соединения могут формироваться более э к о н о м н ы м образом. На рис. 10.1 показан процесс ф о р м и р о в а н и я сеанса. Звездочками помечены необязательные сообщения, в квадратные скобки заключено сообщение протокола смены параметров ш и ф р о в а н и я . П р о ц е с с ф о р м и р о в а н и я нового сеанса происходит с п о м о щ ь ю транспортных услуг протокола передачи записей по некоторому сущест149

Курс

Информационная безопасность: основные стандарты и спецификации

Клиент

Сервер

Приветственное сообщение клиента _ — — — -<— Сертификат клиента* Ключевой материал клиента В е р и ф и к а ц и я сертификата* [ Смена параметров шифрования]

—• —• —*• *~ ^ ~* ^

Прикладные данные

Приветственное сообщение сервера Сертификат сервера* Ключевой материал сервера* Запрос сертификата клиента* Завершение приветствия

<

Завершение ф о р м и р о в а н и я сеанса [Смена параметров шифрования] Завершение ф о р м и р о в а н и я сеанс > Прикадные данные

Рис. 10.1. Процесс ф о р м и р о в а н и я сеанса. вующему соединению, возможно, с пустыми алгоритмами сжатия и крип¬ тографии. Новое соединение на основе существующего сеанса формируется более э к о н о м н ы м образом (см. рис. 10.2). Обычно новые сеансы и соединения формируются по инициативе клиента (например, п р и подсоединении к серверу), н о и сервер может «намекнуть» клиенту на желательность подобного действия (если, н а п р и ­ мер, п р и ш л о время смены криптографических параметров), послав за­ прос приветственного сообщения (HelloRequest). П о я с н и м структуру и назначение сообщений, приведенных на ри¬ сунках. Приветственное сообщение клиента, открывающее процесс форми¬ рования сеанса и л и соединения, выглядит следующим образом (см. л и с ­ тинг 10.7). struct { uint3 2

gmt_unix_time; 150

Лекция 10

Спецификация Internet-сообщества TLS

opaque random_bytes [ 2 8 ] ; } Random; struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2 16-1>; CompressionMethod compression_methods<1..2 8-1>; } ClientHello; Листинг 10.7. Структура приветственного сообщения клиента в протоколе установления соединений. л

л

Если идентификатор сеанса (session id) пуст, имеется в виду ф о р м и ­ рование нового сеанса; в противном случае устанавливается новое соеди­ н е н и е в рамках существующего сеанса. П о л я compressionmethods и ciphersuites содержат списки предлагаемых клиентом алгоритмов сжатия и криптографии (в порядке убывания приоритетов). О н и д о л ж н ы быть построены так, чтобы согласие между клиентом и сервером было заведо¬ м о возможным. В частности, в списке алгоритмов сжатия должен фигури¬ ровать пустой метод. Сервер отвечает клиенту собственным приветствием, главное в ко¬ тором — выбранные алгоритмы сжатия и криптографии (см. листинг 10.8).

Клиент

Сервер

Приветственное сообщение клиента

^ [Смена параметров шифрования] Завершение ф о р м и р о в а н и я соединения Прикладные данные

Приветственное сообщение сервера [Смена параметров шифрования] Завершение ф о р м и р о в а н и я соединения

~~ —• — • Прикладные д а н н ы е

Рис. 10.2. Ф о р м и р о в а н и е нового соединения на основе существую¬ щего сеанса. 151

Курс

Информационная безопасность: основные стандарты и спецификации

struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello; Листинг 10.8. Структура приветственного сообщения сервера в п р о ­ токоле установления соединений. Если клиент представил непустой идентификатор сеанса, сервер ищет его в своем к э ш е и при возможности и ж е л а н и и возобновляет сеанс, формируя на его основе (по сокращенному варианту, показанному на рис. 10.2) новое соединение. В противном случае организуется еще один се¬ анс, быть может, а н о н и м н ы й (с пустым идентификатором) и, следова¬ тельно, невозобновляемый. На следующем шаге ф о р м и р о в а н и я нового сеанса сервер направля¬ ет клиенту свой сертификат (точнее, с е р т и ф и к а ц и о н н ы й маршрут), на¬ значение которого — предоставить материал для выработки совместных ключей и аутентифицировать сервер. В п р и н ц и п е , возможен, хотя и не рекомендуется, а н о н и м н ы й сеанс, без обмена сертификатами, однако нужно помнить, что он уязвим для атак нелегального посредника. Если сертификат сервера не посылался или содержащихся в нем данных недостаточно, сервер должен отправить свой ключевой материал в отдельном сообщении. П р и желании сервер может запросить сертифи¬ кат клиента. П о с л е з а в е р ш е н и я приветствия сервером и н и ц и а т и в а переходит к клиенту, к о т о р ы й д о л ж е н представить свой с е р т и ф и к а т (если таковой был з а п р о ш е н ) и ключевой материал для выработки предварительного мастер-секрета (или сам секрет, з а ш и ф р о в а н н ы й о т к р ы т ы м ключом сервера, если таков согласованный метод выработки ключей). В случае предоставления к л и е н т о м сертификата, о т к р ы т ы й ключ в котором п р и ­ годен для проверки э л е к т р о н н о й п о д п и с и , клиент может подписать все с о о б щ е н и я , отправленные и п о л у ч е н н ы е к этому моменту в процессе ус­ т а н о в л е н и я с о е д и н е н и я , что позволит аутентифицировать его к а к обла­ дателя соответствующего секретного ключа и подтвердить целостность процесса. С о о б щ е н и я о завершении ф о р м и р о в а н и я сеанса (соединения), от­ правляемые как клиентом, так и сервером, — первые, з а щ и щ е н н ы е толь­ ко что согласованными алгоритмами. О н и позволяют убедиться, что в ы ­ работка ключей и аутентификация прошли успешно. После того как сто¬ р о н ы отправили подобное сообщение, получили и верифицировали соот152

Лекция 10

Спецификация Internet-сообщества TLS

ветствующее сообщение партнера, о н и могут переходить к обмену при¬ кладными д а н н ы м и . Структура сообщения о завершении ф о р м и р о в а н и я сеанса (соеди­ н е н и я ) показана на листинге 10.9. struct { opaque v e r i f y _ d a t a [ 1 2 ] ; } Finished; F i n i s h e d . v e r i f y _ d a t a = PRF ( m a s t e r _ s e c r e t , finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; /* Хэшируются все сообщения, участвовавшие в уста­ новлении соединения Значениями параметра " f i n i s h e d _ l a b e l " служат, соответственно, цепочка символов " c l i e n t f i n i s h e d " на стороне клиента и " s e r v e r f i n i s h e d " на стороне сервера. */ Листинг 10.9. Структура сообщения о завершении ф о р м и р о в а н и я сеанса в протоколе установления соединений. Мастер-секрет вычисляется единообразно для всех методов выра­ ботки ключей (см. листинг 10.10). m a s t e r _ s e c r e t = PRF ( p r e _ m a s t e r _ s e c r e t , "master s e c r e t " , C l i e n t H e l l o . r a n d o m + ServerHello.random) [0..47]; Листинг 10.10. Вычисление мастер-секрета. Участвующий в процессе ф о р м и р о в а н и я сеанса протокол смены па­ раметров ш и ф р о в а н и я устроен предельно просто и заключает в себе один тип однобайтных сообщений. Более содержательный протокол оповещения предназначен для пе¬ редачи предупреждений и сообщений об ошибках. Наиболее употреби¬ тельное предупреждение — уведомление о завершении сеанса. Типичные о ш и б к и — неожиданное сообщение, неверная имитовставка, неверный параметр, ошибка р а с ш и ф р о в а н и я и т.п. После получения сообщения об о ш и б к е соединение разрывается.

П р и м е н е н и е п р о т о к о л а HTTP над TLS П р и м е н е н и е протокола H T T P над T L S описано в с п е ц и ф и к а ц и я х [82]. С концептуальной точки зрения, оно организовано весьма просто. H T T P / T L S - с е р в е р слушает порт 443. H T T P / T L S - к л и е н т , являясь, в част153

Курс

Информационная безопасность: основные стандарты и спецификации

ности, TLS-клиентом, начинает процесс установления соединения с п о ­ сылки приветственного сообщения. П о сформированному TLS-соединен и ю направляются обычные H T T P - з а п р о с ы и ответы на них, которые трактуются протоколом T L S как прикладные данные. В у н и к а л ь н о м и д е н т и ф и к а т о р е ресурсов ( U R I ) сочетание H T T P / T L S обозначается как «https»: https://www.example.com/home.html Обычно после анализа U R I клиент узнает и м я хоста, на котором функционирует сервер. Это и м я должно быть сопоставлено с тем, которое фигурирует в сертификате сервера. Если сервер задан IP-адресом, тот ж е адрес должен присутствовать в сертификате и подвергаться проверке. В качестве сигнала о к о н ч а н и я взаимодействия используется уведом¬ ление о завершении сеанса.

154

Лекция 11

Спецификация Internet-сообщества GSS-API

Лекция 1 1 . Спецификация Internet-сообщества «Обобщенный прикладной программный интерфейс службы безопасности» Рассматривается прикладной программный интерфейс к средствам за­ щиты коммуникаций между компонентами программных систем, построен­ ных в архитектуре клиент/сервер. Данная спецификация логически дополня¬ ет защитные протоколы сетевого и транспортного уровней.

Ключевые слова: защита к о м м у н и к а ц и й , архитектура клиент/сервер, аутентификация, целостность, конфиденциальность, механизм бе¬ зопасности, мобильность приложений на уровне исходного текста, удостоверение, контекст безопасности, токен безопасности, меха¬ низм безопасности, и м я , канал передачи данных, основной код от­ вета, дополнительный код ответа, дескриптор удостоверения, запрос удостоверения, отказ от удостоверения, получение и н ф о р м а ц и и об удостоверении, с о з д а н и е контекста безопасности, у н и ч т о ж е н и е контекста безопасности, получение и н ф о р м а ц и и о контексте, пере¬ дача контекста другому процессу, прием контекста, а н о н и м н ы й кон¬ текст, стслеживание продублированных сообщений, контроль по¬ следовательности сообщений, качество защиты, входной параметр, выходной параметр, дескриптор структурного значения, и д е н т и ф и ­ катор объекта.

Введение О б о б щ е н н ы й прикладной программный интерфейс службы безо¬ пасности (Generic Security Service Application Program Interface — G S S A P I , см. [73], [91]) предназначен для защиты коммуникаций между ком¬ понентами программных систем, построенных в архитектуре клиент/сер¬ вер. О н предоставляет услуги по взаимной аутентификации осуществля¬ ю щ и х контакт партнеров и по контролю целостности и обеспечению кон¬ фиденциальности пересылаемых сообщений. Пользователями интерфейса безопасности G S S - A P I являются к о м ­ м у н и к а ц и о н н ы е протоколы (обычно прикладного уровня) или другие программные системы, самостоятельно в ы п о л н я ю щ и е пересылку данных. О б о б щ е н н ы й интерфейс безопасности G S S - A P I не зависит от кон¬ кретной языковой среды и от механизмов безопасности, обеспечиваю­ щ и х реальную защиту. Последнее обстоятельство позволяет создавать приложения, которые на уровне исходного текста мобильны по о т н о ш е 155

Курс

Информационная безопасность: основные стандарты и спецификации

н и ю к смене механизмов безопасности. Тем самым реализуется откры¬ тость прикладных систем и соответствующих средств защиты. Следует отметить, что средства защиты могут быть очень р а з н ы м и — от систем Kerberos (см. [3]) д о продуктов, реализующих с п е ц и ф и к а ц и и X.509, т. е. G S S - A P I имеет под собой вполне конкретную почву. На каждом к о м п ь ю т е р е , где предполагается п р и м е н я т ь и н т е р ф е й с безопасности G S S - A P I , д о л ж н о быть установлено к л и е н т с к о е про¬ г р а м м н о е о б е с п е ч е н и е соответствующего механизма з а щ и т ы . Прило¬ ж е н и е , и с п о л ь з у ю щ е е G S S - A P I , л о к а л ь н ы м образом вызывает необхо¬ д и м ы е ф у н к ц и и , получая в ответ т а к н а з ы в а е м ы е т о к е н ы безопасности. Подобный токен может содержать зашифрованное удостоверение пользователя, э л е к т р о н н у ю п о д п и с ь и л и целое з а ш и ф р о в а н н о е с о о б ­ щ е н и е . П р и л о ж е н и я о б м е н и в а ю т с я т о к е н а м и безопасности, достигая тем с а м ы м а у т е н т и ф и к а ц и и , целостности и к о н ф и д е н ц и а л ь н о с т и об¬ щ е н и я . П о с к о л ь к у к о м м у н и к а ц и о н н ы е аспекты в ы н е с е н ы за пределы G S S - A P I , о н автоматически оказывается н е з а в и с и м ы м от сетевых п р о ­ т о к о л о в . Сетевая м о б и л ь н о с т ь п р и л о ж е н и й д о л ж н а обеспечиваться и н ы м и средствами.

Основные понятия О б о б щ е н н ы й прикладной программный интерфейс службы безо¬ пасности содержит следующие основные понятия: • удостоверение; • контекст безопасности; • токен безопасности; • механизм безопасности; • имя; • канал передачи данных. Удостоверение — это структура данных, позволяющая ее владельцу доказать партнеру по о б щ е н и ю и л и третьей стороне, что он (владелец) я в ­ ляется и м е н н о тем, за кого себя выдает. Таким образом, в G S S - A P I удос­ товерения выступают к а к средство аутентификации. Естественно, что служба безопасности (например, Kerberos) совме¬ стно с операционной системой д о л ж н ы обеспечить защиту удостовере¬ н и й от несанкционированного использования и / и л и изменения. П р о ц е с ­ сам, действующим от и м е н и пользователей, н е предоставляется прямого доступа к удостоверениям. Вместо этого п р и необходимости процессы снабжаются дескрипторами удостоверений, которые н е содержат секрет­ ной и н ф о р м а ц и и и н е нуждаются в защите. Нет смысла воровать дес­ крипторы, поскольку их интерпретация для разных процессов-предъяви¬ телей будет различной. 156

Лекция 11

Спецификация Internet-сообщества GSS-API

О д н о м у п о л ь з о в а т е л ю могут п о н а д о б и т ь с я у д о с т о в е р е н и я не¬ с к о л ь к и х видов. В о - п е р в ы х , структура у д о с т о в е р е н и й , н е с о м н е н н о , з а в и с и т от м е х а н и з м а б е з о п а с н о с т и , с т о я щ е г о за о б о б щ е н н ы м и н т е р ­ ф е й с о м . В о - в т о р ы х , и н о г д а для связи с р а з н ы м и п а р т н е р а м и н у ж н ы р а з л и ч н ы е удостоверения. В-третьих, о с о б ы м о б р а з о м д о л ж н ы быть устроены т а к н а з ы в а е м ы е делегируемые у д о с т о в е р е н и я , с л у ж а щ и е для передачи прав на в ы п о л н е н и е о п р е д е л е н н ы х д е й с т в и й от и м е н и неко¬ торого пользователя. Есть и другие ф а к т о р ы , в л и я ю щ и е на структуру удостоверений. В процессе входа пользователя в систему могут формироваться удо­ стоверения стандартного вида, выдаваемые по умолчанию. Контекст безопасности — это пара структур данных (по одной л о ­ кально хранимой структуре для каждого контактирующего партнера), где содержится разделяемая и н ф о р м а ц и я о состоянии процесса о б щ е н и я , н е ­ обходимая для защиты пересылаемых сообщений. К а к и удостоверения, контексты безопасности хранятся внутренним (для службы безопаснос­ ти) образом — прикладные процессы снабжаются л и ш ь дескрипторами контекстов. Контексты формируются на основании локально выданных или делегированных удостоверений. Партнеры могут по очереди или одновременно использовать не¬ сколько контекстов, если необходимо поддерживать и н ф о р м а ц и о н н ы е потоки разной степени защищенности. Интерфейс G S S - A P I не зависит от используемых коммуникацион¬ ных протоколов, поэтому ф о р м и р о в а н и е контекста безопасности н и к а к не связано с установлением соединения в сетевом смысле. Более того, для G S S - A P I безразлично, какой протокол используется — с установлением соединения или без такового. Организация потока сообщений, а также выделение из входного потока данных, генерируемых в рамках G S S - A P I , — обязанность прикладных систем. Токены безопасности — элементы данных, пересылаемые между пользователями интерфейса G S S - A P I с целью поддержания работоспо¬ собности этого интерфейса и защиты прикладной и н ф о р м а ц и и . Токены подразделяются на два класса. Контекстный класс предназначен для ус­ тановления контекстов безопасности и для в ы п о л н е н и я над н и м и управ­ л я ю щ и х действий. В рамках уже установленного контекста для защиты сообщений используются токены сообщений. Перед началом о б щ е н и я с удаленным партнером приложение обра­ щается к интерфейсу G S S - A P I с просьбой инициализировать контекст. В ответ возвращается контекстный токен безопасности, который приложе­ н и е обязано переслать партнеру. Тот, получив токен, передает его локаль­ ному экземпляру G S S - A P I для проверки подлинности инициатора и п р о ­ должения (обычно — завершения) ф о р м и р о в а н и я контекста. 157

Курс

Информационная безопасность: основные стандарты и спецификации

Если п р и л о ж е н и ю необходимо защитить сообщение, обеспечив воз¬ можность контроля целостности и подлинности источника данных, оно передает его интерфейсу G S S - A P I , получая в ответ токен, содержащий криптографическую контрольную сумму (имитовставку, хэш, дайджест), заверенную электронной подписью отправителя. После этого приложе¬ н и е должно переслать как само сообщение, так и з а щ и щ а ю щ и й его токен. Партнер, получив обе п о р ц и и данных, передает их своему локальному эк¬ земпляру G S S - A P I для проверки авторства и целостности. Для приложения структура токенов безопасности закрыта. Токены генерируются и контролируются исключительно ф у н к ц и я м и G S S - A P I . Дело приложения — переслать их и передать соответствующим ф у н к ц и я м для обработки. Естественно, служба безопасности обнаружит попытки приложения изменить токен, если таковые будут предприняты. Вполне возможно, что на удаленных системах функционирует не¬ сколько различных служб безопасности. В этих условиях для успешного ф о р м и р о в а н и я контекста безопасности партнеры д о л ж н ы тем или и н ы м способом договориться, какая и м е н н о служба будет использоваться. Конкретная служба характеризуется типом реализуемого механизма бе­ зопасности. В свою очередь, тип обозначается посредством структуры дан¬ ных, называемой идентификатором объекта. На уровне обобщенного про¬ граммного интерфейса структура идентификаторов объектов не уточняется. Каждая система обязана предлагать некоторый механизм безопасно­ сти к а к подразумеваемый, которым и рекомендуется пользоваться прило¬ ж е н и ю из соображений мобильности. Если токены являются структурой, закрытой для приложений, то структура и м е н , употребляемых при ф о р м и р о в а н и и контекста безопасно­ сти (имеются в виду имена партнеров по о б щ е н и ю ) , закрыта для ф у н к ц и й G S S - A P I . И м е н а рассматриваются этими ф у н к ц и я м и как последователь­ ности байт, интерпретируемые, вероятно, к о м м у н и к а ц и о н н ы м и компо¬ нентами приложений. В G S S - A P I предусматривается наличие трех типов и м е н — внутрен¬ них, печатных и объектных. К а к правило, аргументами ф у н к ц и й G S S A P I служат внутренние имена. Интерфейс G S S - A P I предоставляет ф у н к ­ ц и и для преобразования имен и выполнения некоторых других действий над н и м и . Отметим, что интерпретация имен — дело довольно сложное, посколь­ ку они могут принадлежать разным пространствам имен. Чтобы избежать неоднозначности, в состав имени включается идентификатор его типа. Для усиления защиты и н ф о р м а ц и и в интерфейсе G S S - A P I предлага­ ется возможность связывания контекста безопасности с определенными каналами передачи данных: инициатор ф о р м и р о в а н и я контекста может указать набор каналов, которые допустимо использовать в рамках о т к р ы 158

Лекция 11

Спецификация Internet-сообщества GSS-API

ваемого сеанса общения. Партнер должен подтвердить свое согласие на связывание с этим набором каналов. Канал характеризуется целевым ад­ ресом и некоторыми другими параметрами, включая формат пересылае­ мой по нему и н ф о р м а ц и и , степень ее защищенности и т.п. Если токен, отправленный для установления контекста, будет перехвачен, использо­ вание соответствующего контекста ограничится рамками связанных с н и м каналов. М о ж н о надеяться, что подобное препятствие затруднит действия злоумышленника. К а ж д а я ф у н к ц и я , в х о д я щ а я в состав о б о б щ е н н о г о и н т е р ф е й с а бе­ з о п а с н о с т и G S S - A P I , возвращает два кода ответа — о с н о в н о й и д о п о л ­ н и т е л ь н ы й . Н а б о р о с н о в н ы х кодов регламентируется в р а м к а х G S S A P I , д о п о л н и т е л ь н ы е могут быть с п е ц и ф и ч н ы для р а з л и ч н ы х служб безопасности. Основные коды подразделяются на и н ф о р м и р у ю щ и е и сигнализи¬ р у ю щ и е об ошибке. Перечислим некоторые и н ф о р м и р у ю щ и е коды: • G S S _ S _ C O M P L E T E — нормальное завершение; • G S S _ S _ C O N T I N U E _ N E E D E D — требуется дополнительный вызов данной функции; • G S S _ S _ D U P L I C A T E _ T O K E N — обнаружено дублирование токена защиты сообщений. Следующие значения входят в число кодов, сигнализирующих об ошибке: • G S S _ S _ B A D _ N A M E — задано некорректное имя; • G S S _ S _ C O N T E X T _ E X P I R E D — истек срок действия контекста; • G S S _ S _ C R E D E N T I A L S _ E X P I R E D — истек срок действия удостове­ рения; • G S S _ S _ D E F E C T I V E _ T O K E N — обнаружено повреждение токена безопасности; • G S S _ S _ N O _ C O N T E X T — не задан контекст; • G S S _ S _ N O _ C R E D — не задано удостоверение. Проанализировав основной код, приложение сделает вывод о нор¬ мальном или ненормальном завершении ф у н к ц и и . В последнем случае о н о может принять во в н и м а н и е дополнительный код, что даст пользова­ телю больше и н ф о р м а ц и и , но уменьшит мобильность приложения.

Функции для работы с удостоверениями Работа приложения, опирающегося на интерфейс G S S - A P I , должна начинаться с получения удостоверения, которое засвидетельствует, что приложение имеет право выступать от и м е н и определенного субъекта. Интерфейс G S S - A P I предоставляет следующие ф у н к ц и и для п р и м е ­ н е н и я удостоверений: 159

Курс

Информационная безопасность: основные стандарты и спецификации

• GSS_Ac.quire_c.reH — запрос удостоверения для последующего ис¬ пользования; • GSS_Release_cred — отказ от удостоверения, ставшего ненужным; • GSS_Inquire_cred — получение и н ф о р м а ц и и об удостоверении; • GSS_Add_cred — постепенное ф о р м и р о в а н и е удостоверения; • GSS_Inquire_cred_by_mech — получение и н ф о р м а ц и и об удостове­ р е н и и , связанной с конкретным механизмом безопасности. К а к уже указывалось, приложение получает в свое распоряжение не само удостоверение, а его дескриптор, впоследствии используемый в ка¬ честве аргументов ф у н к ц и й GSS_Release_cred, GSS_Inquire_cred, GSS_Add_cred, а также ф у н к ц и й ф о р м и р о в а н и я контекста безопасности. Ф у н к ц и я GSS_Acquire_cred нужна в первую очередь серверным про¬ цессам, ж е л а ю щ и м сообщить, от чьего и м е н и они выступают. Интерак¬ тивные пользователи могут получать подразумеваемые удостоверения н е ­ я в н ы м образом при входе в систему. Аналогично, при выходе такого поль­ зователя из системы может автоматически выполняться вызов ф у н к ц и и GSS_Release_cred. Ф у н к ц и я GSS_Inquire_cred позволяет получить и н ф о р м а ц и ю об удостоверении: и м я ассоциированного субъекта, срок годности, возмож­ ность употребления в операциях с контекстом ( и н и ц и а ц и я и / и л и п р и н я ­ тие), поддерживаемые механизмы безопасности. Д а н н а я ф у н к ц и я осо¬ бенно полезна применительно к подразумеваемому удостоверению, ха¬ рактеристики которого могут меняться от системы к системе. С п о м о щ ь ю ф у н к ц и и GSS_Add_cred возможно постепенно форми¬ ровать удостоверения, добавляя в них поля, необходимые различным ме¬ ханизмам безопасности. Ф у н к ц и я GSS_Inquire_cred_by_mech пригодится в среде, поддержи­ вающей несколько механизмов безопасности. Она, в частности, позволя­ ет убедиться в том, что допускается использование данного удостовере­ н и я совместно с конкретным механизмом безопасности.

Создание и уничтожение контекстов безопасности Создание контекста безопасности предшествует всем операциям по обмену с о о б щ е н и я м и между потенциальными партнерами. В процессе его ф о р м и р о в а н и я партнеры могут убедиться в подлинности друг друга, а также договориться о степени защищенности коммуникаций. Впрочем, обычно, в силу асимметричности о т н о ш е н и я клиент/сервер, аутентифи­ кация носит односторонний характер — сервер убеждается в подлинности клиента. Для работы с контекстами о б о б щ е н н ы й интерфейс безопасности G S S - A P I предоставляет следующие функции: 160

Лекция 11

Спецификация Internet-сообщества GSS-API

• GSS_Init_sec_context — ф о р м и р о в а н и е «исходящего» контекста, т. е. части контекста, относящейся к инициатору общения; • GSS_Accept_sec_context — формирование «входящего» контекста, т. е. части контекста, относящейся к вызываемому партнеру; • GSS_Delete_sec_context — отказ от контекста, ставшего ненужным; • GSS_Process_context_token — обработка полученного контекстного токена; • GSS_Context_time — выяснение срока годности контекста; • GSS_Inquire_context — получение и н ф о р м а ц и и о контексте; • GSS_Wrap_size_limit — выяснение максимального размера сообще­ н и я , которое м о ж н о зашифровать в рамках заданного контекста бе¬ зопасности; • GSS_Export_sec_context — передача контекста другому процессу; • GSS_Import_sec_context — прием контекста, переданного другим процессом. И н и ц и а т о р о б щ е н и я вызывает ф у н к ц и ю GSS_Init_sec_context, п е ­ редавая ей свое удостоверение — я в н о полученное или подразумеваемое. К р о м е того, инициатор специфицирует запрашиваемую процедуру вза¬ и м н о й аутентификации и уровень защиты сообщений. В ответ ему воз¬ вращается токен, который следует переслать партнеру. Партнер, получив токен, передает его функции GSS_Accept_sec_context (вместе со своим удостоверением). К а к правило, на этом ф о р м и р о в а н и е контекста заканчивается. Партнеры д о л ж н ы про¬ анализировать флаги, ассоциированные с контекстом, чтобы узнать, ка¬ ков реально предоставленный уровень защиты. Если инициатор о б щ е н и я (обычно это клиент) желает убедиться в подлинности партнера, о н передает ф у н к ц и и GSS_Init_sec_context флаг mutual_req_flag (требуется взаимная аутентификация). В таком случае вы¬ зов GSS_Init_sec_context возвращает в качестве основного кода значение G S S _ S _ C O N T I N U E _ N E E D E D (а н е G S S _ S _ C O M P L E T E ) . Соответству¬ ю щ и м образом меняется и генерируемый контекстный токен. Партнер, п р и н я в и обработав (с п о м о щ ь ю ф у н к ц и и GSS_Accept_sec_context) при¬ с л а н н у ю и н ф о р м а ц и ю , получит н а выходе у с т а н о в л е н н ы й ф л а г mutual_state и н о в ы й контекстный токен, который следует вернуть ини¬ циатору. П о с л е д н и й д о л ж е н п о в т о р н о обратиться к ф у н к ц и и GSS_Init_sec_context с полученным токеном. П р и отсутствии о ш и б о к GSS_Init_sec_context вернет, н а к о н е ц , о с н о в н о й к о д G S S _ S _ C O M P L E T E , и ф о р м и р о в а н и е контекста на этом завершится. П р и ф о р м и р о в а н и и контекста служба безопасности может требовать обмена несколькими токенами (даже без взаимной аутентификации). Тогда и н и ц и а т о р у п р и д е т с я н е с к о л ь к о р а з в ы з ы в а т ь ф у н к ц и ю GSS_Init_sec_context, а его партнеру — ф у н к ц и ю GSS_Accept_sec_con161

Курс

Информационная безопасность: основные стандарты и спецификации

text. Все вызовы, кроме последнего, вернут основной код G S S _ S _ C O N T I N U E _ N E E D E D . Последний вызов, завершающий ф о р м и р о в а н и е кон¬ текста на соответствующей стороне, в нормальном случае выдаст основ¬ ной код G S S _ S _ C O M P L E T E . Партнеры д о л ж н ы сами определять (способами, в н е ш н и м и по отно¬ ш е н и ю к G S S - A P I ) , что и м е н н о и з пересылаемой и н ф о р м а ц и и представ¬ ляет собой контекстный токен и какой ф у н к ц и и его следует передать. П р и о т к а з е от к о н т е к с т а , с т а в ш е г о н е н у ж н ы м , ф у н к ц и я GSS_Delete_sec_context может передать у п р а в л я ю щ и й т о к е н , п о д л е ­ ж а щ и й п е р е с ы л к е партнеру. П а р т н е р , п р и н я в т о к е н , д о л ж е н вызвать ф у н к ц и ю GSS_Process_context_token, к о т о р а я п р о а н а л и з и р у е т у п р а в ­ л я ю щ у ю и н ф о р м а ц и ю и удалит вторую п о л о в и н у с б р а с ы в а е м о г о кон¬ текста. К а к правило, в процессе ф о р м и р о в а н и я контекста партнер получает и н ф о р м а ц и ю о его инициаторе. И н и ц и а т о р может запросить формирова¬ н и е «анонимного» контекста посредством флага anon_req_flag. Это имеет смысл при пользовании общедоступными услугами (получение свободно распространяемой и н ф о р м а ц и и и т.п.). Партнер вправе принять или от¬ вергнуть а н о н и м н ы й контекст. Ф у н к ц и я GSS_Inquire_context позволяет получить и н ф о р м а ц и ю о контексте — имена инициатора общения и его партнера, срок годности, тип задействованного механизма безопасности, а также ассоциирован¬ н ы е флаги (replay_det_state — обеспечивается отслеживание продублиро­ ванных сообщений, conf avail — предоставляется возможность ш и ф р о ­ вать сообщения и т.п.). Ф у н к ц и я GSS_Export_sec_context предоставляет токен, пригодный для передачи контекста безопасности другому процессу в пределах одной вычислительной системы. Передавать м о ж н о только полностью сформи¬ р о в а н н ы й контекст. Вообще говоря, экспортировав контекст, процесс т е ­ ряет право на его использование. Для приема (импорта) контекста безопасности служит ф у н к ц и я GSS_Import_sec_context.

Защита сообщений П р и ф о р м и р о в а н и и контекста партнеры п о о б щ е н и ю имеют воз¬ можность убедиться в подлинности друг друга. Все остальные средства службы безопасности направлены на защиту сообщений. Интерфейс G S S - A P I предоставляет следующие ф у н к ц и и для работы с сообщениями: • G S S G e t M I C — ф о р м и р о в а н и е токена, позволяющего контролиро­ вать целостность сообщения и подлинность его источника; 162

Лекция 11

Спецификация Internet-сообщества GSS-API

• G S S VerifyMIC — проверка целостности сообщения и подлинности источника с п о м о щ ь ю ассоциированного токена; • GSS_Wrap — ф о р м и р о в а н и е инкапсулированного, возможно, заши¬ фрованного, сообщения, содержащего и н ф о р м а ц и ю для контроля целостности и проверки подлинности источника; • G S S U n w r a p — разбор инкапсулированного сообщения. П р и ф о р м и р о в а н и и контекста инициатор специфицирует требуе¬ м ы й уровень защиты сообщений. Ответные флаги показывают, обеспечи¬ вается ли этот уровень на самом деле. Флаг integavail информирует о воз­ можности контроля целостности и подлинности источника сообщения, confavail — о доступности средств ш и ф р о в а н и я . Прежде чем обращаться к ф у н к ц и я м G S S _ G e t M I C / G S S _ W r a p , приложение должно проверить с о ­ стояние перечисленных флагов. Ф у н к ц и я G S S G e t M I C на основе с о о б щ е н и я формирует отдель­ н ы й токен безопасности. Ф у н к ц и я G S S Wrap «упаковывает» контроль¬ ную и н ф о р м а ц и ю вместе с с о о б щ е н и е м (быть может, з а ш и ф р о в а н н ы м ) . П р и л о ж е н и я д о л ж н ы уметь различать т о к е н ы безопасности и с о о б щ е ­ н и я ( и н к а п с у л и р о в а н н ы е или нет) и обрабатывать их соответствующим образом. Служба безопасности способна предоставлять дополнительные ус­ луги в виде отслеживания продублированных сообщений и усиленного контроля последовательности сообщений. П р и ф о р м и р о в а н и и контекста эти услуги могут быть з а к а з а н ы (флаги replay_det_req_flag и sequence_req_flag). Ответные флаги показывают, действительно ли обес¬ печивается з а п р о ш е н н ы й уровень защиты — тогда в ассоциированные т о ­ к е н ы безопасности или инкапсулированные сообщения прозрачным для приложения образом могут вставляться порядковые номера, временные ш т а м п ы и т.п. Соответственно, приложение должно быть готово получить от ф у н к ц и й G S S V e r i f y M I C / G S S U n w r a p основные коды завершения: G S S _ S _ D U P L I C A T E _ T O K E N (обнаружено дублирование сообщений), G S S _ S _ O L D _ T O K E N (старое с о о б щ е н и е ) , G S S _ S _ U N S E Q _ T O K E N (опоздавшее с о о б щ е н и е ) , G S S _ S _ G A P _ T O K E N ( с о о б щ е н и е п р и ш л о с л и ш к о м рано — некоторые предшествующие сообщения еще не получе­ ны). Подозрительные сообщения, несмотря на ненормальный код завер­ ш е н и я , передаются п р и л о ж е н и ю , которое трактует ситуацию в соответст¬ вии с избранной политикой безопасности (в частности, ничто не мешает обработать сообщение о б ы ч н ы м образом). Некоторые службы безопасности могут предоставлять различное ка­ чество защиты (Quality O f Protection — QOP). Выбор подходящего качест­ ва важен для приложения с точки зрения разумного расходования ресур­ сов, поскольку сильная защита может требовать значительных накладных расходов. В с п е ц и ф и к а ц и я х интерфейса G S S A P I определяется формат 163

Курс

Информационная безопасность: основные стандарты и спецификации

элемента данных, описывающего качество защиты. Это 32-битное целое, состоящее из двух 16-битных частей, одна и з которых относится к к о н ­ тролю целостности, а другая — к обеспечению конфиденциальности. В обоих случаях задается степень контроля, идентификаторы используемых алгоритмов и и н ф о р м а ц и я , с п е ц и ф и ч н а я для выбранного алгоритма.

Логика работы пользователей интерфейса безопасности П р и в е д е м п р и м е р н ы й с ц е н а р и й взаимодействия между к л и е н т о м и сервером (см. р и с . 11.1). Предполагается, что д л я в з а и м н о й аутенти¬ ф и к а ц и и достаточно о б м е н а о д н о й п а р о й т о к е н о в безопасности и что п а р т н е р ы з а п р а ш и в а ю т и к о н т р о л ь целостности, и о б е с п е ч е н и е конфи¬ д е н ц и а л ь н о с т и с о о б щ е н и й , а служба безопасности предоставляет и м эти средства. Детали, связанные с преобразованием и м е н , опущены. Текст в ф и ­ гурных скобках является комментарием. Стрелка —> отделяет входные параметры от выходных. М ы видим, что общая схема взаимодействия удаленных партнеров под защитой интерфейса безопасности G S S - A P I довольно проста, однако практическая реализация всех необходимых проверок (кодов заверше­ н и я , установленных флагов) требует известной аккуратности.

Представление некоторых объектов интерфейса безопасности в среде языка C Представление средствами я з ы к а C объектов, фигурирующих в о б о б щ е н н о м интерфейсе безопасности G S S - A P I , по большей части до¬ вольно очевидно (или н е может быть стандартизовано, так к а к зависит от с п е ц и ф и к и механизма безопасности). Прежде всего, вводится тип OM_uint32, соответствующий 32-бит­ н ы м беззнаковым целым значениям. Большинство структурных значений представляется с п о м о щ ь ю указателя на дескриптор (см. листинг 11.1). typedef s t r u c t gss_buffer_desc_struct { size_t length; void *value; } gss_buffer_desc, *gss_buffer_t; Листинг 11.1. О п и с а н и е дескриптора буфера и указателя на него. Тип g s s _ b u f f e r _ t используется при задании составных аргумен¬ тов — и м е н , дескрипторов, токенов, сообщений и т.п. 164

Лекция 11

Спецификация Internet-сообщества GSS-API

Сервер {Получение удостоверения сервером} GSS_Acquire_cred (servername {имя, под которым регистрируется сервер}, ... ) —> GSS_S_COMPLETE, serv_cred_handle {дескриптор удостовере­ н и я сервера}, ... . . . {Обслуживание других клиентов} . . .

|Клиент {Получение удостоверения клиентом} {Неявное получение подразумеваемого удостоверения при входе в систему} {Начало ф о р м и р о в а н и я контекста клиентом} GSS_Init_sec_context ( N U L L {подразумеваемое удостоверение}, 0 {дескриптор контекста пока н е сформирован}, targname {имя удаленного сервера}, mutual_req_flag {истина, если нужна взаимная аутентификация}, N U L L {пока нет токена, полученного от партнера}) —> GSS_S_CONTINUE_NEEDED, client_context_handle {дескрип­ тор контекста для клиента}, con_token_1 {контекстный токен, ко¬ торый нужно переслать серверу}, ... {флаги}, ...

^

Пересылка токена con_token_1 серверу

Сервер {Принятие контекста сервером} GSS_Accept_sec_context (serv_cred_handle, 0 {дескриптор контекста пока н е сформирован}, con_token_1) —> G S S _ S _ C O M P L E T E , ... , c l i e n t n a m e {имя инициатора ф о р м и р о в а н и я контекста}, serv_context_handle {дескриптор контекста для сервера}, ... {флаги}, con_token_2 {контекстный токен, который нужно вернуть клиенту}

1

Пересылка токена con_token_2 клиенту продолжение на следующей 165

странице

Курс

Информационная безопасность: основные стандарты и спецификации

Клиент {Завершение ф о р м и р о в а н и я контекста клиентом} GSS_Init_sec_context ( N U L L , client_context_handle, targ_name, ... , con_token_2) —> GSS_S_COMPLETE, client_context_handle, N U L L {нет токена, который нужно переслать серверу}, ... {Формирование клиентом сообщения с контролем целостности и доказательством подлинности источника данных} G S S _ G e t M I C (client_context_handle, 0 {подразумеваемое качество защиты}, message_1 {защищаемое сообщение}) —> G S S _ S _ C O M P L E T E , ... , mes_token_1 {токен, з а щ и щ а ю щ и й сообщение}

Пересылка сообщения message_1 и токена mes_token_1 серверу

Сервер {Проверка сервером целостности и аутентичности полученного со¬ общения} G S S V e r i f y M I C (serv_context_handle, message_1, mes_token_1) —> qopstate {обеспечиваемое качество защиты}, G S S _ S _ C O M P L E T E {если все в порядке}, {Формирование сервером зашифрованного сообщения} G S S W r a p (serv_context_handle, conf_req_flag {истина, если требуется шифрование}, 0 {подразумеваемое качество защиты}, message_2) —> GSS_S_COMPLETE, confstate {истина, если служба безопаснос¬ ти обеспечивает конфиденциальность}, encaps_message_2 {инкапсу¬ лированное сообщение message_2, зашифрованное, с добавленной и н ф о р м а ц и е й для контроля целостности и подлинности источника}

Пересылка зашифрованного сообщения encaps_message_2 клиенту продолжение на следующей 166

странице

Лекция 11

Спецификация Internet-сообщества GSS-API 1

Клиент {Прием клиентом зашифрованного сообщения} G S S U n w r a p (client_context_handle, encaps_message_2) —> conf_state {истина, если служба безопасности обеспечивает конфи¬ денциальность}, qopstate {обеспечиваемое качество защиты}, G S S _ S _ C O M P L E T E {если все в порядке}, message_2 {расшифрованное сообщение}

т

{Обмен другими сообщениями} . .

.

Сервер

{Сброс сервером контекста безопасности, ставшего ненужным} GSS_Delete_sec_context (serv_context_handle) —> GSS_S_COMPLETE, con_token_3 {контекстный токен, который м о ж н о переслать клиенту, чтобы тот также удалил свою часть кон¬ текста безопасности}

т

Пересылка токена con token 3 клиенту

^

Клиент {Обработка полученного управляющего токена} GSS_Process_context_token (client_context_handle, con_token_3) —> G S S _ S _ C O M P L E T E , ... {Выход клиента из системы}

1 Сервер {Обслуживание других клиентов}

Рис. 11.1. П р и м е р н ы й сценарий взаимодействия между клиентом и сервером под защитой обобщенного интерфейса безопасности.

167

Курс

Информационная безопасность: основные стандарты и спецификации

И д е н т и ф и к а т о р ы объектов представляются следующим образом (см. листинг 11.2). typedef s t r u c t gss_OID_desc_struct { OM_uint32 l e n g t h ; void *elements; } gss_OID_desc, *gss_OID; Листинг 11.2. О п и с а н и е дескриптора идентификаторов объектов и указателя на него. Указатели e l e m e n t s ссылаются на начало представления иденти¬ фикаторов, т. е. на последовательности байт, устроенных в соответствии с базовыми правилами A S N . 1 . Наборы объектных идентификаторов представляются так, к а к пока¬ зано на листинге 11.3. typedef s t r u c t gss_OID_set_desc_struct { i n t count; gss_OID elements; } gss_OID_set_desc, *gss_OID_set; Листинг 11.3. О п и с а н и е дескриптора набора объектных и д е н т и ф и ­ каторов и указателя на него. Вводятся и некоторые другие т и п ы , уточняющие представление структурированных значений. На листинге 11.4 показано, к а к выглядит на я з ы к е C описание ф у н к ­ ции G S S _ I n i t _ s e c _ c o n t e x t . OM_uint32 g s s _ i n i t _ s e c _ c o n t e x t ( OM_uint32 * m i n o r _ s t a t u s , const g s s _ c r e d _ i d _ t i n i t i a t o r _ c r e d _ h a n d l e , gss_ctx_id_t *context_handle, c o n s t gss_name_t target_name, const gss_OID mech_type, OM_uint32 r e q _ f l a g s , OM_uint3 2 t i m e _ r e q , const gss_channel_bindings_t input_chan_bindings, const g s s _ b u f f e r _ t i n p u t _ t o k e n gss_OID *actual_mech_type, gss_buffer_t output_token, OM_uint32 * r e t _ f l a g s , OM_uint32 * t i m e _ r e c ); Листинг 11.4. Описание ф у н к ц и и GSS_Init_sec_context. 168

Лекция 11

Спецификация Internet-сообщества GSS-API

Отметим, что параметр c o n t e x t _ h a n d l e является здесь одновре­ м е н н о входным и выходным, а основной код завершения возвращается к а к результат ф у н к ц и и . Разумеется, есть еще много аспектов, оговоренных в с п е ц и ф и к а ц и ­ ях [91], например, кто и когда отводит память под объекты и под д е с к р и п ­ торы, и к а к и м образом эту память м о ж н о освобождать. М ы , однако, не будем на этом останавливаться.

169

Курс

Информационная безопасность: основные стандарты и спецификации

Лекция 12. Спецификация Internet-сообщества «Руководство п о и н ф о р м а ц и о н н о й б е з о п а с н о с т и предприятия» Анализируются рекомендации по формированию политики безопаснос­ ти организации, имеющей современную информационную систему и активно использующей сетевые сервисы.

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

Основные понятия М ы приступаем к рассмотрению с п е ц и ф и к а ц и й Internet-сообщест­ ва, относящихся к административному и процедурному уровням и н ф о р ­ м а ц и о н н о й безопасности (см. курс «Основы и н ф о р м а ц и о н н о й безопас­ ности» [3]). Центральное место среди н и х занимает «Руководство п о и н ­ ф о р м а ц и о н н о й безопасности предприятия» ([53], [51]), причем предше­ ствующая (с формальной точки зрения — устаревшая) версия этой специ170

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

ф и к а ц и и , [53], представляется более информативной. В своем изложении м ы опираемся на публикацию [35]. Д а н н о е Руководство призвано помочь организациям, и м е ю щ и м вы¬ ход в Internet, сформировать политику безопасности и разработать соот¬ ветствующие процедуры. В нем перечисляются вопросы и факторы, кото­ р ы е следует предварительно проанализировать, даются некоторые р е к о ­ мендации, обсуждается ряд смежных тем. Руководство содержит л и ш ь основные элементы, необходимые для выработки политики и процедур безопасности. Чтобы получить э ф ф е к ­ т и в н ы й набор защитных средств, ответственным лицам придется принять немало р е ш е н и й , заключить многочисленные соглашения, и л и ш ь после этого довести политику безопасности до сотрудников и приступить к ее реализации. Руководство рассчитано на руководителей и системных администра¬ торов. Основной акцент делается на политику и процедуры, необходимые для поддержки технических средств, выбранных организацией. Слова «организация» и «предприятие» трактуются в нем как синони¬ м ы , обозначающие собственника компьютеров и и н ы х сетевых ресурсов. В число последних входят хосты, на которых работают пользователи, а также маршрутизаторы, терминальные серверы, П К и другие устройства, и м е ю щ и е связь с Internet. Организация может выступать в роли конечного пользователя сер­ висов Internet или поставщиком соответствующих услуг. Тем н е менее, Ру¬ ководство рассчитано в основном на конечных пользователей. Предполагается, что организация способна создавать собственные политику и процедуры безопасности при согласии и поддержке реальных владельцев ресурсов. Термин «системный администратор» относится к тем, кто отвечает за повседневную работу ресурсов. Администрирование может выполнять группа людей и л и независимая к о м п а н и я . П о н я т и е «руководитель» обозначает сотрудника организации, выра­ батывающего и л и одобряющего политику безопасности. Часто (но н е всегда) руководитель одновременно является собственником ресурсов. Документ отвечает на вопросы о том, что входит в политику безопас¬ ности, какие процедуры необходимы для обеспечения безопасности, ч т о нужно делать в ситуациях, угрожающих безопасности. П р и выработке по¬ литики следует помнить н е только о защите локальной сети, н о также о нуждах и требованиях других подсоединенных сетей. Системные администраторы и руководители д о л ж н ы располагать сведениями о современных угрозах, связанных с н и м и рисках, размере возможного ущерба, а также о наборе доступных мер для предотвращения и отражения нападений. 171

Курс

Информационная безопасность: основные стандарты и спецификации

Проблемы, с которыми может столкнуться организация В Руководстве рассматривается гипотетическая, но весьма вероятная последовательность проблем в области и н ф о р м а ц и о н н о й безопасности. • Системный администратор получает сообщение о том, что главный подпольный бюллетень крэкеров распространяется с администра­ тивной м а ш и н ы , находящейся в его ведении, и попадает в пять т ы ­ сяч американских и западноевропейских компьютеров. • Спустя восемь недель тот ж е администратор получает о ф и ц и а л ь н о е уведомление, что и н ф о р м а ц и я из одного бюллетеня была использо­ вана для выведения из строя на пять часов службы «911» в одном из больших городов. • Пользователь звонит и сообщает, что он не может войти в систему под своим именем в 3 часа утра субботы. Администратору также не удается войти в систему. • После перезагрузки и входа в однопользовательский режим он обна¬ руживает, что файл паролей пуст. К утру понедельника выясняется, что между д а н н о й м а ш и н о й и местным университетом в привилеги¬ рованном режиме было передано несколько файлов. • Во вторник утром на университетском компьютере найдена к о п и я стертого файла паролей вместе с аналогичными файлами с д ю ж и н ы других м а ш и н . • Спустя неделю администратор обнаруживает, что ф а й л ы инициали¬ зации системы и з м е н е н ы враждебным образом. • Администратор получает сообщение о том, что в компьютер прави¬ тельственной лаборатории совершено вторжение с подведомствен¬ ной ему м а ш и н ы . Ему предлагают предоставить регистрационную и н ф о р м а ц и ю для отслеживания нападавшего. • Спустя неделю администратор получает список подведомственных компьютеров, подвергшихся успешным атакам крэкеров. • Администратору звонит репортер и интересуется подробностями п р о н и к н о в е н и я на компьютеры организации. Администратор н и ч е ­ го не слышал о таких проникновениях. • Через три д н я выясняется, что случай п р о н и к н о в е н и я имел-таки м е ­ сто. Глава организации использовал в качестве пароля имя жены. • Обнаруживаются м о д и ф и к а ц и и системных бинарных файлов. • После восстановления ф а й л ы в тот ж е день вновь оказываются м о ­ д и ф и ц и р о в а н н ы м и . Так повторяется несколько недель. С подобными проблемами может столкнуться любая организация, и м е ю щ а я выход в Internet. Необходимо иметь заранее заготовленные от­ веты по крайней мере на следующие вопросы: 172

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

• Если в системе обнаруживается присутствие злоумышленника, сле­ дует ли оставить систему открытой и попытаться проследить за н и м , или компьютер нужно немедленно выключить и залатать обнару¬ ж е н н ы е дыры? • Если з л о у м ы ш л е н н и к использует к о м п ь ю т е р ы вашей организа¬ ц и и , д о л ж н ы ли вы обращаться в п р а в о о х р а н и т е л ь н ы е органы? К т о п р и н и м а е т р е ш е н и е о т а к о м о б р а щ е н и и ? Если представитель властей предложит оставить с и с т е м ы о т к р ы т ы м и , кто ответит за это р е ш е н и е ? • К а к и е шаги следует предпринять, если звонят из другой организа­ ц и и и сообщают о подозрительных действиях со стороны одного из ваших пользователей? Что делать, если этим пользователем окажет¬ ся местный системный администратор?

Основы предлагаемого подхода Формирование политики и процедур безопасности означает выра­ ботку плана действий по и н ф о р м а ц и о н н о й защите, для этого необходимо: • выяснить, что следует защищать; • выяснить, от чего следует защищаться; • определить вероятность угроз; • реализовать меры, которые позволят защитить активы экономичес¬ ки оправданным образом; • постоянно возвращаться к предыдущим этапам и совершенствовать защиту после выявления новых уязвимых мест. В рассматриваемом Руководстве основной упор делается на два по¬ следних этапа, однако следует помнить и о критической важности первых трех этапов для принятия э ф ф е к т и в н ы х р е ш е н и й в области безопасности, поскольку стоимость защиты не должна превосходить вероятный ущерб от осуществления угроз. Руководство [53], п о м и м о вводного, содержит еще пять разделов, где обсуждаются вопросы, которые организация должна рассмотреть при вы¬ работке политики безопасности и ф о р м и р о в а н и и процедур, реализую¬ щ и х эту политику. В некоторых случаях анализируются имеющиеся аль¬ тернативы и аргументы в пользу выбора к а к о й - л и б о из них. В плане общей структуры обсуждение политики безопасности пред¬ шествует рассмотрению процедур, необходимых для ее реализации. П е р ­ вый из пяти разделов посвящен особенностям о ф и ц и а л ь н о й политики предприятия, касающейся доступа к вычислительным ресурсам. Рассма­ триваются также вопросы ее нарушения. Политика определяет набор н е ­ обходимых процедур, поэтому руководителю следует сначала разобраться в политических составляющих предмета обсуждения и только после это173

Курс

Информационная безопасность: основные стандарты и спецификации

го переходить к процедурным. Ключевым компонентом ф о р м и р о в а н и я политики безопасности является производимая в той или и н о й форме оценка рисков, позволяющая установить, что необходимо защищать и ка¬ ков объем ресурсов, которые разумно выделить на защиту. Когда политика выработана, м о ж н о приступать к созданию проце¬ дур, р е ш а ю щ и х проблемы безопасности. В разделе «Выработка процедур для предупреждения нарушений безопасности» определяются и предлага­ ются действия, которые необходимо предпринять при возникновении подозрений по поводу совершения неавторизованных операций, и анали­ зируются ресурсы, необходимые для предотвращения нарушений режима безопасности. В разделе «Типы процедур безопасности» перечисляются т и п ы п р о ­ цедур, служащих для предотвращения нападений. П р о ф и л а к т и к а — осно¬ ва безопасности. Раздел «Реакция на нарушения безопасности» п о с в я щ е н реагирова­ н и ю на нарушения безопасности, т. е. кругу вопросов, с которыми орга­ н и з а ц и я сталкивается, когда кто-то отступает от политики безопасности. Если такое случается, приходится принимать целый комплекс р е ш е н и й , но многие из них м о ж н о продумать заранее. П о крайней мере, следует до¬ говориться о распределении обязанностей и способах взаимодействия. И здесь важнейшую роль играет политика безопасности. Тема последнего раздела — м е р ы , п р е д п р и н и м а е м ы е после ликви¬ д а ц и и н а р у ш е н и я безопасности. П л а н и р о в а н и е з а щ и т н ы х действий — это н е п р е р ы в н ы й ц и к л и ч е с к и й п р о ц е с с , поэтому очередной и н ц и д е н т становится п р е к р а с н ы м поводом для пересмотра и улучшения п о л и т и к и и процедур.

Общие принципы выработки официальной политики предприятия в области информационной безопасности Целью ф о р м и р о в а н и я о ф и ц и а л ь н о й п о л и т и к и п р е д п р и я т и я в о б ­ ласти и н ф о р м а ц и о н н о й безопасности я в л я е т с я о п р е д е л е н и е п р а в и л ь ­ ного (с точки з р е н и я о р г а н и з а ц и и ) способа и с п о л ь з о в а н и я вычисли¬ тельных и к о м м у н и к а ц и о н н ы х ресурсов, а т а к ж е разработка процедур, п р е д о т в р а щ а ю щ и х или реагирующих на н а р у ш е н и я р е ж и м а безопасно сти. Ч т о б ы достичь д а н н о й ц е л и , следует учесть с п е ц и ф и к у к о н к р е т н о й организации. Во-первых, необходимо принять во в н и м а н и е ее цели и основные направления деятельности. Н а п р и м е р , на военной базе и в университете требования к конфиденциальности весьма отличаются. 174

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

Во-вторых, разрабатываемая политика должна согласовываться с су­ ществующими законами и правилами, о т н о с я щ и м и с я к организации. Значит, и те, и другие необходимо принять во в н и м а н и е при разработке политики. В-третьих, если локальная сеть организации не изолирована, вопро¬ сы безопасности следует рассматривать в более ш и р о к о м контексте. По¬ литика должна освещать проблемы, в о з н и к а ю щ и е на локальном компью¬ тере из-за действий удаленной стороны, а также удаленные проблемы, п р и ч и н о й которых является локальный хост или пользователь. Политика безопасности призвана стать результатом совместной д е я ­ тельности технического персонала, способного понять все аспекты ее структуры и реализации, а также руководителей, способных влиять на н е ­ уклонное выполнение установленных правил. Нереализуемая или непод­ держиваемая политика бесполезна. Ключевой элемент политики — доведение до каждого сотрудника его обязанностей по поддержанию режима безопасности. Она не может пре­ дусмотреть всего, однако обязана гарантировать, что для любого вида проблем существует ответственный исполнитель. В связи с и н ф о р м а ц и о н н о й безопасностью м о ж н о выделить не¬ сколько уровней ответственности. На первом уровне каждый пользова¬ тель компьютерного ресурса обязан заботиться о защите своего счета. Пользователь, допустивший его компрометацию, увеличивает вероят¬ ность компрометации других счетов и ресурсов. Системные администраторы образуют другой уровень ответственно¬ сти. О н и д о л ж н ы обеспечивать защиту компьютерных систем. Сетевых администраторов м о ж н о отнести к еще более высокому уровню. Важно определить, кто будет интерпретировать политику безопас¬ ности, поскольку вне зависимости от того, насколько хорошо она напи¬ сана, время от времени ее содержание нуждается в разъяснении, а заодно и в пересмотре. После того как все положения записаны и одобрены, необходимо начать активный процесс, гарантирующий, что политика безопасности воспринята и обсуждена. Целесообразно провести собрания, чтобы выслушать пожелания пользователей и заодно убедиться в правильном п о н и м а н и и предложен¬ ных правил. П о м и м о усилий по оглашению политики на начальном этапе, необ¬ ходимо постоянно напоминать о ней. О п ы т н ы е пользователи нуждаются в периодических напоминаниях, новичкам ее нужно разъяснять, вводя в курс дела. Прежде чем допускать сотрудника к работе, разумно заручить¬ ся его подписью, свидетельствующей о том, что с политикой безопаснос­ ти он ознакомился и п о н я л ее суть. 175

Курс

Информационная безопасность: основные стандарты и спецификации

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

176

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

Регламентация использования ресурсов П р и разработке политики безопасности ряд вопросов требует обяза¬ тельных ответов: • Кто имеет право пользоваться ресурсами? • К а к правильно использовать ресурсы? • Кто наделен правом давать привилегии и разрешать использование? • Кто может иметь административные привилегии? • К а к о в ы права и обязанности пользователей? • К а к о в ы права и обязанности системных администраторов по отно­ ш е н и ю к обычным пользователям? • К а к работать с к о н ф и д е н ц и а л ь н о й информацией? После определения круга л и ц , имеющих доступ к системным ресур¬ сам, необходимо описать правильные и неправильные способы их приме¬ н е н и я . Для разных категорий пользователей (студентов, внешних пользо­ вателей, штатных сотрудников и т.д.) эти способы могут различаться. Следует я в н о указать, что допустимо, а что — нет. Пользователи д о л ж н ы знать: о н и несут ответственность за свои дей¬ ствия независимо от применяемых защитных средств, использовать чу¬ ж и е счета и обходить механизмы безопасности запрещено. Для регламентации доступа к ресурсам нужно ответить на следую¬ щ и е вопросы: • Разрешается ли использование чужих счетов? • М о ж н о ли отгадывать чужие пароли? • Допускается ли разрушение сервисов? • Д о л ж н ы ли пользователи предполагать, что если файл доступен на чтение всем, то они имеют право его читать? • Вправе ли пользователи модифицировать чужие ф а й л ы , если по ка¬ к и м - л и б о п р и ч и н а м у них есть доступ на запись? • Обязаны ли пользователи разделять счета? В большинстве случаев ответы на подобные вопросы будут отрица¬ тельными. В политике могут найти отражение авторские и л и ц е н з и о н н ы е пра¬ ва на программное обеспечение. Л и ц е н з и о н н о е соглашение с поставщи­ ком налагает на организацию определенные обязательства; чтобы не на­ рушить их, необходимо приложить некоторые усилия. Тщательно сформулированная политика в области правильного и с ­ пользования ресурсов очень важна: если я в н о не сказано, что запрещено, не удастся доказать, что нежелательные действия пользователя — это на­ рушения. Бывают исключительные случаи, когда в исследовательских целях пользователи или администраторы пытаются «взломать» защиту сервиса 177

Курс

Информационная безопасность: основные стандарты и спецификации

или л и ц е н з и о н н о й программы. Политика должна давать ответ на вопрос, разрешены ли подобные исследования в организации и каковы могут быть их рамки. Применительно к исключительным случаям следует дать ответы на такие вопросы: • Разрешены ли вообще подобные исследования? • Что и м е н н о разрешено: п о п ы т к и п р о н и к н о в е н и я , в ы р а щ и в а н и е червей и вирусов и т.п.? • К а к и м образом д о л ж н ы контролироваться подобные исследования (например, изолировать их в рамках отдельного сегмента сети)? • К а к з а щ и щ е н ы пользователи (в том числе внешние) от подобных ис¬ следований? • К а к получать разрешение на проведение исследований? В случае, если разрешение получено, следует отделить тестируемые сегменты от основной сети предприятия: бесспорно, черви и вирусы нельзя выпускать в производственную сеть. Политика безопасности должна давать ответ на вопрос, кто распоря­ жается правами доступа к сервисам. К р о м е того, необходимо точно знать, какие и м е н н о права этим людям позволено распределять. Существует много возможных схем управления распределением прав доступа к сервисам. П р и выборе подходящей целесообразно п р и ­ нять во в н и м а н и е следующие моменты: • К а к будут распределяться права доступа — централизованно или из нескольких мест? • К а к и е методы предполагается использовать для заведения счетов и запрещения доступа? Наделение пользователей правами доступа — одна из самых уязви­ мых процедур. Прежде всего следует позаботиться, чтобы начальный па­ роль не был легко угадываемым, не являлся функцией от и м е н и пользо­ вателя или его полного имени. Н е стоит автоматически генерировать на¬ чальные пароли, если результат легко предсказуем. Нельзя разрешать пользователям до бесконечности полагаться на начальный пароль. П о возможности следует создавать условия для обяза¬ тельной его замены при первом входе в систему. Одно из р е ш е н и й , которое должно быть тщательно взвешено, отно¬ сится к выбору л и ц , имеющих доступ к административным привилегиям и паролям. Очевидно, подобный доступ полагается системным а д м и н и с ­ траторам, но неизбежны ситуации, когда за привилегиями будут обра­ щаться другие пользователи, что с самого начала следует предусмотреть в политике безопасности. Сотрудники, и м е ю щ и е специальные привилегии, д о л ж н ы быть по¬ дотчетны некоторому должностному лицу. 178

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

Политика безопасности должна содержать положения о правах и обязанностях пользователей применительно к использованию к о м п ь ю ­ терных систем и сервисов предприятия. Д о л ж н о быть я в н о оговорено, что все сотрудники обязаны понимать и выполнять правила безопасной экс¬ плуатации систем. Н и ж е приведен перечень тем, которые целесообразно осветить в д а н н о м разделе политики безопасности: • К а к о в ы о б щ и е р а м к и использования ресурсов? Существуют ли огра­ н и ч е н и я на ресурсы и каковы они? • Что является злоупотреблением с точки зрения производительности системы? • К а к «секретные» пользователи д о л ж н ы охранять свои пароли? • Насколько часто пользователи д о л ж н ы менять пароли? К а к о в ы дру­ гие аналогичные ограничения и требования? • К а к обеспечивается резервное копирование — централизованно или индивидуально? • К а к о й должна быть реакция на случаи просмотра конфиденциаль¬ ной и н ф о р м а ц и и ? • Соблюдается ли конфиденциальность почты? • Какова политика в о т н о ш е н и и неправильно адресованной почты, отправлений по спискам рассылки или в адрес телеконференций? Должен соблюдаться баланс между правом пользователей на тайну и обязанностью системного администратора собирать достаточно и н ф о р ­ м а ц и и для разрешения проблем и расследования случаев нарушения ре­ ж и м а безопасности. Политика должна определять границы, в пределах которых системный администратор вправе исследовать пользовательские ф а й л ы с целью разрешения проблем и для иных нужд, и конкретизиро¬ вать права пользователей. П р и необходимости м о ж н о сформулировать положение относительно обязанности администратора соблюдать кон¬ фиденциальность и н ф о р м а ц и и , полученной при оговоренных в ы ш е об¬ стоятельствах. Следует сообщить пользователям, к а к и е сервисы (при наличии та­ ковых) пригодны для хранения к о н ф и д е н ц и а л ь н о й и н ф о р м а ц и и . Д о л ж ­ н ы рассматриваться различные способы хранения данных (на диске, ф а й ­ ловом сервере и т.д.).

Р е а г и р о в а н и е на н а р у ш е н и я п о л и т и к и б е з о п а с н о с т и (административный уровень) Очевидно, что любая о ф и ц и а л ь н а я политика, вне зависимости от ее о т н о ш е н и я к и н ф о р м а ц и о н н о й безопасности, время от времени наруша­ ется. Нарушение может стать следствием пользовательской небрежности, случайной о ш и б к и , отсутствия должной и н ф о р м а ц и и о текущей полити179

Курс

Информационная безопасность: основные стандарты и спецификации

ке или ее н е п о н и м а н и я . Возможно также, что некое лицо или группа лиц сознательно совершают действия, прямо противоречащие утвержденной политике безопасности. Необходимо заранее определить характер действий, предпринимае¬ мых в случае обнаружения нарушений п о л и т и к и , чтобы они были быст­ р ы м и и правильными, а также организовать расследование и выяснить, как и почему нарушение стало возможным. После этого нужно внести коррективы в систему защиты. Политику безопасности могут нарушать самые разные лица. Неко¬ торые из них являются сотрудниками предприятия, другие нападают и з ­ вне. Полезно определить сами понятия «свои» и «чужие», исходя из адми¬ нистративных, правовых или политических положений. Правильно организованное обучение — лучшая защита. Надо поста¬ вить дело так, чтобы не только внутренние, но и в н е ш н и е легальные пользователи знали положения политики безопасности. Каждое предприятие должно заранее определить набор администра­ тивных с а н к ц и й , применяемых к местным пользователям, нарушающим политику безопасности другой организации, и, кроме того, позаботиться о защите от ответных действий с ее стороны. Для взаимодействия с в н е ш н и м и организациями, в число которых входят правоохранительные органы, другие учреждения, команды «быст­ рого реагирования», средства массовой и н ф о р м а ц и и , политика безопас­ ности предприятия должна содержать специальные процедуры, регла¬ ментирующие, кто имеет право на такие контакты и как и м е н н о о н и со¬ вершаются. Среди прочих нужно дать ответы на следующие вопросы: • Кому поручено разговаривать с прессой? • Когда следует обращаться в правоохранительные органы? • Какого рода сведения об инцидентах могут выходить за пределы ор¬ ганизации? П о м и м о политических положений, необходимо продумать и напи¬ сать процедуры, исполняемые в случае обнаружения нарушений режима безопасности. Когда на организацию совершается нападение, грозящее нарушени­ ем и н ф о р м а ц и о н н о й безопасности, стратегия ответных действий может строиться под влиянием двух противоположных подходов. Если руководство опасается уязвимости предприятия, оно может предпочесть стратегию «защититься и продолжить». Главная ее цель — за¬ щита и н ф о р м а ц и о н н ы х ресурсов и максимально быстрое восстановление нормальной работы пользователей. Действиям нарушителя оказывается максимальное противодействие, дальнейший доступ предотвращается, после чего немедленно начинается процесс о ц е н к и повреждения и вос­ становления. Возможно, придется выключить компьютерную систему, 180

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

закрыть доступ в сеть или предпринять и н ы е жесткие меры. Оборотная сторона медали состоит в том, что пока з л о у м ы ш л е н н и к не выявлен, он может вновь напасть на эту ж е или другую организацию п р е ж н и м или но¬ вым способом. Другой подход, «выследить и осудить», опирается на и н ы е ф и л о ­ с о ф и ю и систему целей: з л о у м ы ш л е н н и к у продолжать свои д е й с т в и я , п о к а о р г а н и з а ц и я н е сможет установить его л и ч н о с т ь . Такой подход приветствуют п р а в о о х р а н и т е л ь н ы е органы. К с о ж а л е н и ю , о н и н е смо¬ гут освободить о р г а н и з а ц и ю от ответственности, если пользователи об¬ ратятся в суд с и с к о м по поводу ущерба, н а н е с е н н о г о их п р о г р а м м а м и данным. Следующий контрольный перечень помогает сделать выбор между стратегиями «защититься и продолжить» и «выследить и осудить». Перечень обстоятельств, обусловливающих стратегию «защититься и продолжить»: • активы организации недостаточно з а щ и щ е н ы ; • продолжающееся вторжение сопряжено с большим ф и н а н с о в ы м ри¬ ском; • нет возможности или намерения осудить злоумышленника; • неизвестен круг пользователей; • пользователи н е о п ы т н ы , а их работа уязвима; • пользователи могут привлечь организацию к суду за нанесенный ущерб. Когда предпочтительна стратегия «выследить и осудить»: • активы и системы хорошо з а щ и щ е н ы ; • имеются качественные резервные к о п и и ; • угроза активам организации меньше потенциального ущерба от бу¬ дущих повторных вторжений; • имеет место скоординированная атака, повторяющаяся с большой частотой и настойчивостью; • организация «притягивает» з л о у м ы ш л е н н и к о в и, следовательно, подвергается частым атакам. • организация готова идти на риск, позволяя продолжить вторжение; • действия злоумышленника м о ж н о контролировать; • доступны развитые средства отслеживания, поэтому преследование нарушителя имеет ш а н с ы на успех; • обслуживающий персонал обладает достаточной к в а л и ф и к а ц и е й для успешного отслеживания; • руководство организации желает осудить злоумышленника; • имеется тесный контакт с правоохранительными органами; • среди сотрудников есть человек, хорошо з н а ю щ и й соответствующие законы; 181

Курс

Информационная безопасность: основные стандарты и спецификации

• организация готова к искам собственных пользователей по поводу программ и данных, скомпрометированных во время выслеживания злоумышленника.

Подход к выработке процедур для предупреждения нарушений безопасности Политика безопасности отвечает на вопрос Ч Т О : Что следует защищать? Что является самым важным? Что за свойства у защищаемых объектов? Что за подход к проблемам безопасности избран? Сама по себе политика безопасности не говорит, К А К защищаются объекты. Ответы на вопросы К А К дают процедуры безопасности. Политика безопасности оформляется в виде высокоуровневого до¬ кумента, описывающего общую стратегию. Процедуры безопасности д о л ж н ы в деталях специфицировать шаги, предпринимаемые организа­ цией для собственной защиты. П о л и т и к а безопасности д о л ж н а включать в себя общую о ц е н к у р и с к о в по о т н о ш е н и ю к н а и б о л е е в е р о я т н ы м угрозам и о ц е н к у в о з м о ж ­ н ы х последствий их осуществления. Ч а с т ь процесса о ц е н к и р и с к о в за­ ключается в составлении с п и с к а а к т и в о в , н у ж д а ю щ и х с я в защите. Д а н ­ н а я и н ф о р м а ц и я необходима для в ы р а б о т к и э к о н о м и ч е с к и эффектив¬ н ы х процедур. Заманчиво начать разработку процедур безопасности, отправля­ я с ь от з а щ и т н ы х м е х а н и з м о в : «На всех к о м п ь ю т е р а х н а ш е й о р г а н и з а ­ ции должны вестись регистрационные журналы, модемы обязаны в ы п о л н я т ь о б р а т н ы й д о з в о н , а всем п о л ь з о в а т е л я м н е о б х о д и м о вы¬ дать и н т е л л е к т у а л ь н ы е к а р т о ч к и » . О д н а к о п о д о б н ы й подход м о ж е т повести к массированной защите областей с небольшим риском и к недостаточной защите действительно уязвимых участков. Если же н а ч а т ь с п о л и т и к и и о п и с а н н ы х е ю р и с к о в , м о ж н о быть у в е р е н н ы м , ч т о п р о ц е д у р ы о б е с п е ч и в а ю т д о с т а т о ч н ы й у р о в е н ь з а щ и т ы д л я всех активов. Чтобы определить р и с к и , необходимо выявить уязвимые места. Од¬ на из целей политики безопасности состоит в том, чтобы их прикрыть и тем самым уменьшить р и с к для максимально возможного числа активов. К числу типичных уязвимостей и их источников относятся: • точки доступа; • неправильно сконфигурированные системы; • программные о ш и б к и ; • внутренние злоумышленники. • • • •

182

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

Выбор регуляторов для практичной защиты После определения объектов защиты и оценки рисков, грозящих ак¬ тивам, необходимо решить, к а к реализовать средства безопасности. Регу¬ ляторы и защитные механизмы следует выбирать так, чтобы успешно и в то же время без излишних затрат противостоять угрозам, в ы я в л е н н ы м в процессе анализа рисков. Выбранные регуляторы представляют собой реальное воплощение по¬ литики безопасности. Они образуют первую (и главную) линию обороны. В этой связи особенно важно, чтобы регуляторы в совокупности составляли правильный набор. Если наибольшая угроза для системы — внешние зло­ умышленники, то нет смысла использовать биометрические устройства для аутентификации обычных, внутренних пользователей. Если, с другой сто¬ роны, основная опасность состоит в неавторизованном использовании вычислительньгх ресурсов внутри предприятия, целесообразно воспользовать­ ся процедурами автоматического учета совершаемых действий. Здравый смысл — лучшее средство формирования политики безопасно­ сти. Тщательная проработка схем и механизмов — занятие увлекательное и в определенной степени необходимое, но едва ли имеет смысл тратить деньги и время на такую проработку, если без внимания остались простые регулято­ ры. Например, как бы тщательно ни была продумана система, построенная на основе существующих средств безопасности, один пользователь с плохо выбранным паролем способен поставить под удар всю организацию. Целесообразно построить эшелонированную оборону, п р и м е н я я н е ­ сколько стратегий защиты. П р и подобном подходе, если одна л и н и я обо­ р о н ы оказывается прорванной, в дело вступает другая — и активы не о с ­ таются беззащитными. К о м б и н а ц и я нескольких простых стратегий зача­ стую позволяет создать более надежный заслон, чем один, даже очень сложный, метод. Если не обеспечена физическая защита, говорить о других аспектах и н ф о р м а ц и о н н о й безопасности не имеет смысла. И м е я доступ к м а ш и н е , з л о у м ы ш л е н н и к может остановить ее, перезагрузить в привилегирован¬ н о м режиме, заменить д и с к или изменить его содержимое и т.п. Критически важные к о м м у н и к а ц и о н н ы е каналы, серверы и другие ключевые элементы д о л ж н ы быть сосредоточены в закрытых помещени¬ ях. Некоторые механизмы безопасности (например, сервер аутентифика­ ц и и Kerberos) выполняют свои ф у н к ц и и только при условии физической защищенности. Для обнаружения большинства видов неавторизованного использо­ вания компьютерных систем существуют несложные процедуры, п р и м е ­ н я ю щ и е стандартные средства операционных систем или опирающиеся на инструментарий, свободно доступный из различных источников. 183

Курс

Информационная безопасность: основные стандарты и спецификации

Системный мониторинг может выполняться как администратором, так и специально н а п и с а н н ы м и программами. Он включает в себя про¬ смотр различных частей системы в поисках чего-нибудь необычного. Отслеживание использования систем очень важно выполнять постоян­ но. Бессмысленно выделять для мониторинга один день в месяце, поскольку нарушения режима безопасности зачастую длятся всего несколько часов. Пользователям необходимо объяснить, к а к выявлять случаи неле­ гального вторжения в их счета. Если при входе в систему выдается время предыдущего входа, о н и д о л ж н ы сопоставить его контролировать со сво¬ и м и п р о ш л ы м и действиями. Д о л ж н ы быть разработаны процедуры, позволяющие докладывать о замеченных проблемах, связанных с неправильным использованием сче¬ та или с другими аспектами безопасности. Отслеживайте состояние привилегированных счетов («root» в О С U N I X ) . К а к только привилегированный пользователь увольняется или перестает нуждаться в привилегиях, следует изменить пароли всех при¬ надлежавших ему счетов. При установке с дистрибутива операционной системы или дополнитель¬ ного программного продукта необходимо тщательно проверить результирую¬ щую конфигурацию. Многие процедуры установки исходят из предположения, что всем пользователям в организации можно доверять, оставляя файлы обще­ доступными для записи или иным способом компрометируя безопасность. Тщательной проверке д о л ж н ы подвергаться и сетевые сервисы. Час¬ то поставщики в стандартной конфигурации предполагают надежность всех внешних хостов, что едва ли разумно, если речь идет о такой глобаль¬ ной сети, как Internet. М н о г и е злоумышленники собирают и н ф о р м а ц и ю о слабостях к о н ­ кретных версий систем. Ч е м старее версия, тем вероятнее наличие в ее за¬ щите известных ошибок, исправленных поставщиком в более поздних выпусках. В этой связи необходимо сопоставить р и с к от сохранения ста¬ рой версии (с «дырами» в безопасности) и стоимость перехода на новое программное обеспечение (включая возможные проблемы с продуктами неизвестных производителей). Точно так ж е оценивается и целесообраз­ ность постановки «заплат», предоставляемых поставщиком, но с учетом того обстоятельства, что заплаты к системе безопасности, как правило, закрывают действительно серьезные дыры. Невозможно переоценить важность хорошей стратегии резервного копирования. Резервные к о п и и , особенно ежедневные, могут быть п о ­ лезны, п о м и м о прочего, и для прослеживания действий з л о у м ы ш л е н н и ­ ков. Анализируя старые к о п и и , нетрудно выяснить, когда система была скомпрометирована в первый раз. Резервные к о п и и — это и материал для правоохранительных органов. 184

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

Ресурсы для предупреждения нарушений безопасности Конфиденциальность, т. е. обеспечение скрытности или секретности, — одна из главных практических целей информационной безопасности. К а к правило, с и н ф о р м а ц и е й могут н е с а н к ц и о н и р о в а н н о ознако¬ миться в трех местах: • там, где она хранится (на компьютерных системах); • там, где она передается (в сети); • там, где хранятся резервные к о п и и . В первом случае для защиты используются права доступа к файлам, списки управления доступом и / и л и аналогичные механизмы. В послед­ н е м возможно физическое ограничение доступа. И во всех случаях по¬ м о щ ь способны оказать криптографические средства. Обычно м ы принимаем на веру, что в заголовке электронного сооб¬ щ е н и я отправитель указан правильно. Заголовок, однако, нетрудно под­ делать. Аутентификация источника данных позволяет удостоверить под­ линность отправителя сообщения или другого объекта. Говорят, что информация находится в целостном состоянии, если она полна, корректна и не изменилась с момента последней проверки «цельности». На целостность системной и н ф о р м а ц и и влияют многочисленные п р о г р а м м н о - т е х н и ч е с к и е и процедурные м е х а н и з м ы . Т р а д и ц и о н н ы е средства управления доступом обеспечивают контроль над тем, кто имеет доступ к системной и н ф о р м а ц и и . Необходимо также ограничение сете¬ вого доступа. Дополнительно могут использоваться простые или крипто¬ графические контрольные суммы (имитовставки). Ш и р о к спектр механизмов аутентификации. В простейшем случае в роли такового выступает системный администратор, заводящий новые пользовательские счета. На другом конце спектра находятся высокотехно­ логичные системы распознавания отпечатков пальцев и сканирования р о ­ говицы потенциальных пользователей. В некоторых системах для облегче­ н и я аутентификации применяются интеллектуальные карты. Здесь подлин­ ность пользователя подтверждается обладанием определенным объектом. Политика управления паролями важна для поддержания их секрет­ ности. Соответствующие процедуры могут варьироваться от эпизодичес¬ ких просьб или приказаний пользователю сменить пароль до активных п о п ы т о к этот пароль подобрать с последующим и н ф о р м и р о в а н и е м вла¬ дельца о легкости в ы п о л н е н и я данного действия. Другая часть политики управления описывает, кто может распространять пароли. Некоторые системы программным образом вынуждают пользовате¬ лей регулярно менять пароли. К о м п о н е н т о м многих из них является гене¬ ратор паролей. 185

Курс

Информационная безопасность: основные стандарты и спецификации

К о н ф и г у р а ц и о н н о е управление, которое обычно применяют в п р о ­ цессе разработки программного обеспечения, полезно и на этапе эксплу¬ атации. Поскольку довольно часто системные программы предназначены для проведения в ж и з н ь политики безопасности, необходима уверенность в их корректности. К о н ф и г у р а ц и о н н о е управление разумно применять и к физическо¬ му конфигурированию аппаратуры. Иногда (например, на экранирующих системах) для противостояния стандартным атакам полезно ввести в конфигурацию небольшие нестан¬ дартности, в число которых могут входить оригинальный алгоритм шифро¬ вания паролей, необычное расположение конфигурационных файлов, а так¬ же переписанные или функционально ограниченные системные команды. Проверки безопасности (контроль защищенности) — важная часть ф у н к ц и о н и р о в а н и я любой компьютерной среды. Элементом таких п р о ­ верок должна стать ревизия политики безопасности и защитных механиз­ мов, используемых для ее реализации. Периодически нужно проводить плановые учения, чтобы проверить, адекватны ли выбранные процедуры безопасности предполагаемым угрозам. В процессе проверок необходимо с максимальной тщательностью подбирать тесты политики безопасности, четко определить, что тестиру¬ ется, как проводится тестирование и какие результаты ожидаются. Все это нужно документировать, включить в основной текст политики безо¬ пасности или издать в качестве дополнения. Важно протестировать все аспекты политики безопасности, проце¬ дурные и программно-технические, с упором на автоматизированные ме¬ ханизмы проведения политики в ж и з н ь . Должна быть уверенность в п о л ­ ноте тестирования каждого средства защиты.

Р е а г и р о в а н и е на н а р у ш е н и я б е з о п а с н о с т и (процедурный уровень) Традиционная и н ф о р м а ц и о н н а я безопасность, как правило, к о н ­ центрируется вокруг защиты от атак и, до некоторой степени, вокруг их обнаружения. Обычно почти не уделяют в н и м а н и я мерам, предпринима­ емым во время уже начавшейся атаки. В результате поспешных, непроду­ м а н н ы х действий могут быть затруднены выявление п р и ч и н ы инцидента, сбор улик для расследования, подготовка к восстановлению системы и за¬ щита ц е н н о й и н ф о р м а ц и и . Враждебные а к ц и и , будь то нападение внешних злоумышленников или месть обиженного сотрудника, необходимо предусмотреть заранее. Ничто не может заменить предварительно составленного плана восстано¬ вительных работ. 186

Лекция 12

Спецификация Internet-сообщества «Руководство по ИБ предприятия»

В разделах политики безопасности, касающихся реакции на инци¬ денты, д о л ж н ы быть освещены следующие темы: • обзор (цели, преследуемые политикой безопасности в плане реак¬ ц и и на инциденты); • оценка (насколько серьезно произошедшее событие); • извещение (кого следует известить о нем); • ответные меры (что следует предпринять в ответ); • правовой аспект (каковы правовые последствия случившегося); • регистрационная документация (что следует фиксировать до, во вре­ мя и после инцидента). В а ж н о з а р а н е е о п р е д е л и т ь п р и о р и т е т ы д е й с т в и й , с о в е р ш а е м ы х во в р е м я и н ц и д е н т а . Ш к а л а п р и о р и т е т о в может выглядеть с л е д у ю щ и м образом: • защита ж и з н и и здоровья людей; • защита секретных и / и л и критически важных данных; • защита прочих данных, включая частную, научную и управленчес¬ кую и н ф о р м а ц и ю ; • предотвращение повреждения систем; • м и н и м и з а ц и я урона, нанесенного вычислительным ресурсам. И д е н т и ф и к а ц и и инцидента сопутствует выяснение его масштабов и возможных последствий, а для эффективного противодействия важно правильно определить его границы. К р о м е того, оценка возможных по¬ следствий позволит установить приоритеты при выделении ресурсов для п р и н я т и я ответных мер. Когда есть уверенность, что нарушение режима безопасности дейст¬ вительно имеет место, следует известить соответствующий персонал. Ч т о б ы удержать события под контролем и с технической, и с э м о ц и о ­ нальной точек зрения, очень важно, кто и как будет извещен. Л ю б о е с о о б щ е н и е об и н ц и д е н т е д о л ж н о быть в н я т н ы м , л ю б а я фраза — ясной, точной и полной. Попытки скрыть отдельные момен­ ты, сообщая ложную или неполную информацию, способны не только п о м е ш а т ь п р и н я т и ю э ф ф е к т и в н ы х ответных м е р , н о и п р и в е с т и к ухудшению ситуации. М е р ы , предпринимаемые для борьбы с нарушением, м о ж н о подраз¬ делить на основные категории: • сдерживание; • ликвидация; • восстановление; • анализ. Цель сдерживания — ограничить атакуемую область. Н а п р и м е р , как м о ж н о быстрее приостановить распространение червя в сети.

187

Курс

Информационная безопасность: основные стандарты и спецификации

Когда задача сдерживания решена, м о ж н о приступать к ликвидации. В этом поможет программный инструментарий (в частности, антивирус¬ н ы е пакеты). После ликвидации атаки наступает время восстановления, т. е. п р и ­ ведения системы в нормальное состояние. Следует предпринять по крайней мере следующие действия: • произвести переучет системных активов, т. е. тщательно проверить состояние систем; • отразить уроки, извлеченные из инцидента, в пересмотренной про¬ грамме обеспечения безопасности, чтобы не допустить повторения аналогичного нарушения; • произвести новый анализ риска с учетом полученной и н ф о р м а ц и и ; • начать следствие против в и н о в н и к о в инцидента, если это признано необходимым. Устранить все уязвимые места, сделавшие возможным нарушение режима безопасности, непросто, но необходимо. Ключевым моментом здесь является п о н и м а н и е механизма вторжения. П р и восстановлении, возможно, придется вернуться к начальному состоянию системы с последующей ее настройкой. Чтобы облегчить д е й ­ ствия даже в таком, наихудшем, случае, целесообразно хранить записи о начальных установках и обо всех внесенных изменениях. Анализ — одна из самых важных стадий реакции на и н ц и д е н т ы , о ко¬ торой, тем не менее, почти всегда забывают. Она важна потому, что поз¬ воляет всем причастным лицам извлечь поучительные уроки, чтобы в бу­ дущем в аналогичных ситуациях действовать эффективнее. Требуется получить ответы по крайней мере на следующие вопросы: • Что и м е н н о и когда произошло? • Насколько хорошо сработал персонал? • Какая срочная и н ф о р м а ц и я понадобилась в первую очередь, и что способствовало ее скорейшему получению? • Что в следующий раз нужно делать по-другому? После восстановления системы в ней нередко остаются уязвимости или даже ловушки. Н а фазе анализа система должна быть тщательно об¬ следована, чтобы выявить проблемы, упущенные при восстановлении. В качестве отправной точки разумно воспользоваться программными сред­ ствами контроля защищенности. Целесообразно документировать все детали, связанные с и н ц и д е н ­ том: способы его обнаружения, процедуры исправления ситуации, про¬ цедуры мониторинга и усвоенные уроки. Детальное документирование в конечном итоге ведет к э к о н о м и и времени, позволяет оценить размер на¬ несенного ущерба.

188

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

Лекция 13. Спецификация Internet-сообщества «Как р е а г и р о в а т ь на н а р у ш е н и я и н ф о р м а ц и о н н о й безопасности» Рассматривается взаимодействие групп реагирования на нарушения ин­ формационной безопасности и опекаемого сообщества во время ликвидации нарушений; анализируются используемые при этом документы, правила и процедуры.

Ключевые слова: нарушение и н ф о р м а ц и о н н о й безопасности, группа реагирования на нарушения и н ф о р м а ц и о н н о й безопасности, опека­ емое сообщество, потеря конфиденциальности, нарушение целост¬ ности, нарушение доступности, неправомочное использование, по¬ вреждение, атака, доклад о нарушении, разделение и н ф о р м а ц и и , и н ф о р м а ц и о н н ы й сервер, аутентичность, криптографический ключ, ц и ф р о в а я п о д п и с ь , межгрупповое в з а и м о д е й с т в и е , д о в е р е н н ы е к о м м у н и к а ц и и , правило, процедура, шаблон, бланк, с п и с о к рассыл¬ ки, виды деятельности, клиентура, спонсор, вышестоящая организа­ ц и я , полномочия, тип нарушения, уровень поддержки, раскрытие и н ф о р м а ц и и , поставщик, персональные д а н н ы е , и н ф о р м а ц и я о зло­ у м ы ш л е н н и к е , и н ф о р м а ц и я о частной системе, и н ф о р м а ц и я об уязвимостях, и н ф о р м а ц и я , бросающая тень, статистическая и н ф о р м а ­ ц и я , контактная и н ф о р м а ц и я , действия в реальном времени, п р о ф и ­ лактические действия, классификация нарушений, оценка докла­ дов, в е р и ф и к а ц и я , координация реагирования, категорирование и н ­ ф о р м а ц и и , разрешение проблем, техническая поддержка, искорене¬ ние проблем, восстановление, обучение и подготовка кадров, оцен¬ ка продуктов, оценка з а щ и щ е н н о с т и , консультационные услуги, ф о р м ы для докладов о нарушениях. Тема реагирования на нарушения и н ф о р м а ц и о н н о й безопасности исключительно важна, н о , на н а ш взгляд, о н а пока н е получила достаточ­ ного освещения в отечественной литературе. Детальное рассмотрение с п е ц и ф и к а ц и и Internet-сообщества «Как реагировать на нарушения и н ­ ф о р м а ц и о н н о й безопасности» [39] призвано отчасти восполнить этот пробел. В последующем изложении использована публикация [13]. Цель интересующей нас с п е ц и ф и к а ц и и — сформулировать ожида¬ н и я Internet-сообщества по о т н о ш е н и ю к группам реагирования на нару­ ш е н и я и н ф о р м а ц и о н н о й б е з о п а с н о с т и (Computer Security Incident Response Teams, CSIRTs). Потребители имеют законное право (и необхо189

Курс

Информационная безопасность: основные стандарты и спецификации

димость) досконально понимать правила и процедуры работы «своей» группы реагирования. Словосочетание «группа реагирования на нарушения и н ф о р м а ц и о н ­ ной безопасности» обозначает группу, выполняющую, координирующую и поддерживающую реагирование на нарушения, затрагивающие инфор¬ м а ц и о н н ы е системы в пределах определенной зоны ответственности. Коллектив, называющий себя группой реагирования, обязан долж­ н ы м образом отвечать на выявленные нарушения безопасности и на угро­ зы своим подопечным, действуя в интересах конкретного сообщества и способами, п р и н я т ы м и в этом сообществе. Чтобы считаться группой реагирования, необходимо: • предоставлять ( з а щ и щ е н н ы й ) канал для приема сообщений о пред­ полагаемых нарушениях; • помогать членам опекаемого сообщества в ликвидации нарушений; • распространять и н ф о р м а ц и ю , относящуюся к нарушению, среди представителей опекаемого сообщества и других заинтересованных сторон. Деятельность группы реагирования предполагает наличие опекаемо го сообщества — группы пользователей, систем, сетей или организаций. Существуют разные виды групп реагирования. Некоторые заботятся о безопасности весьма о б ш и р н ы х сообществ. Так, К о о р д и н а ц и о н н ы й центр C E R T (Computer Emergency Response Team, см. http://www.cert.org) опекает Internet. У других масштабы деятельности н е столь велики (на­ пример, группа D F N - C E R T поддерживает немецкую исследовательскую сеть D F N , см. http://www.cert.dfn.de), у коммерческих или корпоративных групп реагирования о н и могут быть совсем небольшими. Группы реагиро­ вания и безопасности координируют свою работу на всемирном форуме — F I R S T (Forum of Incident Response and Security Teams, см. http://www.first.org/). Под нарушением и н ф о р м а ц и о н н о й безопасности понимается лю¬ бой вид компрометации каких-либо аспектов безопасности систем и / и л и сетей, к их числу относятся: • потеря конфиденциальности и н ф о р м а ц и и ; • нарушение целостности и н ф о р м а ц и и ; • нарушение доступности и н ф о р м а ц и о н н ы х услуг; • неправомочное использование услуг, систем и л и и н ф о р м а ц и и ; • повреждение систем. Атаки, даже если о н и оказались неудачными из-за правильно пост¬ р о е н н о й защиты, могут трактоваться к а к нарушения. И н о г д а а д м и н и с т р а т о р может л и ш ь подозревать н а р у ш е н и е . В п р о ц е с с е р е а г и р о в а н и я необходимо установить, действительно л и о н о и м е л о место. 190

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

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

Взаимодействие между группой реагирования, опекаемым сообществом и другими группами Каждый пользователь услуг группы реагирования на нарушения и н ­ ф о р м а ц и о н н о й безопасности должен заранее, задолго до возникновения реального инцидента, узнать как м о ж н о больше об этих услугах и поряд­ ке взаимодействия с группой. Я с н о е изложение правил и процедур помогает пользователям п о ­ нять, как сообщать о нарушениях и какую поддержку ожидать. Окажет ли группа содействие в расследовании инцидента? Поможет ли она избежать подобных нарушений в будущем? Доскональное п о н и м а н и е ее возмож¬ ностей и ограничений в предоставляемых услугах сделает взаимодействие между пользователями и группой более э ф ф е к т и в н ы м . Целесообразно, чтобы каждая группа реагирования разместила ре¬ комендации и процедуры на своем и н ф о р м а ц и о н н о м сервере (например, на Web-сервере). Тем самым пользователи получат свободный доступ к документам, хотя остается проблема поиска «своей» группы. Независимо от источника, пользователь должен проверять аутентич­ ность и н ф о р м а ц и и о группе. Настоятельно рекомендуется защищать по¬ д о б н ы е ж и з н е н н о важные документы ц и ф р о в о й подписью, чтобы убе¬ диться, что они на самом деле опубликованы определенной группой реа­ гирования и их целостность не была нарушена. 191

Курс

Информационная безопасность: основные стандарты и спецификации

В некоторых случаях группа реагирования может э ф ф е к т и в н о рабо¬ тать л и ш ь в тесном взаимодействии с опекаемым сообществом. Н о в ус¬ ловиях современных международных сетей гораздо более вероятно, что в большинство нарушений будут вовлечены третьи стороны. Межгрупповое взаимодействие может включать в себя получение рекомендаций от других групп, распространение з н а н и й о в о з н и к ш и х проблемах, а также совместную работу по ликвидации нарушения, затро¬ нувшего одно или несколько опекаемых сообществ. П р и установлении взаимоотношений, обеспечивающих подобное взаимодействие, группы д о л ж н ы решить, какого рода соглашения могут существовать между н и м и (например, как разделяется и н ф о р м а ц и я о за­ щите, может ли раскрываться факт существования взаимоотношений, и если может, то перед кем). После того к а к одна из сторон решила разделять и н ф о р м а ц и ю с дру¬ гой либо две стороны заключили соглашение о разделении и н ф о р м а ц и и или совместной работе, к а к того требует скоординированная реакция на нарушение и н ф о р м а ц и о н н о й безопасности, появляется необходимость в доверенных к о м м у н и к а ц и о н н ы х каналах. Цели организации доверенных к о м м у н и к а ц и й состоят в следующем: • обеспечение конфиденциальности; • обеспечение целостности; • обеспечение аутентичности. Важный фактор эффективной защиты — обеспечение аутентичности криптографических ключей, используемых в доверенных коммуникациях. К о м м у н и к а ц и и критичны для всех аспектов реагирования. Группа может действовать наилучшим образом, только собрав и систематизиро¬ вав всю относящуюся к делу и н ф о р м а ц и ю . С п е ц и ф и ч е с к и е требования (в частности, звонок по определенному номеру для проверки аутентичности ключей) д о л ж н ы быть оговорены с самого начала.

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

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

• дата последнего изменения; она необходима для проверки актуальности сведений, поскольку детали работы группы со временем изменяются; • список рассылки; почтовые списки — удобное средство распростра­ н е н и я обновлений среди большого числа пользователей, обычно в них перечислены коллективы, с которыми группа реагирования ак¬ тивно взаимодействует; • расположение документа; текущая версия документа должна быть доступна в рамках оперативных и н ф о р м а ц и о н н ы х сервисов группы. В таком случае пользователи смогут легко получить дополнительную и н ф о р м а ц и ю о группе, проанализировать недавние изменения. В следующем разделе бланков должна быть приведена исчерпываю¬ щ а я контактная и н ф о р м а ц и я : • название группы реагирования; • почтовый адрес; • часовой пояс (эта и н ф о р м а ц и я полезна при реакции на нарушения, затрагивающие несколько часовых поясов); • номер телефона; • номер факса; • адрес электронной почты; • открытые ключи и способы ш и ф р о в а н и я ; использование конкрет¬ ных механизмов зависит от того, доступны ли партнерам по комму¬ н и к а ц и я м соответствующие программы, ключи и т.п. Наличие п о ­ добной и н ф о р м а ц и и дает возможность пользователям определить, способны ли они организовать з а щ и щ е н н о е взаимодействие с груп¬ пой реагирования и к а к и м образом это сделать; • ч л е н ы группы; • ч а с ы работы. Может быть представлена более детальная контактная и н ф о р м а ц и я , например, разные способы контакта для разных услуг, с п и с о к оператив¬ ных и н ф о р м а ц и о н н ы х сервисов и т.п. Каждая группа реагирования должна иметь устав, который опреде­ ляет, что она должна делать и на каком основании. В уставе д о л ж н ы при¬ сутствовать по крайней мере следующие разделы: • виды деятельности; • клиентура; • спонсоры и вышестоящие организации; • полномочия. Определение клиентуры должно задать р а м к и , в пределах которых группа будет предоставлять свои услуги. Сообщества пользователей могут пересекаться. Н а п р и м е р , постав­ щ и к услуг Internet обеспечивает реагирование для своих потребителей, возможно, имеющих собственные группы. 193

Курс

Информационная безопасность: основные стандарты и спецификации

Сведения о компаниях-спонсорах и вышестоящих организациях п о ­ могут пользователям выяснить возможности группы, что необходимо для ф о р м и р о в а н и я доверительных о т н о ш е н и й с клиентами. П о л н о м о ч и я существенно зависят от с п е ц и ф и к и группы. Н а п р и м е р , компетенция корпоративной группы определяется руководством, о б щ е ­ ственная группа может поддерживаться и выбираться на началах само­ управления, играть консультативную роль и т.п. Н е все группы наделяются правами на вмешательство в работу всех систем в пределах контролируемого периметра. И н ы м и словами, область управления отличается от круга пользователей; в других случаях она мо¬ жет быть устроена иерархически, и тогда этот факт нужно зафиксировать с указанием подчиненных групп. О п и с а н и е п о л н о м о ч и й группы может сделать ее уязвимой д л я су­ дебных и с к о в , поэтому в д а н н о м вопросе следует опираться н а п о м о щ ь юристов. В рассматриваемой с п е ц и ф и к а ц и и приводится пример устава для в ы м ы ш л е н н о й группы реагирования X Y Z - C E R T университета X Y Z . Виды деятельности. Целью группы X Y Z - C E R T является п о м о щ ь со¬ трудникам университета X Y Z в реализации профилактических мер, сни¬ ж а ю щ и х р и с к нарушений и н ф о р м а ц и о н н о й безопасности, и п о м о щ ь в реагировании на все-таки п р о и з о ш е д ш и е нарушения. Клиентура. Опекаемое сообщество группы X Y Z - C E R T — сотрудни¬ ки, студенты и аспиранты университета X Y Z . Это определено в политике университета по о т н о ш е н и ю к вычислительным ресурсам, с н е й м о ж н о ознакомиться по адресу http://www.../policies/pcf.html. Услуги группы рас­ пространяются только на производственные системы. С п о н с о р ы и в ы ш е с т о я щ и е организации. С п о н с о р о м группы X Y Z C E R T является к о м п а н и я A C M E Canadian Research Network, предлага­ ю щ а я свои услуги в К а н а д е и С Ш А в качестве в ы ш е с т о я щ е й организа­ ц и и д л я различных университетских групп р е а г и р о в а н и я , если о н и того пожелают. П о л н о м о ч и я . Группа X Y Z - C E R T работает п о д п о к р о в и т е л ь с т в о м и с п о л н о м о ч и я м и , д е л е г и р о в а н н ы м и отделом к о м п ь ю т е р н ы х услуг университета X Y Z . П р е д п о л а г а е т с я , что X Y Z - C E R T взаимодействует с с и с т е м н ы м и а д м и н и с т р а т о р а м и и п о л ь з о в а т е л я м и университета X Y Z и, п о в о з м о ж н о с т и , избегает а в т о р и т а р н ы х р е ш е н и й . О д н а к о , п о д дав¬ л е н и е м обстоятельств, ч л е н ы группы могут обратиться в отдел к о м ­ п ь ю т е р н ы х услуг, ч т о б ы «употребить власть». Все о н и входят в к о м и т е т системных администраторов и сполна наделены правами и обязаннос­ т я м и , п о л а г а ю щ и м и с я а д м и н и с т р а т о р а м в ы ч и с л и т е л ь н ы х ресурсов в соответствии с п о л и т и к о й , л и б о п р е д с т а в л е н ы в руководстве универ¬ ситета. Ч л е н ы у н и в е р с и т е т с к о г о сообщества, ж е л а ю щ и е обжаловать 194

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

д е й с т в и я группы X Y Z - C E R T , д о л ж н ы обратиться к заместителю ди¬ р е к т о р а по т е х н и ч е с к и м в о п р о с а м и л и в у н и в е р с и т е т с к о е бюро п р а в и обязанностей.

Описание правил группы реагирования Критически важно, чтобы группа реагирования определила свои правила, которые регламентируют следующие аспекты: • т и п ы нарушений и уровень поддержки; • кооперация, взаимодействие и раскрытие и н ф о р м а ц и и ; • коммуникации и аутентификация. Д о л ж н ы быть с п е ц и ф и ц и р о в а н ы т и п ы нарушений, на которые груп¬ па способна реагировать, а также уровень поддержки, предоставляемой для каждого из заданных типов. Уровень поддержки может меняться в зависимости от таких факто¬ ров, как загруженность группы и полнота доступной и н ф о р м а ц и и . По¬ д о б н ы е факторы д о л ж н ы быть о п и с а н ы , а их влияние разъяснено. П о ­ скольку список известных типов нарушений нельзя составить в исчерпы¬ вающей полноте по о т н о ш е н и ю ко всем возможным или будущим инци¬ дентам, необходимо описать поддержку для «прочих» нарушений. Следует определить, будет ли группа действовать на основе получае¬ мой и н ф о р м а ц и и об уязвимостях, которые делают в о з м о ж н ы м и будущие нарушения. Согласие учитывать такую и н ф о р м а ц и ю в интересах своих пользователей рассматривается как дополнительная профилактическая услуга, а не как обязательный сервис. П о поводу кооперации, взаимодействия и раскрытия и н ф о р м а ц и и необходимо проинформировать пользователей, с к а к и м и родственными группами налажено взаимодействие. Правила докладов и раскрытия и н ф о р м а ц и и д о л ж н ы разъяснять, кто и в каких случаях имеет право получать доклады группы, предполага­ ется ли работа силами другой группы или непосредственное взаимодейст­ вие с членом другого сообщества по вопросам, касающимся и м е н н о это­ го пользователя. Необходимость взаимодействия с другими группами реагирования возникает часто. Н а п р и м е р , корпоративная группа сообщает о наруше­ н и и национальной группе, которая, в свою очередь, передает доклад в другие страны, чтобы охватить все и н ф о р м а ц и о н н ы е системы, ставшие жертвами широкомасштабной атаки. У некоторых поставщиков есть собственные группы реагирования, у других нет. В последнем случае группа должна работать непосредственно с поставщиком, чтобы предложить улучшения или и з м е н е н и я , проанали¬ зировать техническую проблему или протестировать предлагаемые р е ш е 195

Курс

Информационная безопасность: основные стандарты и спецификации

ния. Если продукты поставщика оказываются вовлеченными в наруше¬ ние, о н играет особую роль в реагировании. Группы реагирования и пользователи д о л ж н ы соблюдать действую­ щее законодательство, которое существенно различается в разных стра­ нах. Группа реагирования может давать рекомендации по техническим д е ­ талям атаки или запрашивать совета по правовым последствиям наруше­ ния. В законодательстве нередко содержатся специфические требования к предоставлению докладов и соблюдению конфиденциальности. Время от времени от прессы поступают запросы на и н ф о р м а ц и ю и комментарии. Я в н ы е правила, касающиеся передачи и н ф о р м а ц и и такого рода, весьма полезны; о н и д о л ж н ы разъяснять все вопросы как м о ж н о подробнее, поскольку пользователи весьма болезненно воспринимают контакты с журналистами. Подразумеваемый статус любых сведений, получаемых группой и имеющих отношение к информационной безопасности, — «конфиденци¬ ально», однако, строгое следование этому положению превращает группу в информационную «черную дыру», что может уменьшить ее привлекатель¬ ность как партнера для пользователей и других организаций. Необходимо определить, что именно докладывается или раскрывается, кому и когда. Возможно, разные группы будут являться субъектами разного зако­ нодательства, требующего раскрытия и н ф о р м а ц и и или, напротив, огра¬ ничивающего его, особенно, если речь идет о группах из разных стран. К р о м е того, о н и могут руководствоваться требованиями на доклады, н а ­ лагаемыми спонсорскими организациями. Все такие ограничения долж­ н ы быть с п е ц и ф и ц и р о в а н ы , чтобы прояснить ситуацию для пользовате¬ лей и других групп. Необходимо иметь политику, определяющую методы защиты и к о н ­ троля к о м м у н и к а ц и й . Это важно для взаимодействия как между группа­ ми, так и между группой и пользователями. В дополнение к максимально полному ш и ф р о в а н и ю критичной и н ф о р м а ц и и ее следует снабжать циф¬ ровой подписью. Для упомянутой в ы ш е в ы м ы ш л е н н о й группы реагирования X Y Z C E R T определены специальные правила. Типы нарушений и уровень поддержки. Группа X Y Z - C E R T уполно¬ мочена заниматься всеми видами нарушений безопасности, а также угро¬ зами нарушений в университете X Y Z . Уровень поддержки, предоставляемой группой X Y Z - C E R T , зависит от типа и серьезности нападения, типа опекаемого сообщества, числа п о ­ страдавших, а также от количества наличных ресурсов, хотя в любом слу­ чае некоторый ресурс в течение рабочего д н я будет выделен. Ресурсы в ы ­ деляются в соответствии со следующими приоритетами, перечисленны¬ ми по убыванию: 196

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

• угрозы физической безопасности людей; • атаки на уровне суперпользователя или системном уровне на любую административную и н ф о р м а ц и о н н у ю систему или часть инфраст¬ руктуры магистральной сети; • атаки на уровне суперпользователя или системном уровне на любую машину, предоставляющую крупный сервис, многопользователь¬ ский или специализированный; • компрометация конфиденциальных счетов пользователей на сервисах ограниченного доступа или компрометация установок программного обеспечения, особенно тех, что используются администраторами и приложениями, работающими с конфиденциальными данными; • атака на доступность сервисов, перечисленных в предыдущем пункте; • любое из перечисленных в ы ш е нападений, направленных на другие системы и исходящих из университета X Y Z ; • масштабные атаки любого типа, например: перехват пакетов, атаки в IRC путем морально-психологического воздействия, атаки на пароли; • угрозы, п р и ч и н е н и е беспокойства и другие противоправные дейст¬ вия, направленные на отдельных пользователей; • компрометация отдельных счетов пользователей в многопользова¬ тельских системах; • компрометация настольных систем; • подделка, неправильное представление и другие относящиеся к бе­ зопасности нарушения местных правил: подделка новостей и элек¬ тронной почты, н е с а н к ц и о н и р о в а н н о е использование роботов I R C ; • атака на доступность отдельных счетов пользователей, в частности п р и м е н е н и е почтовых бомб. Типы нарушений, не перечисленные выше, получают приоритет в соответствии со своей наблюдаемой серьезностью и масштабом. Непосредственная п о м о щ ь к о н е ч н ы м пользователям не предостав­ ляется; предполагается, что они будут взаимодействовать со своим сис¬ т е м н ы м или сетевым администратором или уполномоченным по отделу. С этими сотрудниками X Y Z - C E R T и будет работать. В группе понимают, что уровень подготовки системных администра¬ торов в университете X Y Z может быть очень разным. Группа X Y Z - C E R T намерена предоставлять и н ф о р м а ц и ю и п о м о щ ь в форме, п о н я т н о й всем, тем не менее, она не может повышать к в а л и ф и к а ц и ю администраторов «на лету», равно как и администрировать системы вместо них. В боль¬ шинстве случаев предоставляются ссылки на и н ф о р м а ц и ю , необходимую для п р и н я т и я соответствующих мер. Группа X Y Z - C E R T стремится информировать системных админист­ раторов университета X Y Z о потенциальных уязвимостях, по возможнос­ ти до того, как их используют для нападений. 197

Курс

Информационная безопасность: основные стандарты и спецификации

Кооперация, взаимодействие и раскрытие и н ф о р м а ц и и . Существу­ ют законодательные и этические ограничения на раскрытие и н ф о р м а ц и и группой X Y Z - C E R T (многие из этих ограничений упомянуты в политике университета по о т н о ш е н и ю к вычислительным ресурсам; безусловно, все они будут соблюдаться), но группа подтверждает свою привержен­ ность духу сотрудничества, создавшему Internet. Поэтому, п р и н и м а я н е ­ обходимые меры для сокрытия личной и н ф о р м а ц и и членов опекаемого сообщества и организаций-партнеров, группа, по возможности, станет свободно разделять и н ф о р м а ц и ю , если это целесообразно с точки зрения отражения или предупреждения нападений. Далее в тексте под «пострадавшими сторонами» понимаются закон¬ н ы е владельцы, операторы и пользователи вычислительных систем. В этот круг не входят неавторизованные пользователи, а также авторизо¬ в а н н ы е пользователи, работающие с вычислительными системами неав¬ торизованным образом; таким злоумышленникам не гарантируется с о ­ хранение конфиденциальности группой X Y Z - C E R T . О н и могут иметь или не иметь законных прав на конфиденциальность; если такие права суще¬ ствуют, о н и , конечно, будут соблюдаться. И н ф о р м а ц и я , которая, возможно, будет распространяться, класси­ фицируется следующим образом: • персональные д а н н ы е пользователей. Это и н ф о р м а ц и я о конкрет­ ных пользователях или, в некоторых случаях, о конкретных п р и л о ­ жениях, которая должна считаться к о н ф и д е н ц и а л ь н о й по юридиче¬ ским, контрактным и / и л и этическим причинам. Персональные дан¬ ные пользователей не будут раскрываться в узнаваемой форме за пределами группы X Y Z - C E R T ; исключения оговорены ниже. Если личность пользователя скрыта, и н ф о р м а ц и я может распространять­ ся свободно; • и н ф о р м а ц и я о злоумышленнике аналогична персональным д а н н ы м пользователя, но относится к злоумышленнику. Хотя и н ф о р м а ц и ю о злоумышленнике (в частности, идентифицирующие данные) не сде¬ лают общедоступной (если только она уже не стала достоянием об­ щественности, например, по п р и ч и н е возбуждения судебного пре­ следования), ее будут свободно пересылать системным администра­ торам и группам реагирования, прослеживающим нарушение; • и н ф о р м а ц и я о частной системе — это техническая и н ф о р м а ц и я о конкретных системах или организациях. Она не будет разглашаться без согласия соответствующих организаций. И с к л ю ч е н и я оговоре¬ н ы ниже; • и н ф о р м а ц и я об уязвимостях — техническая и н ф о р м а ц и я об уязви­ мостях или атаках, включая исправления и сопутствующие меры. Она распространяется свободно, хотя и будут прилагаться все уси198

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

л и я , чтобы заинтересованный в ней поставщик получил ее р а н ь ш е других; • и н ф о р м а ц и я , бросающая тень, — сообщение о том, что нарушение имело место, а также сведения о его масштабе или серьезности. Н е будет распространяться без разрешения соответствующих организа­ ц и й или пользователей. И с к л ю ч е н и я оговорены ниже; • статистическая и н ф о р м а ц и я — это и н ф о р м а ц и я , бросающая тень, снабженная удаленными и д е н т и ф и ц и р у ю щ и м и д а н н ы м и . Она рас­ пространяется по усмотрению отдела компьютерных услуг; • контактная и н ф о р м а ц и я позволяет обратиться к системным адми­ нистраторам и группам реагирования. Она будет распространяться свободно, если только контактное лицо или организация не попро¬ сит об обратном или если группа X Y Z - C E R T не решит, что такое распространение вызовет недовольство. Потенциальные получатели и н ф о р м а ц и и от группы X Y Z - C E R T так¬ ж е отнесены к различным категориям: • по роду своей д е я т е л ь н о с т и , в т о м ч и с л е по с о б л ю д е н и ю конфи¬ д е н ц и а л ь н о с т и , а д м и н и с т р а т о р ы университета X Y Z и м е ю т п р а в о получать всю и н ф о р м а ц и ю , необходимую д л я э ф ф е к т и в н о й р е а к ­ ц и и на н а р у ш е н и я б е з о п а с н о с т и , з а т р а г и в а ю щ и е в в е р е н н ы е и м системы; • системные администраторы университета X Y Z также, в силу возло¬ ж е н н ы х на них обязанностей, допущены к работе с к о н ф и д е н ц и а л ь ­ ной и н ф о р м а ц и е й . Однако, если эти лица не являются членами группы X Y Z - C E R T , они будут получать только те сведения, которые нужны и м для проведения расследования или обеспечения безопас¬ ности вверенных и м систем; • пользователи университетских систем д о п у щ е н ы к и н ф о р м а ц и и , ко¬ торая касается безопасности их собственных компьютерных счетов, даже если это означает утечку «информации о злоумышленнике» или «информации, бросающей тень» на другого пользователя; • университетское сообщество не будет получать н и к а к о й информа¬ ц и и ограниченного распространения, если только стороны, затрону­ тые нарушением, не дадут разрешения на распространение сведе­ н и й . Статистическая и н ф о р м а ц и я может предоставляться общест­ венности. Группа X Y Z - C E R T не считает себя обязанной и н ф о р м и ­ ровать общественность о нарушениях, хотя и может делать это; в ча­ стности, вероятно, известит все заинтересованные стороны о том, каким образом они были атакованы, или одобрит распространение этими сторонами подобной и н ф о р м а ц и и ; • ш и р о к а я общественность не получит н и к а к о й и н ф о р м а ц и и ограни­ ченного распространения. На самом деле, к ней не будут обращать199

Курс

Информационная безопасность: основные стандарты и спецификации

ся, хотя группа X Y Z - C E R T понимает, что сведения, с о о б щ е н н ы е университетскому сообществу, могут стать всеобщим достоянием; • сообщество специалистов по информационной безопасности рассмат¬ ривается наравне с широкой общественностью. Хотя члены группы X Y Z - C E R T могут принимать участие в дискуссиях в рамках этого со¬ общества, например, посредством телеконференций, списков рассыл¬ ки (включая раскрывающий все детали список «bugtraq») и совещаний разного рода, они (члены группы) рассматривают такие форумы как обращение к широкой общественности. Хотя технические вопросы (в том числе уязвимости) могут обсуждаться сколь угодно подробно, все примеры, взятые из опыта группы X Y Z - C E R T , будут изменены, чтобы сделать невозможной идентификацию затронутых сторон; • пресса также рассматривается как часть ш и р о к о й общественности. Группа X Y Z - C E R T не будет вступать с ней в непосредственные кон¬ такты по поводу нарушений безопасности, если только речь не идет о распространении сведений, уже ставших всеобщим достоянием; • другие организации и группы реагирования, я в л я ю щ и е с я партнера­ ми в расследовании нарушения безопасности, в некоторых случаях допустят к к о н ф и д е н ц и а л ь н о й и н ф о р м а ц и и . П р и этом добропоря­ дочность внешних организаций подлежит проверке, а передаваемая и н ф о р м а ц и я будет сводиться к минимуму, полезному для ликвида­ ции нарушения. Вероятнее всего, доступ к и н ф о р м а ц и и доверят о р ­ ганизациям, хорошо известным группе X Y Z - C E R T ; • поставщики, как правило, рассматриваются X Y Z - C E R T наравне с в н е ш н и м и группами реагирования. Приветствуется желание постав­ щ и к о в всех видов сетевого и компьютерного оборудования, п р о ­ граммного обеспечения и услуг повышать безопасность своих п р о ­ дуктов. С этой целью и м будет передаваться и н ф о р м а ц и я об уязвимо­ стях, обнаруженных в их продуктах, вместе с техническими деталями, позволяющими идентифицировать и ликвидировать проблему; • правоохранительные органы получат от группы X Y Z - C E R T всю и н ­ ф о р м а ц и ю , необходимую для проведения расследования, в соответ¬ ствии с политикой по о т н о ш е н и ю к вычислительным ресурсам. Коммуникации и аутентификация. Проанализировав т и п ы инфор¬ мации, с которой имеет дело группа X Y Z - C E R T , м о ж н о сделать вывод, что телефоны без средств ш и ф р о в а н и я м о ж н о считать достаточно безопасны­ ми. Н е ш и ф р о в а н н а я электронная почта не особенно защищена, однако ее можно использовать для передачи данных низкой степени критичности. Если по электронной почте нужно передать критичные данные, бу¬ дет применяться P G P . С точки зрения безопасности, передача файлов по сети рассматривается наравне с электронной почтой: критичные д а н н ы е д о л ж н ы шифроваться. 200

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

Когда необходимо получить уверенность в подлинности партнера, на¬ пример, перед началом действий на основе информации, предоставленной группе X Y Z - C E R T , или перед раскрытием конфиденциальной информации, с высокой степенью надежности будет проверяться его личность и репутация.

Описание услуг группы реагирования Услуги, оказываемые группой реагирования, м о ж н о разделить на две категории: • действия в реальном времени, непосредственно связанные с главной задачей — реагированием на нарушения; • профилактические действия, играющие вспомогательную роль и осуществляемые не в реальном масштабе времени. Вторая категория и часть первой состоит из услуг, которые являются дополнительными в том смысле, что их предлагают не все группы реаги¬ рования. Реагирование на нарушения обычно включает оценку входящих д о ­ кладов («классификация нарушений») и работу над поступившей инфор¬ мацией вместе с другими группами, поставщиками услуг Internet и ины¬ м и организациями («координация реагирования»). Третья группа услуг — п о м о щ ь локальным пользователям в восстановлении нормальной работы после нарушения («разрешение проблем») — обычно состоит из д о п о л н и ­ тельных сервисов, предоставляемых л и ш ь частью групп. К л а с с и ф и к а ц и я нарушений обычно включает в себя следующие действия: • оценка докладов: входящая и н ф о р м а ц и я интерпретируется, класси­ фицируется по степени важности, соотносится с продолжающимися событиями и выявляемыми тенденциями; • верификация; определяется, действительно ли имеет место наруше¬ ние и каковы его масштабы. П о д координаций реагирования обычно понимается: • категорирование и н ф о р м а ц и и : и н ф о р м а ц и я , относящаяся к нару­ ш е н и ю (регистрационные журналы, контактная и н ф о р м а ц и я и т.д.) категорируется согласно политике раскрытия сведений; • координация: в соответствии с политикой раскрытия сведений о на­ рушении извещаются другие стороны. Перечислим действия, предоставляемые в рамках услуг по разреше¬ н и ю проблем: • техническая поддержка (например, анализ «взломанных» систем); • искоренение проблем: устранение п р и ч и н нарушения (использован­ ных уязвимостей) и его проявлений (например, прерывание сеанса пользователя-нарушителя); 201

Курс

Информационная безопасность: основные стандарты и спецификации

• восстановление: п о м о щ ь в возвращении систем и услуг к состоянию, имевшему место до нарушения безопасности. В профилактические действия входят: • предоставление и н ф о р м а ц и и . П о д этим понимается поддержка а р ­ хива известных уязвимостей, заплат, способов разрешения прошлых проблем или организация списков рассылки с рекомендательными целями; • предоставление средств безопасности (например, средств аудита); • обучение и подготовка кадров; • оценка продуктов; • оценка з а щ и щ е н н о с т и организации, консультационные услуги. Е щ е один важный момент — использование ф о р м для докладов о н а ­ рушениях. О н о упрощает работу к а к пользователей, так и групп реагиро­ вания. Пользователи могут заготовить ответы на некоторые важные во¬ просы заранее, в с п о к о й н о й обстановке. Группа сразу, в первом сообще¬ н и и , получает всю необходимую и н ф о р м а ц и ю , что закладывает основу эффективного реагирования. В зависимости от целей и набора услуг конкретной группы, может использоваться несколько форм. Н а п р и м е р , форма для сообщения о н о ­ вой уязвимости может существенно отличаться от доклада о нарушении. Лучше всего предоставлять ф о р м ы в рамках оперативных информа¬ ц и о н н ы х услуг группы. Точные ссылки на н и х д о л ж н ы присутствовать в документах, описывающих группу, вместе с перечнем правил пользова¬ н и я и руководством п о порядку работы с ф о р м а м и . Если для «докладов по форме» поддерживаются отдельные адреса электронной почты, о н и так¬ ж е д о л ж н ы быть указаны. Один и з примеров — форма для доклада о нарушениях к о о р д и н а ц и ­ онного центра C E R T , представленная на Web-сервере http://www.cert.org. Документы, о п и с ы в а ю щ и е группу реагирования, н е являются кон¬ трактом, н о возможность последующих судебных санкций может выте¬ кать из описания услуг и целей. П о этой п р и ч и н е рекомендуется разме¬ щать в к о н ц е бланков соответствующий отвод (письменный отказ), пре¬ дупреждающий пользователей о возможных ограничениях. Группа X Y Z - C E R T предоставляет соответствующие задачам услуги. Реагирование на нарушения. X Y Z - C E R T помогает системным адми­ нистраторам в технических и организационных аспектах реагирования на нарушения. В частности, оказывается п о м о щ ь или даются советы о следу­ ющих аспектах реагирования: 1. К л а с с и ф и к а ц и я нарушений: • выяснение того, действительно л и имеет место нарушение; • определение масштаба нарушения. 2. Координация реагирования: 202

Лекция 13

Спецификация Internet-сообщества «Как реагировать на нарушения ИБ»

• выяснение первоначальной п р и ч и н ы нарушения (использованной уязвимости); • облегчение контактов с другими системами, возможно, затронутыми нарушением; • облегчение контактов со службой безопасности университета X Y Z и / и л и правоохранительными органами, если это необходимо; • предоставление отчетов другим группам реагирования; • составление уведомлений для пользователей, если это необходимо. 3. Разрешение проблем: • устранение уязвимостей; • ликвидация последствий нарушения; • оценка возможных дополнительных действий с учетом их стоимости и риска (например, исчерпывающее расследование или дисципли¬ нарные действия: сбор улик после нарушения, накопление и н ф о р ­ мации во время инцидента, установка ловушек для злоумышленни¬ ков и т.п.); • возможный сбор улик для судебного преследования или дисципли¬ нарных акций. К р о м е того, группа X Y Z - C E R T накапливает статистическую инфор¬ м а ц и ю о нарушениях, затрагивающих университетское сообщество, и, при необходимости, информирует сообщество, помогая ему защититься от известных атак. Чтобы воспользоваться услугами группы X Y Z - C E R T по реагирова­ н и ю на нарушения, следует направить электронное письмо по контактно¬ му адресу. Профилактические действия. Группа X Y Z - C E R T координирует и предоставляет следующие услуги в объеме, возможно, зависящем от на­ личия ресурсов: 1. И н ф о р м а ц и о н н о е обслуживание: • список контактных координат уполномоченных лиц по безопаснос¬ ти в отделах (административных и технических). Эти списки обще¬ доступны по таким каналам, как Web; • списки рассылки для и н ф о р м и р о в а н и я уполномоченных лиц о п о ­ явлении новой и н ф о р м а ц и и , относящейся к их компьютерной сре­ де, которые доступны только для системных администраторов уни¬ верситета X Y Z ; • хранилище защитных заплат, распространяемых поставщиками или источниками, для различных операционных систем. Х р а н и л и щ е об­ щедоступно, если это позволяют л и ц е н з и о н н ы е соглашения. Доступ к нему предоставляется по о б ы ч н ы м каналам — Web и / и л и ftp; • хранилище защитного инструментария и документации для исполь­ зования системными администраторами. П о возможности предо203

Курс

Информационная безопасность: основные стандарты и спецификации

ставляются предварительно с к о м п и л и р о в а н н ы е версии, готовые к установке. К а к обычно, доступ предоставляется через Web или ftp; • подготовка краткого изложения инцидента для различных и н ф о р м а ­ ц и о н н ы х ресурсов, включая основные списки рассылки и телекон­ ф е р е н ц и и . Результирующие а н н о т а ц и и распространяются через списки рассылки с ограниченным доступом или через Web, в зависи¬ мости от критичности и срочности и н ф о р м а ц и и . 2. П о в ы ш е н и е квалификации: • члены группы X Y Z - C E R T периодически проводят семинары по раз¬ л и ч н ы м аспектам и н ф о р м а ц и о н н о й безопасности; системные адми¬ нистраторы университета X Y Z приглашаются на эти занятия. 3. Аудит безопасности: • проверка целостности основных файлов; • присвоение уровней безопасности. М а ш и н ы и подсети в универси­ тете X Y Z проверяются на предмет присвоения им уровня безопасно­ сти. И н ф о р м а ц и я об уровнях доступна университетскому сообщест¬ ву, чтобы упростить установку соответствующих прав доступа; • централизованное протоколирование для м а ш и н , поддерживающих удаленное протоколирование в Unix-стиле. Регистрационные ж у р ­ налы автоматически просматриваются анализирующей программой, а события или тенденции, указывающие на потенциальные пробле­ м ы безопасности, доводятся до сведения соответствующих систем­ ных администраторов; — сохранение записей о нарушениях безопас­ ности. Хотя эти записи остаются к о н ф и д е н ц и а л ь н ы м и , периодичес­ ки готовятся и распространяются статистические отчеты. Детальное описание перечисленных в ы ш е услуг вместе с инструкци¬ я м и по присоединению к спискам рассылки, скачиванию и н ф о р м а ц и и или получению таких услуг, как централизованное протоколирование или проверка целостности файлов, доступны через Web-сервер группы X Y Z CERT. На этом м ы завершаем рассмотрение с п е ц и ф и к а ц и и Internet-сооб­ щества «Как реагировать на нарушения и н ф о р м а ц и о н н о й безопасности».

204

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

Лекция 14. Спецификация Internet-сообщества «Как в ы б и р а т ь п о с т а в щ и к а И н т е р н е т - у с л у г » Данная спецификация важна с точки зрения формирования организаци­ онной и архитектурной безопасности, на которой базируются прочие меры процедурного и программно-технического уровней.

Ключевые слова: Internet-услуги, поставщик Internet-услуг, потреби­ тель Internet-услуг, нарушение и н ф о р м а ц и о н н о й безопасности, реа­ гирование на нарушения и н ф о р м а ц и о н н о й безопасности, группа реагирования, ненадлежащее поведение, сетевая инфраструктура, уязвимость, атака, источник атаки, цель атаки, свидетельства нару­ ш е н и я , фильтрация трафика, разделение и н ф о р м а ц и и , доверенный канал, политика добропорядочного пользования, закон о защите данных, управление аутентификационными д а н н ы м и , коммутатор, маршрутизатор, таблица маршрутизации, подделка адресов, атака на доступность, одноразовые пароли, центр управления сетью, ф и з и ч е ­ ская защита, разделение сегмента сети, входная фильтрация, выход­ ная фильтрация, ограничение вещания, системная инфраструктура, распространение программного обеспечения, резервное копирова­ ние, конфигурирование, д о м е н н а я система и м е н , мониторинг, с и н ­ хронизация часов, почтовый сервер, сервер телеконференций, м и ­ н и м и з а ц и я привилегий, виртуальный сервер, управление доступом, программа на серверной стороне, идентифицирующая цепочка, эле­ ктронная к о м м е р ц и я , транзакция, ш и ф р о в а н и е транзакций, и н ф о р ­ м а ц и о н н о е наполнение, поисковая м а ш и н а , аудит безопасности, ак­ тивный аудит, балансировка нагрузки, разводка по сети питания.

Общие положения П о л н о е название рассматриваемой с п е ц и ф и к а ц и и (точнее, проекта с п е ц и ф и к а ц и и ) [46] — «Дополнение к Руководству по и н ф о р м а ц и о н н о й безопасности предприятия: К а к выбирать поставщика Интернет-услуг». Далее, для краткости, м ы будем называть ее «Дополнением к Руководст¬ ву» или просто Дополнением. Н а п о м н и м , что «Руководство по информа¬ ц и о н н о й безопасности предприятия» было рассмотрено нами ранее. П р и изложении Д о п о л н е н и я м ы опираемся на публикацию [28]. «Дополнение к Руководству» призвано помочь в выработке полити¬ ки и процедур безопасности в организациях, и н ф о р м а ц и о н н ы е системы которых подключены к Internet, а также служить для потребителей к о н 205

Курс

Информационная безопасность: основные стандарты и спецификации

трольным перечнем при обсуждении вопросов и н ф о р м а ц и о н н о й безо¬ пасности с поставщиками Internet-услуг. В д а н н о м документе выделено три типа потребителей: • потребители к о м м у н и к а ц и о н н ы х услуг; • потребители услуг по р а з м е щ е н и ю ресурсов; • потребители, разместившиеся там ж е , где и поставщики услуг. Е щ е одна цель Д о п о л н е н и я состоит в том, чтобы, информируя п о ­ ставщиков Internet-услуг об ожиданиях общественности, побудить их принять упреждающие меры, сделав безопасность одним из приоритет­ ных направлений развития. Поставщик Internet-услуг определяется как организация, обеспечи­ вающая для других подключение к Internet, а также и н ы е Internet-услуги, в том числе размещение Web-серверов, поставку и н ф о р м а ц и о н н о г о н а ­ п о л н е н и я , услуги электронной почты и т.д. Вероятно, для многих п р и в ы ч н е е называть такого п о с т а в щ и к а Internet-провайдером; м ы не стали этого делать, поскольку тогда, по с о ­ ображениям концептуальной целостности, потребителя пришлось бы именовать Internet-консьюмером, а этот термин пока не прижился.

Роль п о с т а в щ и к а I n t e r n e t - у с л у г в р е а г и р о в а н и и на н а р у ш е н и я б е з о п а с н о с т и М ы уже обсуждали тему реагирования на нарушения и н ф о р м а ц и о н ­ ной безопасности и взаимодействие групп реагирования с опекаемым с о ­ обществом. Затронута она и в Д о п о л н е н и и . Независимо от того, есть ли у поставщика Internet-услуг группа реа­ гирования, он должен определить и довести до потребителей порядок п е ­ редачи и обработки докладов о нарушениях, а также документировать собственные возможности по реагированию. У некоторых поставщиков есть группы реагирования на нарушения и н ф о р м а ц и о н н о й безопасности, однако даже в этом случае п о м о щ ь час¬ то предоставляется в качестве дополнительно оплачиваемой услуги, а группа включает в зону своей ответственности только тех, кто специаль¬ но на нее подписался. Если группы реагирования нет, поставщику следует определить, ка­ кую роль о н возьмет на себя (если возьмет вообще) при реагировании на нарушение, и существует ли группа, ответственность которой распрост¬ раняется на потребителя, чтобы направлять ей доклады о нарушениях. Поставщику Internet-услуг следует иметь специальные почтовые ящики: S E C U R I T Y — для сообщений о нарушениях безопасности, A B U S E — для сообщений о ненадлежащем поведении и N O C — для сооб¬ щ е н и й о проблемах в сетевой инфраструктуре. 206

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

Когда происходит нарушение и н ф о р м а ц и о н н о й безопасности, за¬ трагивающее инфраструктуру поставщика, необходимо немедленно со¬ общить потребителям такие сведения: • кто координирует р е а к ц и ю на нарушение; • какая уязвимость использована атакующим; • как нарушение сказалось на предоставляемых услугах; • что делается для реагирования на нарушение; • могут ли быть скомпрометированы д а н н ы е потребителей; • какие действия предпринимаются для устранения выявленной уяз¬ вимости; • предполагаемый график реагирования, если он может быть составлен. Если имеет место нарушение, направленное на какого-либо потре¬ бителя услуг подключения, поставщик Internet-услуг должен проинфор¬ мировать его об атаке и, по возможности, оказать п о м о щ ь в следующем: • проследить видимый источник атаки и попытаться определить до¬ стоверность каждого шага на этом маршруте. Если исходный адрес подделан, поставщик может определить точку в своей сети, через ко¬ торую поступает поток данных злоумышленника; • получить контактную и н ф о р м а ц и ю источника атаки; • собрать и защитить свидетельства нарушения, предохраняя их от уничтожения или непреднамеренного разглашения. В случае продолжения нарушения поставщик Internet-услуг, по за­ просу потребителя, может оказать п о м о щ ь путем протоколирования с це¬ лью дальнейшей диагностики проблемы или посредством фильтрации определенных видов трафика. Если окажется, что источником нарушения и н ф о р м а ц и о н н о й безо­ пасности является кто-то из потребителей, поставщик может помочь ад¬ министраторам источника и цели атаки, вступив с нарушителем в контакт и переслав ему контактную и н ф о р м а ц и ю для связи с пострадавшими. К поставщику могут также обратиться за п о м о щ ь ю в случае атак, к о ­ торые проходят через его сеть, но используют поддельные исходные адре¬ са. Поддержка возможна в предоставлении сетевой регистрационной ин¬ ф о р м а ц и и , генерируемой маршрутизаторами, чтобы найти точку, в кото¬ рой поток данных с поддельными адресами вошел в сеть поставщика. П р и прослеживании источника подобных атак требуется координация усилий со смежными поставщиками. Поставщикам Internet-услуг следует иметь правила и процедуры, ка­ сающиеся разделения и н ф о р м а ц и и о нарушении безопасности со своими потребителями, с другими поставщиками или группами реагирования, с правоохранительными органами, средствами массовой и н ф о р м а ц и и и общественностью. Понадобятся средства для организации доверенного канала с целью передачи подобной и н ф о р м а ц и и . 207

Курс

Информационная безопасность: основные стандарты и спецификации

Меры по защите Internet-сообщества Поставщики Internet-услуг играют критически важную роль в повы¬ ш е н и и безопасности Internet. Каждому из них следует иметь политику добропорядочного пользо­ вания, с учетом которой составляется контракт с потребителем. В п о л и ­ тике определяются права потребителей на те или и н ы е действия в разных частях сети и на разных системах. Во многих странах есть законы о защите данных. В ситуациях, когда они п р и м е н и м ы , поставщики д о л ж н ы проанализировать характер посту¬ пающих к н и м персональных данных и, если нужно, принять меры, пре­ пятствующие их противозаконному использованию. Учитывая глобаль­ н ы й характер Internet, поставщикам Internet-услуг, действующим в стра­ нах, где таких законов нет, необходимо хотя бы ознакомиться с идеей за¬ щ и т ы данных. Важно, чтобы штат поставщика постоянно п о м н и л о проблемах ин¬ ф о р м а ц и о н н о й безопасности, с п о н и м а н и е м подходил к их р е ш е н и ю , умел д о л ж н ы м образом применять средства п о в ы ш е н и я безопасности. К числу наиболее значимых принадлежат вопросы использования доверен­ ных каналов для передачи к о н ф и д е н ц и а л ь н о й и н ф о р м а ц и и , управления аутентификационными д а н н ы м и и т.д. Поставщики Internet-услуг ответственны за такое управление сете¬ вой инфраструктурой Internet, чтобы обеспечивалась устойчивость к по¬ я в л е н и ю уязвимостей, а атакующие н е могли легко организовать плац­ дарм для последующих атак. Ключевой элемент сетевой инфраструктуры — маршрутизаторы. К сожалению, они не только сами по себе являются притягательными целя­ ми атак на безопасность, н о и представляют собой отличный плацдарм для организации нападений на другие цели. М н о г и е маршрутизаторы позволяют злоумышленникам совершать опасные действия, например: • «прослушивать» транзитные потоки данных; • манипулировать таблицами маршрутизации для перенаправления потоков данных; • изменять состояние интерфейсов с целью нарушения обслужива­ ния; • вызывать «трепыхание» маршрутных таблиц, чреватое отказом в об¬ служивании для крупных частей Internet; • создавать пакеты с поддельными адресами и л ю б ы м желаемым набо¬ ром флагов; • порождать ш т о р м ы I C M P - п а к е т о в , устраивать другие атаки на до¬ ступность; 208

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

• отправлять потоки данных в «черную дыру»; • скрывать обращения п о в н е ш н и м адресам, что облегчается недоста¬ точным протоколированием в маршрутизаторах. Доступ к маршрутизаторам следует основывать на одноразовых па¬ ролях или е щ е более сильных средствах и ограничивать в максимально возможной степени. Обращения к маршрутизатору — протоколировать, привлекая ресурсы других систем. Сеансы взаимодействия с маршрутизаторами подлежат ш и ф р о в к е для предотвращения к р а ж сеансов или данных и для недопущения атак, основанных на воспроизведении трафика. На маршрутизаторы нельзя возлагать в ы п о л н е н и е мелких услуг, ко¬ торые нередко включены п о умолчанию. Поставщики Internet-услуг д о л ж н ы быть столь ж е бдительными при конфигурировании всех видов сетевого оборудования, п о возможности ограничивая доступ к сетевому оборудованию, предоставляя его только уполномоченным сетевым администраторам. Конфигурационную и н ф о р м а ц и ю маршрутизаторов и коммутато¬ ров следует сопровождать на файловом сервере. Производители предлагают много сетевых устройств — от недорогих маршрутизаторов до принтеров, — п р и н и м а ю щ и х соединения п о прото­ колу telnet без запроса пароля. Если в сети поставщика Internet-услуг есть такое оборудование, доступ к нему следует ограничить. К р о м е того, по¬ требителям необходимо рекомендовать блокировать доступ к подобным устройствам из внешних сетей. К р а й н е нежелательно использовать про¬ токол telnet для управления компонентами сети. Центр управления сетью (ЦУС) является критически важной частью инфраструктуры поставщика Internet-услуг, поэтому его работу следует строить с соблюдением должных мер безопасности. ЦУС располагает административным контролем над конфигураци¬ о н н ы м и д а н н ы м и сетевого оборудования и обязан ограничить доступ к такой и н ф о р м а ц и и . К а к правило, ЦУС выполняет ф у н к ц и и мониторинга сети, периоди­ чески опрашивая множество сетевых устройств. П о м и м о простого о п р о ­ са, для взаимодействия с сетевыми устройствами ЦУС может использо­ вать управляющий протокол, в частности S N M P . Обычно с его п о м о щ ь ю выясняют значения различных переменных, например, число пакетов, принятых через определенный интерфейс. Однако протокол может п р и ­ меняться и для установки переменных, возможно, с далеко идущими п о ­ следствиями (к примеру, переконфигурирование устройства). В любом случае, в S N M P v l присутствует только тривиальная аутентификация. П о возможности, к S N M P следует прибегать только как к средству получения и н ф о р м а ц и и от удаленных устройств, трактуя ее к а к конфиденциальную. 209

Курс

Информационная безопасность: основные стандарты и спецификации

Е щ е одно п р и м е н е н и е протокола S N M P состоит в уведомлении уп¬ равляющей станции о возникновении исключительных ситуаций. Такую и н ф о р м а ц и ю также необходимо считать к о н ф и д е н ц и а л ь н о й и проявить осторожность, чтобы S N M P - с о о б щ е н и я сами по себе не вылились в ата¬ ку на доступность. В плане физической защиты наибольший интерес представляет ситуа­ ция, когда оборудование потребителей располагается на площадке постав­ щика Internet-услуг. В идеале каждый потребитель должен получить полно­ стью закрытую, запирающуюся «клетку», т. е. небольшое помещение со сте­ нами и проемами для прокладки множества кабелей, а также со стойками для монтажа оборудования. Потребители проходят туда в сопровождении сотрудника поставщика (либо получают ключи только от своей комнаты). Выделение отдельных комнат, однако, может оказаться с л и ш к о м н а ­ кладным, поэтому многие поставщики идут на компромисс, собирая «чу­ жое» оборудование в одном м а ш и н н о м зале и тщательно контролируя все, что в нем происходит. К сожалению, этого может оказаться недоста­ точно, чтобы избежать таких недоразумений, как нечаянное отключение оборудования другого потребителя. Вместо единого открытого простран­ ства следует разделить зал перегородками и предоставлять каждому п о ­ требителю отдельное п о м е щ е н и е с запирающейся дверью. Вблизи чужого оборудования никого нельзя оставлять без присмот­ ра. Такое оборудование запрещается трогать, фотографировать или ис¬ следовать. Надо помнить также о безопасности на втором уровне семиуровне¬ вой модели, запрещая разделение физического сегмента сети между о б о ­ рудованием потребителя и компьютерами, принадлежащими другим п о ­ требителям или поставщику Internet-услуг. Нередки случаи, когда зло­ у м ы ш л е н н и к и пользуются уязвимостями или н е з а ш и ф р о в а н н ы м и уда­ л е н н ы м и входами в оборудование потребителя, получают контроль над этими устройствами, переводят его в режим прослушивания сегмента л о ­ кальной сети, потенциально нарушая тем самым конфиденциальность или безопасность других устройств в этом сегменте. Вопросы безопасности чрезвычайно важны и тогда, когда компо¬ ненты сетевой инфраструктуры поставщика Internet-услуг размещены вне его территории (например, у партнера или в удаленной точке присут¬ ствия). Такие к о м п о н е н т ы нередко являются ж и з н е н н о важными с точки зрения топологии сети и, в то ж е время, могут стать объектом атаки или пострадать от несчастного случая. Для ограничения физического доступа оборудование в идеальном случае следует размещать в полностью закры¬ тых, запирающихся комнатах или «клетках». Если на чужой площади хра­ нятся запчасти, их также следует защищать от кражи, порчи или встраи­ вания «жучков». П о возможности необходимо использовать системы бе210

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

зопасности и замки, открывающиеся персональными картами. Удален­ н ы е к о м п о н е н т ы нужно периодически проверять на предмет встраивания постороннего оборудования, которое может использоваться для прослу­ ш и в а н и я сетевых соединений. К а к и на других площадках, компьютеры не следует подключать к транзитным сегментам и л и допускать подсоеди¬ н е н и е к сети неиспользуемых физических интерфейсов.

Маршрутизация, фильтрация и ограничение вещания Способность поставщика Internet-услуг направлять потоки данных к правильному конечному пункту зависит от правил маршрутизации, за¬ данных в виде маршрутных таблиц. П о с т а в щ и к и д о л ж н ы убедиться, ч т о находящаяся в их ведении маршрутная и н ф о р м а ц и я может быть измене¬ на только после надежной аутентификации и что права на внесение изме¬ н е н и й д о л ж н ы м образом ограничены. В граничных маршрутизаторах следует аутентифицировать соседей в рамках протокола B G P . П р и выборе протоколов внутренней маршрутизации нельзя забы­ вать о безопасности. В случае изменения маршрутов необходимо обра­ титься к наивысшему уровню аутентификации, поддерживаемому прото¬ колом внутренней маршрутизации. Нередко атакующие скрывают следы, подделывая исходные адреса. Ч т о б ы отвлечь в н и м а н и е от своей системы, в качестве исходного о н и вы¬ бирают адрес н е в и н н о й удаленной системы. К р о м е того, поддельные ис¬ ходные адреса часто встречаются в атаках, основанных на использовании о т н о ш е н и я доверия между узлами сети. Чтобы уменьшить область распространения подобных атак, постав­ щ и к и Internet-услуг д о л ж н ы применять входную фильтрацию потоков данных, т. е. фильтрацию в направлении от п е р и ф е р и й н о й системы (по¬ требитель) к Internet (см. рис. 14.1). Во всех граничных маршрутизаторах, к которым подключены потребители, следует сразу отфильтровывать иду¬ щ и е от них сетевые пакеты и и м е ю щ и е исходные адреса, отличные от вы¬ деленных д а н н ы м потребителям. Дополнительной мерой защиты потребителей от атак, основанных на подделке исходных адресов, является выходная фильтрация — от сети Internet к п е р и ф е р и й н о й системе (см. рис. 14.2). Во всех граничных мар¬ шрутизаторах, к которым подключены потребители, следует сразу от¬ фильтровывать потоки данных, идущие к потребителю и и м е ю щ и е исход¬ н ы е адреса из выделенного ему пространства. Иногда возникают ситуации, когда фильтрация оказывается невоз¬ можной. Н а п р и м е р , большой агрегирующий маршрутизатор н е выдержи211

Курс

Информационная безопасность: основные стандарты и спецификации

Рис. 14.1. Входная фильтрация IP-пакетов п о исходным адресам. П о с т а в щ и к Internet-услуг Потребитель Internet- |-< услуг

Граничный маршру­ тизатор

Граничный гЧ маршру¬ тизатор

Internet

Рис. 14.2. Выходная фильтрация IP-пакетов п о исходным адресам. вает дополнительной нагрузки, вызванной п р и м е н е н и е м пакетных филь­ тров. К р о м е того, входная фильтрация способна привести к трудностям для мобильных пользователей. Следовательно, хотя д а н н ы й метод для борьбы с подделкой адресов настоятельно рекомендуется, и м н е всегда удается воспользоваться. В тех редких случаях, когда фильтрация на стыке потребителя и п о ­ ставщика Internet-услуг невозможна, следует рекомендовать потребителю организовать фильтрацию внутри его сети. З л о у м ы ш л е н н и к и могут прибегнуть к и з б ы т о ч н ы м и з м е н е н и я м маршрутной и н ф о р м а ц и и как к средству увеличения загрузки, на базе к о ­ торого развивается атака на доступность. П о меньшей мере это приведет к деградации производительности. Поставщикам Internet-услуг следует отфильтровывать поступающие объявления о маршрутах, игнорируя, н а ­ пример, маршруты к адресам для частных объединений сетей, избегая ф и к т и в н ы х маршрутов и реализуя политику расщепления и агрегирова­ н и я маршрутов. Поставщики Internet-услуг д о л ж н ы применять методы, уменьшаю­ щ и е р и с к нарастания нагрузки на маршрутизаторы в других частях сети. Следует отфильтровывать «кустарные» маршруты, настойчивое агрегиро¬ вание и расщепление маршрутов. Протокол IP поддерживает направленное вещание (посылку) через сеть пакетов, которые в определенной подсети станут широковещатель212

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

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

Защита системной инфраструктуры То, как поставщик услуг управляет своими системами, критически важно для безопасности и надежного ф у н к ц и о н и р о в а н и я сети. Наруше­ н и я в работе систем могут в лучшем случае привести к с н и ж е н и ю произ¬ водительности или функциональности, но способны также вызвать поте¬ р ю данных или сделать возможным перехват сетевого трафика (не исклю¬ чена и последующая атака методом «нелегального посредника»). В общедоступном месте, например, на Web-сервере поставщика ус¬ луг, следует опубликовать его политику по о т н о ш е н и ю к защите персо¬ нальных данных, обеспечению аутентичности, подотчетности, наложе¬ н и ю защитных заплат, поддержке доступности, реагированию на доклады о нарушениях. Предоставление разных услуг следует возлагать на разные системы. К р о м е выгод от облегчения системного администрирования м о ж н о с о ­ слаться на многократно проверенный факт, что при таком подходе гораз¬ до п р о щ е построить з а щ и щ е н н у ю систему. Все услуги выиграют от организации надежной защиты на сетевом уровне средствами IPsec. Доступ ко всем системам поставщика, в ы п о л н я ю щ и м критически важные ф у н к ц и и (среди которых — почта, телеконференции и размеще­ н и е Web-серверов), следует ограничить, разрешая его только администра­ торам соответствующих услуг, предоставлять после надежной аутентифи­ к а ц и и и осуществлять по доверенному каналу. Доступными из внешних сетей д о л ж н ы быть только те порты, на которых ожидают подключения уже востребованные услуги. Если распространение и обновление программного обеспечения производится с п о м о щ ь ю автоматизированных средств, им выделяется доверенный канал. Целостность П О необходимо гарантировать путем вычисления и распространения вместе с П О криптографических кон¬ трольных сумм. Регистрационная и н ф о р м а ц и я должна быть доступна на чтение только системному администратору. Если поставщик услуг ведет учет работы потребителей, то системы, обеспечивающие этот учет, изолируются от остальной части сети. 213

Курс

Информационная безопасность: основные стандарты и спецификации

Нельзя подключать системы к транзитным сегментам. Резервное копирование может являться слабым звеном в системной безопасности, если защита резервных носителей н е налажена д о л ж н ы м образом. П р и копировании по сети следует пользоваться доверенным к а ­ налом. Если в процессе резервного копирования д а н н ы е помещаются на промежуточные диски, то доступ к этим дискам ограничивается в макси¬ мально возможной степени. Отслужившие срок носители д о л ж н ы уничтожаться, а н е выбрасы­ ваться. Пользователей систем и услуг необходимо информировать о том, что сохраняется на резервных копиях, а что нет. Д о м е н н а я система и м е н ( D N S ) играет критически важную роль в повседневной деятельности миллионов пользователей Internet. Постав­ щ и к а м услуг п р и администрировании DNS-серверов следует обратить в н и м а н и е на следующие аспекты: • мониторинг: обязательный контроль доступности D N S (способнос¬ ти отвечать на запросы); • синхронизация часов: синхронизация установленного на серверах времени с п о м о щ ь ю протокола N T P с аутентификацией. П р и конфигурировании почтовых серверов поставщики Internet-ус­ луг д о л ж н ы руководствоваться такими положениями: • по возможности использовать П О с раздельными агентами при¬ ема/отправки и обработки, чтобы агент приема/отправки, взаимо¬ действующий с удаленными почтовыми серверами, выполнялся с м и н и м а л ь н ы м и привилегиями; • ограничить запуск очередей п о запросу (предоставляемый для удоб¬ ства потребителей, получающих почту в своем домене и н е имеющих постоянного соединения), желательно средствами надежной аутен¬ тификации; • запретить предоставлять и н ф о р м а ц и ю о локальных пользователях или механизмах доставки, выходящую за рамки необходимого; • выявлять исключительные ситуации (повторяющиеся неудачи ау­ т е н т и ф и к а ц и и , зацикливание почты, ненормальная длина очереди) и генерировать соответствующие доклады. Говорят, что почтовый SMTP-сервер функционирует в режиме «от­ крытой» системы промежуточного хранения и пересылки почты, если о н допускает прием и пересылку нелокальным адресатам таких сообщений, которые были порождены нелокально. П о д о б н ы е открытые системы пе¬ ресылки почты нередко используются «спамерами», организующими массовую незапрошенную рассылку с сокрытием инициатора. Только в весьма специфических обстоятельствах м о ж н о оправдать решение адми¬ нистратора сделать систему пересылки в Internet полностью открытой. 214

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

П р и конфигурировании серверов телеконференций ( N N T P ) постав¬ щ и к а м Internet-услуг необходимо соблюдать следующие требования: • использовать П О , устойчивое к вредоносным управляющим сооб­ щ е н и я м и к переполнению буферов; • освободить сервер телеконференций от в ы п о л н е н и я каких-либо иных ф у н к ц и й ; • если поддерживаются входящие пакеты статей, н е подавать их на вход командного интерпретатора.

Размещение Web-серверов М н о г и е организации передают свои Web-серверы п о с т а в щ и к а м Internet-услуг вместе с обязанностями по эксплуатации и администриро­ ванию, исходя, главным образом, и з соображений и н ф о р м а ц и о н н о й бе¬ зопасности. П о м и м о перечисленных в ы ш е аспектов, поставщики услуг п р и ад¬ министрировании оборудования, на котором размещены Web-серверы, д о л ж н ы руководствоваться такими положениями: • разумное использование D N S . В момент подключения клиента н е следует выполнять п о и с к его и м е н и , поскольку это делает Web-сер­ веры уязвимыми для атак на доступность и заметно сказывается на производительности; • м и н и м и з а ц и я привилегий. Web-демон следует выполнять от и м е н и пользователя и группы, специально выделенных для этой цели и имеющих м и н и м а л ь н ы е привилегии. Ответственный за информаци¬ онное наполнение Web-сервера должен работать от имени другого пользователя; • контроль DocumentRoot. Все, что располагается н и ж е этого катало­ га, надо тщательнейшим образом проконтролировать. Желательно использовать системный вызов chroot для смены корневого каталога HTTP-демона; • контроль UserDir. Н а сервере нельзя регистрировать других пользова¬ телей, кроме администраторов. Если такие пользователи все-таки есть, директиве «UserDir» (в случае ее разрешения) н е следует предо­ ставлять доступ к информации пользователей — в частности, не разре¬ шать выполнение командных процедур от имени этих пользователей; • разбиение на виртуальные серверы. Единый сервер, на котором раз¬ мещено множество серверов (виртуальных доменов), необходимо организовать так, чтобы все д а н н ы е , программы и регистрационные журналы различных виртуальных серверов были отделены друг от друга и чтобы доступ к «чужой» конфигурации или д а н н ы м был не¬ возможен. К р о м е того, надо исключить доступ к д а н н ы м или п р о 215

Курс

Информационная безопасность: основные стандарты и спецификации

граммам на сервере одного потребителя через локатор ресурсов, в хостовой части которого указано и м я сервера другого потребителя; • управление доступом. Следует сделать в о з м о ж н ы м разграничение доступа к определенным частям сервера на основе механизмов на¬ дежной аутентификации — сертификатов или одноразовых паролей. Программы на серверной стороне, поддерживающие C G I или ка­ кой-либо другой интерфейс, важны для гибкости web к а к к о м м у н и к а ц и ­ о н н о й среды. Однако эта гибкость достигается ценой появления угроз бе­ зопасности, а слабая программа может сделать уязвимыми все виртуаль¬ н ы е домены на сервере. Правила, сообразно которым поставщик Internetуслуг разделяет программы на допустимые и недопустимые, является по¬ казательным аспектом всей его политики безопасности. Поставщику следует руководствоваться такими положениями: • политика безопасности; выработка для своих потребителей ясной ме­ тодики написания безопасных программ в имеющейся среде размеще­ ния Web-серверов с обязательным описанием тех приемов программи­ рования, при применении которых программы будут отвергаться. • установка программ: запрет на установку собственных программ по¬ требителей. Все программы и к о м а н д н ы е процедуры передаются п о ­ ставщику для первоначальной проверки на соответствие политике безопасности. Программы устанавливаются так, чтобы только адми¬ нистратор сервера мог их модифицировать. • выбор пользователя и группы процесса: программы выполняются от имени пользователя и группы, специально выбранных для этой цели и и м е ю щ и х м и н и м а л ь н ы е привилегии (часто используют «nobody»). • отображение в навигаторах: запрет при любых обстоятельствах на отображение программ в навигаторах. К а к следствие — программы нельзя размещать под DocumentRoot. • разделение виртуальных серверов: программы н е следует делать до¬ ступными через сервер другого потребителя или для Web-мастера другого потребителя; • обработка пользовательского ввода: н е вычислять в ы р а ж е н и я в пользовательском вводе, если нет механизма изоляции небезопас¬ ных действий. • лимитирование потребления ресурсов: ввести лимит потребляемого астрономического и процессорного времени, а также дискового про¬ странства для всех программ. • маршрутные имена: все маршрутные имена делать абсолютными или н а ч и н а ю щ и м и с я с DocumentRoot. Переменную P A T H устанав¬ ливает только системный администратор. Д а н н ы е , которые пишет программа серверной стороны, следует счи¬ тать к о н ф и д е н ц и а л ь н ы м и . Ч т о б ы сделать невозможным доступ к таким 216

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

д а н н ы м через навигаторы, права устанавливаются так, чтобы у Web-демона н е было права на чтение этих данных. Если через Web-сервер предоставляется доступ к базам данных, то программам, осуществляющим такой доступ, выделяются л и ш ь те п о л н о ­ мочия, которые абсолютно необходимы для их ф у н к ц и о н и р о в а н и я . Д а н н ы е , относящиеся к управлению состояниями (идентифициру­ ю щ и е цепочки — cookies), следует считать к о н ф и д е н ц и а л ь н ы м и . Требует­ ся исключить возможность доступа к н и м из навигаторов. Регистрационная и н ф о р м а ц и я , генерируемая Web-демоном, д о л ж ­ на быть весьма к о н ф и д е н ц и а л ь н о й . Д л я реализации этого положения понадобится: • поставщику Internet-услуг разрешить в ы п о л н е н и е л и ш ь необходи¬ мых операций с регистрационной и н ф о р м а ц и е й — генерацию счетов и периодическую ротацию; • регистрационную информацию хранить вне дерева с корнем в DocumentRoot, чтобы исключить возможность доступа через навигаторы; • регистрационную и н ф о р м а ц и ю в первоначальном или обработан¬ ном виде передавать потребителю только по доверенному каналу. М н о г и е поставщики Internet-услуг предоставляют своим потребите­ л я м средства для продажи товаров и л и услуг через р а з м е щ е н н ы е у постав­ щ и к а Web-серверы. Поставщику, разместившему у себя приложения эле­ ктронной к о м м е р ц и и , следует руководствоваться такими положениями: • ш и ф р о в а н и е транзакций: транзакции нельзя хранить на сервере в открытом виде. Разрешается использование криптографии с откры¬ тыми ключами, так что только потребитель сможет расшифровать транзакции. Д а ж е если транзакции передаются напрямую в финан¬ совое учреждение и л и потребителю, поставщик услуг вправе сохра¬ нять у себя какую-то часть данных для обеспечения подотчетности; • передача транзакций: передача производится по доверенному кана­ лу, если транзакции н е обрабатываются немедленно, а передаются потребителю пакетами; • резервное копирование: в случае записи транзакций на резервные носи¬ тели должна гарантироваться физическая безопасность этих носителей. Загрузку и н ф о р м а ц и о н н о г о н а п о л н е н и я н а сервер п о с т а в щ и к а Internet-услуг следует производить по доверенному каналу. Поставщики услуг нередко предоставляют для использования п о ­ требителями поисковые м а ш и н ы , средства контроля целостности ссылок и т. д. Зачастую такие средства создают весьма существенную дополни¬ тельную нагрузку, поэтому их запуск по запросу необходимо запретить, чтобы защититься от атак на доступность. П о и с к о в ы е м а ш и н ы надо сконфигурировать так, чтобы п о и с к огра¬ ничивался частями Web-сервера, доступными всем. 217

Курс

Информационная безопасность: основные стандарты и спецификации

Результат проверки целостности ссылок следует считать конфиден¬ циальным, а доступ к нему предоставить только лицу, управляющему ин¬ ф о р м а ц и о н н ы м наполнением.

Возможные вопросы к поставщику Internet-услуг П р и выборе поставщика Internet-услуг потребителям имеет смысл выяснить целый ряд вопросов: 1. Есть ли у поставщика документированная политика безопасности? 2. Имеется ли документированная политика добропорядочного поль­ зования? К а к о в ы с а н к ц и и за ненадлежащее поведение? 3. Существует ли группа реагирования на нарушения информацион¬ ной безопасности? Если существует, то: • К а к и е у нее права, правила работы и предоставляемые услуги? • Какова цепочка эскалации докладов, которой должен следовать по¬ требитель? Если группы реагирования нет, то: • Какую роль играет поставщик услуг в реагировании на нарушения и н ф о р м а ц и о н н о й безопасности? • Есть ли какая-нибудь группа реагирования, к которой потребитель может обратиться? 4. Оказывает ли поставщик Internet-услуг какие-либо дополнительные услуги в области и н ф о р м а ц и о н н о й безопасности? 5. Информирует ли поставщик своих потребителей об атаках против них? 6. Оказывается ли п о м о щ ь в прослеживании источника атаки? 7. Осуществляется ли сбор и сохранение улик, свидетельствующих о нарушении и н ф о р м а ц и о н н о й безопасности? 8. Какую и н ф о р м а ц и ю сообщает поставщик услуг своим потребителям при обнаружении уязвимостей в предоставляемых и м сервисах? 9. К а к и когда и н ф о р м а ц и я об уязвимостях передается потребителям? 10. К кому может обратиться потребитель по электронной почте для прояснения вопросов и н ф о р м а ц и о н н о й безопасности? 11. К кому может обратиться потребитель по электронной почте для до¬ клада о ненадлежащем поведении сторонних пользователей? 12. К а к организованы к о м м у н и к а ц и и между поставщиком Internet-ус­ луг и потребителями, если имеют место признаки нарушения ин¬ ф о р м а ц и о н н о й безопасности? 13. К а к и е меры принимает поставщик услуг, чтобы не допустить не¬ с а н к ц и о н и р о в а н н о й маршрутизации потоков данных в свою сеть или через нее? 218

Лекция 14

Спецификация Internet-сообщества «Как выбирать поставщика»

14. Разделены л и на сегменты сети, поддерживающие потребителей ус¬ луг подключения и услуг размещения серверов? 15. К а к и е принимаются меры для обеспечения безопасности производ­ ственных сервисов, предоставляемых п о Internet потребителями, в том числе для защиты от атак на доступность, вторжений, подделок? 16. Насколько быстро поставщик накладывает з а щ и т н ы е заплаты на программное и микропрограммное обеспечение, функционирую¬ щее на производственном оборудовании? 17. Сканируются ли порты в сетях потребителей, и сообщается л и и м о найденных аномалиях? 18. Предоставляются л и услуги п о аудиту безопасности и усилению за¬ щ и т ы систем потребителей? 19. Есть л и у поставщика Internet-услуг система активного аудита, обна­ руживающая в реальном времени сетевые и системные атаки? 20. Какова политика добропорядочного пользования для и н ф о р м а ц и ­ онного н а п о л н е н и я Web-сервера, размещенного у поставщика? 21. К а к организована физическая защита оборудования, использующе­ гося для размещения серверов потребителей? 22. К а к часто производится резервное копирование и н ф о р м а ц и о н н о г о наполнения Web-серверов? 23. К а к часто резервные носители передаются на внешнее хранение? 24. Осуществляет ли поставщик услуг балансировку нагрузки, чтобы предотвратить н а с ы щ е н и е сети т р а ф и к о м других потребителей? 25. Какое резервное оборудование используется в случае поломок? К а к быстро о н о может быть развернуто? 26. К а к и е виды доступа предоставляются для управления информацион¬ н ы м наполнением размещенных у поставщика серверов? 27. Предоставляет ли поставщик з а щ и щ е н н ы е Web-серверы (https)? 28. Закрыт л и доступ к и н ф о р м а ц и о н н о м у н а п о л н е н и ю з а щ и щ е н н о г о Web-сервера для других потребителей? 29. К а к передавать и н ф о р м а ц и о н н о е н а п о л н е н и е на з а щ и щ е н н ы й Webсервер? 30. Какова политика добропорядочного пользования для потребителей, разделяющих площади с поставщиком Internet-услуг? 31. К а к организована физическая защита оборудования потребителей, размещенного на площадях поставщика? 32. К а к обеспечена разводка п о сети питания для оборудования разных потребителей, размещенного на общих площадях? 33. К а к обеспечено сетевое разделение для оборудования разных потре­ бителей, размещенного на общих площадях? На этом м ы завершаем рассмотрение с п е ц и ф и к а ц и и Internet-сооб­ щества «Как выбирать поставщика Internet-услуг». 219

Курс

Информационная безопасность: основные стандарты и спецификации

Л е к ц и я 1 5 . Б р и т а н с к и й с т а н д а р т BS 7 7 9 9 Подробно рассматривается британский стандарт BS 7799, ставший основой международного стандарта ISO/IEC 17799. Он помогает решить проблемы административного и процедурного уровней информационной безопасности.

Ключевые слова: у п р а в л е н и е и н ф о р м а ц и о н н о й безопасностью, р е ­ гулятор безопасности, п о л и т и к а безопасности, о р г а н и з а ц и я з а щ и ­ ты, к л а с с и ф и к а ц и я а к т и в о в , у п р а в л е н и е а к т и в а м и , безопасность персонала, ф и з и ч е с к а я безопасность, безопасность о к р у ж а ю щ е й среды, а д м и н и с т р и р о в а н и е систем, а д м и н и с т р и р о в а н и е сетей, уп¬ р а в л е н и е доступом, разработка и н ф о р м а ц и о н н ы х систем, сопро¬ вождение и н ф о р м а ц и о н н ы х систем, п л а н и р о в а н и е б е с п е р е б о й н о й работы, к о н т р о л ь соответствия т р е б о в а н и я м , р а с п р е д е л е н и е о б я ­ з а н н о с т е й , обучение, уведомление о случаях н а р у ш е н и я з а щ и т ы , антивирусное средство, защита д а н н ы х , р и с к , о ц е н к а р и с к о в , пла¬ нирование, реализация, оценка, корректировка, документ п о п о ­ л и т и к е безопасности, р е в и з и я п о л и т и к и безопасности, форум п о у п р а в л е н и ю и н ф о р м а ц и о н н о й безопасностью, периметр физичес¬ к о й безопасности, з а щ и щ е н н а я область, бесперебойное электро¬ п и т а н и е , защита к а б е л ь н о й р а з в о д к и , п р и е м к а систем, вредонос¬ н о е п р о г р а м м н о е о б е с п е ч е н и е , п о в с е д н е в н о е о б с л у ж и в а н и е , уп¬ равление носителями, обмен данными, обмен программами, м о ­ б и л ь н ы й пользователь, у д а л е н н ы й доступ, сегментация сетей, у п ­ р а в л е н и е м а р ш р у т и з а ц и е й , сетевой с е р в и с , и д е н т и ф и к а ц и я т е р ­ миналов, управление паролями, шифрование, электронная ц и ф ­ ровая п о д п и с ь , неотказуемость, у п р а в л е н и е к р и п т о г р а ф и ч е с к и м и к л ю ч а м и , библиотека исходных текстов, с к р ы т ы й к а н а л , т р о я н ­ ская п р о г р а м м а , п е р с о н а л ь н ы е д а н н ы е , аудит, а н а л и з т е н д е н ц и й , несоответствие. Продолжая рассмотрение стандартов и с п е ц и ф и к а ц и й , о т н о с я щ и х ­ ся к административному и процедурному уровням и н ф о р м а ц и о н н о й бе¬ зопасности, м ы приступаем к изучению двух частей британского стан¬ дарта BS 7799 (см. [37], [38]), фактически имеющего статус международ­ ного ( I S O / I E C 17799). Русский перевод первой части опубликован в к а ­ честве п р и л о ж е н и я к и н ф о р м а ц и о н н о м у бюллетеню Jet Info [34]. Первая часть стандарта, по-русски именуемая «Управление инфор¬ м а ц и о н н о й безопасностью. Практические правила», содержит система¬ тический, весьма п о л н ы й , универсальный перечень регуляторов безопас220

Лекция 15

Британский стандарт BS 7799

ности, полезный для организации практически любого размера, структу­ р ы и сферы деятельности. Она предназначена для использования в каче­ стве справочного документа руководителями и рядовыми сотрудниками, отвечающими за планирование, реализацию и поддержание внутренней системы и н ф о р м а ц и о н н о й безопасности. Согласно стандарту, цель и н ф о р м а ц и о н н о й безопасности — обеспе¬ чить бесперебойную работу организации, по возможности предотвратить и / и л и минимизировать ущерб от нарушений безопасности. Управление и н ф о р м а ц и о н н о й безопасностью позволяет коллектив­ но использовать д а н н ы е , одновременно обеспечивая их защиту и защиту вычислительных ресурсов. Подчеркивается, что защитные меры оказываются значительно бо¬ лее дешевыми и э ф ф е к т и в н ы м и , если они заложены в и н ф о р м а ц и о н н ы е системы и сервисы на стадиях задания требований и проектирования. Предлагаемые в первой части стандарта регуляторы безопасности разбиты на десять групп: • политика безопасности; • общеорганизационные аспекты защиты; • классификация активов и управление и м и ; • безопасность персонала; • физическая безопасность и безопасность окружающей среды; • администрирование систем и сетей; • управление доступом к системам и сетям; • разработка и сопровождение и н ф о р м а ц и о н н ы х систем; • управление бесперебойной работой организации; • контроль соответствия требованиям. В стандарте выделяется десять ключевых регуляторов, которые либо являются обязательными в соответствии с действующим законодательст­ вом, либо считаются о с н о в н ы м и структурными элементами и н ф о р м а ц и ­ о н н о й безопасности. К н и м относятся: • документ о политике и н ф о р м а ц и о н н о й безопасности; • распределение обязанностей по обеспечению и н ф о р м а ц и о н н о й бе¬ зопасности; • обучение и подготовка персонала к поддержанию режима информа¬ ц и о н н о й безопасности; • уведомление о случаях нарушения защиты; • антивирусные средства; • процесс планирования бесперебойной работы организации; • контроль за копированием программного обеспечения, защищенно¬ го законом об авторском праве; • защита документации; • защита данных; 221

Курс

Информационная безопасность: основные стандарты и спецификации

• контроль соответствия политике безопасности. Для обеспечения п о в ы ш е н н о г о уровня защиты особо ценных ресур­ сов или оказания противодействия злоумышленнику с исключительно высоким потенциалом нападения могут потребоваться другие (более сильные) средства, которые в стандарте н е рассматриваются. С л е д у ю щ и е ф а к т о р ы в ы д е л е н ы в качестве о п р е д е л я ю щ и х д л я ус¬ п е ш н о й р е а л и з а ц и и с и с т е м ы и н ф о р м а ц и о н н о й безопасности в органи¬ зации: • цели безопасности и ее обеспечение д о л ж н ы основываться на п р о ­ изводственных задачах и требованиях. Ф у н к ц и и управления безо­ пасностью должно взять на себя руководство организации; • необходима я в н а я поддержка и приверженность к соблюдению ре¬ ж и м а безопасности со стороны высшего руководства; • требуется хорошее п о н и м а н и е рисков (как угроз, так и уязвимостей), которым подвергаются активы организации, и адекватное представ¬ ление о ценности этих активов; • необходимо ознакомление с системой безопасности всех руководи¬ телей и рядовых сотрудников организации. Во второй части стандарта BS 7799-2:2002 «Системы управления и н ­ ф о р м а ц и о н н о й безопасностью — с п е ц и ф и к а ц и я с руководством п о и с ­ пользованию» предметом рассмотрения, к а к следует из названия, являет­ ся система управления и н ф о р м а ц и о н н о й безопасностью. Под системой управления информационной безопасностью (СУИ Б ) (Information Security Management System, I S M S ) п о н и м а е т с я часть о б щ е й с и с т е м ы у п р а в л е н и я , б а з и р у ю щ а я с я н а а н а л и з е р и с к о в и предназначенная для проектирования, реализации, контроля, сопро­ в о ж д е н и я и с о в е р ш е н с т в о в а н и я м е р в области и н ф о р м а ц и о н н о й б е з о ­ п а с н о с т и . Эту систему с о с т а в л я ю т о р г а н и з а ц и о н н ы е структуры, п о ­ л и т и к а , д е й с т в и я п о п л а н и р о в а н и ю , о б я з а н н о с т и , п р о ц е д у р ы , про¬ цессы и ресурсы. В основу процесса управления положена четырехфазная модель, включающая: • планирование; • реализацию; • оценку; • корректировку. По-русски данную модель м о ж н о назвать П Р О К (в оригинале — Plan-Do-Check-Act, P D C A ) . Детальный анализ каждой из выделенных ф а з и составляет основное содержание стандарта BS 7799-2:2002.

222

Лекция 15

Британский стандарт BS 7799

Регуляторы безопасности и реализуемые ими цели Часть 1. Регуляторы общего характера М ы приступаем к рассмотрению десяти групп регуляторов безопас¬ ности, выделенных в стандарте BS 7799. К первой группе отнесено то, что связано с политикой безопаснос¬ ти, а именно: • документально о ф о р м л е н н а я политика; • процесс ревизии политики. Цель регуляторов этой группы — определить стратегию управления безопасностью и обеспечить ее поддержку. Рекомендуемая структура документированной политики изложена в курсе «Основы и н ф о р м а ц и о н н о й безопасности» [3]. Вторая группа регуляторов безопасности касается общеорганизаци¬ о н н ы х аспектов. П о сравнению с первой она более многочисленна и на¬ делена внутренней структурой. Ее первая подгруппа — инфраструктура и н ф о р м а ц и о н н о й безопасности — преследует цель управления безопас­ ностью в организации и включает следующие регуляторы: • создание форума по управления и н ф о р м а ц и о н н о й безопасностью; • меры по координации действий в области и н ф о р м а ц и о н н о й безо¬ пасности; • распределение обязанностей в области информационной безопасности; • утверждение руководством (административное и техническое) но¬ вых средств обработки и н ф о р м а ц и и ; • получение рекомендаций специалистов по и н ф о р м а ц и о н н о й безо¬ пасности; • сотрудничество с другими организациями (правоохранительными органами, поставщиками и н ф о р м а ц и о н н ы х услуг и т.д.); • проведение независимого анализа и н ф о р м а ц и о н н о й безопасности. Регуляторы второй подгруппы — безопасность доступа сторонних организаций — предназначены для обеспечения безопасности вычисли¬ тельных и и н ф о р м а ц и о н н ы х ресурсов, к которым имеют доступ сторон¬ н и е организации. Этих регуляторов два: • идентификация рисков, связанных с подключениями сторонних о р ­ ганизаций, и реализация соответствующих защитных мер; • выработка требований безопасности для включения в контракты со сторонними организациями. Цель третьей подгруппы — обеспечение и н ф о р м а ц и о н н о й безопас¬ ности при использовании услуг внешних организаций. Предлагается в ы ­ работать требования безопасности для включения в контракты с постав¬ щ и к а м и и н ф о р м а ц и о н н ы х услуг.

223

Курс

Информационная безопасность: основные стандарты и спецификации

Очень важна третья группа регуляторов безопасности — классифика­ ц и я активов и управление и м и . Необходимым условием обеспечения над­ лежащей защиты активов является их идентификация и классификация. Д о л ж н ы быть выработаны критерии к л а с с и ф и к а ц и и , в соответствии с ко¬ торыми активы тем или и н ы м способом получают метки безопасности. Регуляторы четвертой группы — безопасность персонала — охватыва¬ ют все этапы работы персонала, и первый из них — документирование ро¬ лей и обязанностей в области и н ф о р м а ц и о н н о й безопасности при опре­ делении требований ко всем должностям. В соответствии с этими требо­ ваниями должны производиться отбор новых сотрудников, заключаться соглашения о соблюдении конфиденциальности, оговариваться в к о н ­ трактах другие условия. Для сознательного поддержания режима и н ф о р м а ц и о н н о й безопас­ ности необходимо обучение всех пользователей, регулярное п о в ы ш е н и е их к в а л и ф и к а ц и и . Наряду с превентивными, стандарт предусматривает и меры реагиро­ вания на инциденты в области безопасности, чтобы минимизировать ущерб и извлечь уроки на будущее. Предусмотрены уведомления (доклады) об и н ­ цидентах и замеченных уязвимостях, нештатной работе программного обес­ печения. Следует разработать механизмы оценки ущерба от инцидентов и сбоев и дисциплинарного наказания провинившихся сотрудников. Пятая группа регуляторов направлена на обеспечение физической безо¬ пасности и безопасности окружающей среды. Она включает три подгруппы: • организация з а щ и щ е н н ы х областей; • защита оборудования; • меры общего характера. Для организации з а щ и щ е н н ы х областей требуется определить пери¬ метры физической безопасности, контролировать вход в з а щ и щ е н н ы е области и работу в них, защитить производственные п о м е щ е н и я (особен­ но и м е ю щ и е специальные требования по безопасности) и места погрузочно/разгрузочных работ, которые, по возможности, надо изолировать от производственных помещений. Чтобы предупредить утерю, повреждение или н е с а н к ц и о н и р о в а н ­ ную м о д и ф и к а ц и ю оборудования рекомендуется размещать его в з а щ и ­ щ е н н ы х областях, наладить бесперебойное электропитание, защитить ка­ бельную разводку, организовать обслуживание оборудования, переме¬ щать устройства (в том числе за пределы организации) только с разреше¬ н и я руководства, удалять и н ф о р м а ц и ю перед выведением из эксплуата­ ц и и или изменением характера использования оборудования. К числу мер общего характера принадлежат политика чистого рабо¬ чего стола и чистого экрана, а также уничтожение активов — оборудова¬ н и я , программ и данных — только с разрешения руководства. 224

Лекция 15

Британский стандарт BS 7799

Часть 2. Регуляторы технического характера М е р ы по безопасному администрированию систем и сетей разделе¬ н ы в стандарте BS 7799 на семь подгрупп: • о п е р а ц и о н н ы е процедуры и обязанности; • планирование и приемка систем; • защита от вредоносного программного обеспечения; • повседневное обслуживание; • администрирование сетей; • безопасное управление носителями; • обмен д а н н ы м и и программами с другими организациями. Документирование операционных процедур и обязанностей пресле­ дует цель обеспечения корректного и надежного ф у н к ц и о н и р о в а н и я средств обработки и н ф о р м а ц и и . Требуется обязательно контролировать все изменения этих средств. Доклады о нарушениях безопасности долж­ н ы быть своевременными и э ф ф е к т и в н ы м и . Разделение обязанностей должно препятствовать злоупотреблению полномочиями. Средства раз­ работки и тестирования необходимо отделить от производственных ре­ сурсов. Для безопасного управления в н е ш н и м и ресурсами предлагается предварительно оценить р и с к и и включить в контракты со сторонними организациями соответствующие положения. П л а н и р о в а н и е и приемка систем призваны минимизировать р и с к их отказа. Для этого рекомендуется отслеживать и прогнозировать вычисли­ тельную нагрузку, требуемые ресурсы хранения и т.д. Следует разработать критерии приемки новых систем и версий, организовать их тестирование до введения в эксплуатацию. Защита от вредоносного программного обеспечения должна в к л ю ­ чать как превентивные меры, так и меры обнаружения и ликвидации вре¬ доносного П О . П о д повседневным обслуживанием в стандарте имеется в виду ре¬ зервное копирование, протоколирование действий операторов, регистра¬ ц и я , доведение до сведения руководства и ликвидация сбоев и отказов. Вопросы администрирования сетей в стандарте, по сути, не р а с к р ы ­ ваются, л и ш ь констатируется необходимость целого спектра регуляторов безопасности и документирования обязанностей и процедур. Безопасное управление носителями подразумевает контроль за съем­ н ы м и носителями, безвредную утилизацию отслуживших свой срок носи­ телей, документирование процедур обработки и хранения и н ф о р м а ц и и , защиту системной документации от несанкционированного доступа. Более детально регламентирован обмен д а н н ы м и и программами с другими организациями. Предлагается заключать ф о р м а л ь н ы е и н е ф о р ­ мальные соглашения, защищать носители при транспортировке, обеспе¬ чивать безопасность электронной к о м м е р ц и и , электронной почты, о ф и с 225

Курс

Информационная безопасность: основные стандарты и спецификации

ных систем, систем общего доступа и других средств обмена. В качестве универсальных защитных средств рекомендуются документированная политика безопасности, соответствующие процедуры и регуляторы. Самой многочисленной является группа регуляторов, относящихся к управлению доступом к системам и сетям. Она состоит из восьми под¬ групп: • производственные требования к управлению доступом; • управление доступом пользователей; • обязанности пользователей; • управление доступом к сетям; • управление доступом средствами операционных систем; • управление доступом к приложениям; • контроль за доступом и использованием систем; • контроль мобильных пользователей и удаленного доступа. Производственные требования к управлению доступом излагаются в документированной политике безопасности, которую необходимо прово¬ дить в ж и з н ь . Управление доступом пользователей должно обеспечить авториза¬ ц и ю , выделение и контроль прав в соответствии с политикой безопасно¬ сти. Этой цели служат процедуры регистрации пользователей и ликвида¬ ц и и их системных счетов, управление привилегиями в соответствии с п р и н ц и п о м их м и н и м и з а ц и и , управление паролями пользователей, а так­ ж е д и с ц и п л и н а регулярной ревизии прав доступа. Обязанности пользователей, согласно стандарту, сводятся к пра¬ вильному выбору и п р и м е н е н и ю паролей, а также к защите оборудова¬ н и я , остающегося без присмотра. Управление доступом к сетям опирается на следующие регуляторы: • политика использования сетевых услуг (прямой доступ к услугам должен предоставляться только по явному разрешению); • задание маршрута от пользовательской системы до используемых систем (предоставление выделенных л и н и й , недопущение неогра¬ ниченного перемещения по сети и т.д.); • аутентификация удаленных пользователей; • аутентификация удаленных систем; • контроль доступа (особенно удаленного) к диагностическим портам; • сегментация сетей (выделение групп пользователей, информацион¬ ных сервисов и систем); • контроль сетевых подключений (например, контроль по предостав¬ ляемым услугам и / и л и времени доступа); • управление маршрутизацией; • защита сетевых сервисов (должны быть о п и с а н ы атрибуты безопас¬ ности всех сетевых сервисов, используемых организацией). 226

Лекция 15

Британский стандарт BS 7799

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

Часть 3. Разработка и сопровождение, управление бесперебойной работой, контроль соответствия Регуляторы группы «разработка и сопровождение и н ф о р м а ц и о н н ы х систем» охватывают весь ж и з н е н н ы х ц и к л систем. Первым шагом являет­ ся анализ и задание требований безопасности. Основу анализа составля¬ ют: • необходимость обеспечения конфиденциальности, целостности и доступности и н ф о р м а ц и о н н ы х активов; • возможность использования различных регуляторов для предотвра­ щ е н и я и выявления нарушений безопасности и для восстановления нормальной работы после отказа или нарушения безопасности. В частности, следует рассмотреть необходимость: • управления доступом к и н ф о р м а ц и и и сервисам, включая требова­ н и я к разделению обязанностей и ресурсов; • протоколирования для повседневного контроля или специальных расследований; 227

Курс

Информационная безопасность: основные стандарты и спецификации

• контроля и поддержания целостности данных на всех или избран­ ных стадиях обработки; • обеспечения конфиденциальности данных, возможно, с использо¬ ванием криптографических средств; • выполнения требований действующего законодательства, договор¬ ных требований и т.п. • резервного копирования производственных данных; • восстановления систем после отказов (особенно для систем с п о в ы ­ ш е н н ы м и требованиями к доступности); • защиты систем от н е с а н к ц и о н и р о в а н н ы х м о д и ф и к а ц и й ; • безопасного управления системами и их использования сотрудника­ ми, не я в л я ю щ и м и с я специалистами. Подгруппа регуляторов, обеспечивающих безопасность прикладных систем, включает: • проверку входных данных; • встроенные проверки корректности данных в процессе их обработ¬ ки; • аутентификацию сообщений как элемент контроля их целостности; • проверку выходных данных. Третью подгруппу рассматриваемой группы составляют криптогра­ фические регуляторы. И х основой служит документированная политика использования средств криптографии. Стандартом предусматривается п р и м е н е н и е ш и ф р о в а н и я , электронных цифровых подписей, механиз­ мов неотказуемости, средств управления ключами. Четвертая подгруппа — защита системных файлов — предусматривает: • управление программным обеспечением, находящимся в эксплуата¬ ции; • защиту тестовых данных систем; • управление доступом к библиотекам исходных текстов. Регуляторы пятой подгруппы направлены на обеспечение безопас­ ности процесса разработки и вспомогательных процессов. В нее входят следующие регуляторы: • процедуры управления внесением изменений; • анализ и тестирование систем после внесения изменений; • ограничение на внесение изменений в программные пакеты; • проверка наличия скрытых каналов и троянских программ; • контроль за разработкой П О , выполняемой внешними организациями. Группа «управление бесперебойной работой организации» и с к л ю ч и ­ тельно важна, но устроена существенно проще. Она включает пять регу­ ляторов, направленных на предотвращение перерывов в деятельности предприятия и защиту критически важных бизнес-процессов от послед¬ ствий крупных аварий и отказов: 228

Лекция 15

Британский стандарт BS 7799

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

Курс

Информационная безопасность: основные стандарты и спецификации

• идентифицировать п р и м е н и м ы е законы, нормативные акты и т.п. • обеспечить соблюдение законодательства п о защите интеллектуаль¬ ной собственности; • защитить деловую документацию от утери, уничтожения или фаль¬ сификации; • обеспечить защиту персональных данных; • предотвратить незаконное использование средств обработки инфор¬ мации; • обеспечить выполнение законов, касающихся криптографических средств; • обеспечить сбор свидетельств на случай взаимодействия с правоо¬ хранительными органами. Ко второй подгруппе отнесены регуляторы, контролирующие соот­ ветствие политике безопасности и техническим требованиям. Руководите­ ли всех уровней должны убедиться, что все защитные процедуры, входящие в их зону ответственности, выполняются должным образом и что все такие зоны регулярно анализируются на предмет соответствия политике и стан­ дартам безопасности. И н ф о р м а ц и о н н ы е системы нуждаются в регулярной проверке соответствия стандартам реализации защитных функций. Регуляторы, относящиеся к аудиту и н ф о р м а ц и о н н ы х систем, объе¬ д и н е н ы в третью подгруппу. Их цель — максимизировать эффективность аудита и минимизировать помехи, создаваемые процессом аудита, равно как и вмешательство в этот процесс. Ход аудита должен тщательно п л а н и ­ роваться, а используемый инструментарий — защищаться от несанкцио¬ нированного доступа. На этом м ы завершаем рассмотрение регуляторов безопасности, предусмотренных стандартом BS 7799.

Четырехфазная модель процесса управления информационной безопасностью М ы приступаем к детальному рассмотрению четырехфазной (плани­ рование — реализация — оценка — корректировка, П Р О К ) модели процес­ са управления и н ф о р м а ц и о н н о й безопасностью, п р и м е н е н н о й в стандар­ те BS 7799-2:2002. Процесс управления имеет циклический характер; на фазе первона­ чального планирования осуществляется вход в цикл. В качестве первого шага должна быть определена и документирована политика безопасности организации. Затем определяется область действия системы управления информа¬ ц и о н н о й безопасностью. Она может охватывать всю организацию или ее части. Следует специфицировать зависимости, интерфейсы и предполо230

Лекция 15

Британский стандарт BS 7799

ж е н и я , связанные с границей между С У И Б и ее окружением; это особен­ но важно, если в область действия попадает л и ш ь часть организации. Большую область целесообразно поделить на подобласти управления. Ключевым элементом фазы планирования является анализ рисков. Этот вопрос детально рассмотрен в курсе «Основы и н ф о р м а ц и о н н о й бе­ зопасности» [3]; здесь м ы не будем на нем останавливаться. Результат анализа рисков — выбор регуляторов безопасности. П л а н должен включать график и приоритеты, детальный рабочий план и рас¬ пределение обязанностей по реализации этих регуляторов. На второй фазе — фазе реализации — руководством организации вы¬ деляются необходимые ресурсы (финансовые, материальные, людские, временные), выполняется реализация и внедрение выбранных регулято­ ров, сотрудникам объясняют важность проблем и н ф о р м а ц и о н н о й безо­ пасности, проводятся курсы обучения и п о в ы ш е н и я к в а л и ф и к а ц и и . Ос­ новная цель этой фазы — ввести р и с к и в р а м к и , определенные планом. Назначение фазы оценки — проанализировать, насколько эффек¬ тивно работают регуляторы и система управления и н ф о р м а ц и о н н о й бе­ зопасностью в целом. К р о м е того, следует принять во в н и м а н и е измене­ н и я , произошедшие в организации и ее окружении, способные повлиять на результаты анализа рисков. П р и необходимости намечаются корректи­ р у ю щ и е действия, предпринимаемые в четвертой фазе. К о р р е к ц и я долж­ на производиться, только если в ы п о л н е н о по крайней мере одно из двух условий: • выявлены внутренние противоречия в документации С У И Б ; • р и с к и в ы ш л и за допустимые границы. Оценка может выполняться в нескольких формах: • регулярные (рутинные) проверки; • проверки, вызванные появлением проблем; • изучение опыта (положительного и отрицательного) других органи¬ заций; • внутренний аудит С У И Б ; • и н с п е к ц и и , проводимые по инициативе руководства; • анализ тенденций. Аудит должен выполняться регулярно, не реже одного раза в год. В процессе аудита следует убедиться в следующем: • политика безопасности соответствует производственным требова¬ ниям; • результаты анализа рисков остаются в силе; • документированные процедуры выполняются и достигают постав¬ ленных целей; • технические регуляторы безопасности (например, межсетевые экра­ н ы или средства ограничения физического доступа) расположены 231

Курс

Информационная безопасность: основные стандарты и спецификации

д о л ж н ы м образом, правильно с к о н ф и г у р и р о в а н ы и работают в штатном режиме; • действия, намеченные по результатам предыдущих проверок, вы¬ полнены. Даже если недопустимых отклонений не выявлено и уровень безо¬ пасности п р и з н а н удовлетворительным, целесообразно зафиксировать изменения в технологии и производственных требованиях, появление н о ­ вых угроз и уязвимостей, чтобы предвидеть будущие изменения в системе управления. Систему управления и н ф о р м а ц и о н н о й безопасностью надо посто­ я н н о совершенствовать, чтобы она оставалась э ф ф е к т и в н о й . Эту цель преследует четвертая фаза рассматриваемого в стандарте цикла — коррек¬ тировка. Она может потребовать к а к относительно незначительных дей¬ ствий, так и возврата к фазам планирования (например, если появились новые угрозы) или реализации (если следует осуществить намеченное ра¬ нее). П р и корректировке прежде всего следует устранить несоответствия следующих видов: • отсутствие или невозможность реализации некоторых требований СУИБ; • неспособность С У И Б обеспечить проведение в ж и з н ь политики бе¬ зопасности или обслуживать производственные цели организации. Задача фазы о ц е н к и — выявить проблемы. Н а фазе корректировки необходимо докопаться до их корней и устранить первопричины несоот­ ветствий, чтобы избежать повторного появления. С этой целью могут предприниматься как реактивные, так и превентивные действия, рассчи¬ т а н н ы е на среднесрочную или долгосрочную перспективу. Таково (в сжатом изложении) содержание двух частей стандарта BS 7799. Может показаться, что каждое из его положений самоочевидно; тем не менее, собранные вместе и систематизированные, они обладают несо¬ м н е н н о й ценностью.

232

Федеральный стандарт США FIPS 140-2

Лекция 16

Л е к ц и я 16. Ф е д е р а л ь н ы й с т а н д а р т С Ш А FIPS 1 4 0 - 2 «Требования б е з о п а с н о с т и для криптографических модулей» Рассматриваемый стандарт играет организующую роль, описывая внешний интерфейс криптографического модуля и общие требования к по­ добным модулям. Наличие такого стандарта упрощает разработку сервисов безопасности и профилей защиты для них.

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

О с н о в н ы е п о н я т и я и и д е и с т а н д а р т а FIPS 1 4 0 - 2 В федеральном стандарте С Ш А FIPS 140-2 «Требования безопасно­ сти для криптографических модулей» под криптографическим модулем понимается набор аппаратных и / и л и программных (в том числе встроен¬ ных) компонентов, реализующих утвержденные ф у н к ц и и безопасности (включая криптографические алгоритмы, генерацию и распределение криптографических ключей, аутентификацию) и заключенных в пределах я в н о определенного, непрерывного периметра. В стандарте FIPS 140-2 рассматриваются криптографические моду­ л и , предназначенные для защиты и н ф о р м а ц и и ограниченного доступа, 233

Курс

Информационная безопасность: основные стандарты и спецификации

не я в л я ю щ е й с я секретной, т. е. речь идет о п р о м ы ш л е н н ы х изделиях, представляющих интерес для основной массы организаций. Наличие п о ­ добного модуля — необходимое условие обеспечения з а щ и щ е н н о с т и сколько-нибудь развитой и н ф о р м а ц и о н н о й системы, однако, чтобы вы¬ полнять предназначенную ему роль, сам модуль также нуждается в з а щ и ­ те, как собственными средствами, так и средствами окружения (напри¬ мер, операционной системы). Согласно стандарту, перед криптографическим модулем ставятся следующие высокоуровневые ф у н к ц и о н а л ь н ы е цели безопасности: • п р и м е н е н и е и безопасная реализация утвержденных ф у н к ц и й безо­ пасности для защиты и н ф о р м а ц и и ограниченного доступа; • обеспечение защиты модуля от несанкционированного использова­ н и я и нештатных методов эксплуатации; • предотвращение н е с а н к ц и о н и р о в а н н о г о раскрытия содержимого модуля (криптографических ключей и других данных, критичных для безопасности); • предотвращение н е с а н к ц и о н и р о в а н н о й и необнаруживаемой моди¬ ф и к а ц и и модуля и криптографических алгоритмов, в том числе н е ­ с а н к ц и о н и р о в а н н о й м о д и ф и к а ц и и , подмены, вставки и удаления криптографических ключей и других данных, критичных для безо¬ пасности; • обеспечение отображения (индикации) режима работы (состояния) модуля; • обеспечение доверия тому, что модуль функционирует д о л ж н ы м об¬ разом при работе в утвержденном режиме; • обнаружение о ш и б о к в ф у н к ц и о н и р о в а н и и модуля и предотвраще¬ ние компрометации и н ф о р м а ц и и ограниченного доступа и данных модуля, критичных для безопасности вследствие подобных ошибок. И з перечисленных целей вытекают требования безопасности, отно­ сящиеся к этапам проектирования и реализации модуля и разделенные в стандарте на одиннадцать групп: • с п е ц и ф и к а ц и я криптографического модуля; • требования к портам и интерфейсам модуля; • роли, сервисы и аутентификация; • конечноавтоматная модель; • физическая безопасность; • эксплуатационное окружение; • управление криптографическими ключами; • электромагнитная совместимость; • самотестирование; • доверие проектированию; • сдерживание прочих атак. 234

Федеральный стандарт США FIPS 140-2

Лекция 16

С п е ц и ф и к а ц и я модуля включает определение криптографического периметра, реализуемых ф у н к ц и й и режимов, описание модуля, его аппа¬ ратных и программных компонентов, а также документированную поли¬ тику безопасности. Среди портов и интерфейсов модуля д о л ж н ы быть выделены обяза¬ тельные и дополнительные. Следует специфицировать все интерфейсы, а также все маршруты входных и выходных данных. К р о м е того, порты для н е з а щ и щ е н н ы х параметров, критичных для безопасности, д о л ж н ы быть логически отделены от других портов. Среди ролей и сервисов необходимо провести логическое разделе¬ н и е на обязательные и дополнительные, обеспечить персональную или ролевую аутентификацию. Модель в виде конечного автомата должна описывать деление на обязательные и дополнительные состояния. М е р ы физической самозащиты модуля включают замки, з а щ и т н ы е кожухи, сохраняющие свидетельства вторжений пломбы, средства опера­ тивного выявления и реагирования на попытки вторжений, меры по про¬ тиводействию атакам, о с н о в а н н ы м на использовании нештатных внеш¬ них условий. Ядром допустимого эксплуатационного окружения должна служить операционная система, удовлетворяющая требованиям утвержденного п р о ф и л я защиты, обеспечивающая произвольное управление доступом, протоколирование и аудит, доверенные маршруты. К р о м е того, следует применять утвержденные методы контроля целостности и построить мо¬ дель политики безопасности. В число поддерживаемых механизмов управления ключами д о л ж н ы входить генерация случайных чисел, распределение ввод/вывод, хране¬ н и е и обнуление ключей. На требованиях электромагнитной совместимости м ы останавли­ ваться не будем. П р и включении питания и при выполнении определенных условий необходимо в ы п о л н е н и е тестов криптографических алгоритмов, кон¬ троль целостности программного обеспечения, проверки к р и т и ч н ы х функций. М е р ы доверия проектированию д о л ж н ы включать конфигурацион¬ н о е управление, процедуры безопасной установки, генерации и распрост¬ ранения. Следует подготовить функциональную с п е ц и ф и к а ц и ю , при ре­ ализации использовать я з ы к высокого уровня, продемонстрировать соот¬ ветствие проекта и политики, снабдить пользователей соответствующими руководствами. Н а к о н е ц , предусматриваются меры по сдерживанию атак, для кото¬ рых пока нет стандартизованных требований. 235

Курс

Информационная безопасность: основные стандарты и спецификации

Стандартом FIPS 140-2 предусмотрено четыре уровня з а щ и щ е н н о с ­ ти криптографических модулей, что позволяет экономически целесооб¬ разных образом защищать д а н н ы е разной степени критичности (регист¬ р а ц и о н н ы е журналы, счета на м и л л и о н ы долларов или д а н н ы е , от кото¬ рых зависит ж и з н ь людей) в разных условиях (строго охраняемая терри­ тория, о ф и с , неконтролируемый объект). К первому (самому слабому) уровню применяется м и н и м а л ь н ы й н а ­ бор требований безопасности, которым удовлетворяет, например, ш и ф ­ рующая плата для персонального компьютера. Программные к о м п о н е н ­ ты соответствующих модулей могут выполняться на универсальных вы¬ числительных системах с несертифицированной О С . На втором уровне требуются: • ролевая аутентификация; • замки на съемных оболочках и дверцах, защитные покрытия и п л о м ­ бы, сохраняющие свидетельства вторжений; • использование О С , сертифицированных на соответствие определен­ н ы м п р о ф и л я м защиты на основе «Общих критериев» с о ц е н о ч н ы м уровнем доверия не н и ж е второго. К третьему уровню предъявляются следующие дополнительные тре­ бования: • отделение портов и интерфейсов, применяемых для нешифрованно¬ го ввода/вывода криптографических ключей и других данных, кри¬ тичных для безопасности; • персональная аутентификация с проверкой допустимости п р и н я т и я определенных ролей; • наличие средств оперативного выявления и реагирования на попыт¬ ки вторжений (к примеру, микросхемы, обеспечивающие обнуление критичных данных модуля при попытке вскрыть корпус); • использование О С , сертифицированных на соответствие определен­ н ы м п р о ф и л я м защиты с о ц е н о ч н ы м уровнем доверия не н и ж е тре¬ тьего и поддержкой доверенного маршрута. Четвертый уровень самый сильный. Его требования предусматрива­ ют п о л н ы й спектр мер физической защиты, включая меры по противо­ действию атакам, берущим на вооружение нештатные в н е ш н и е условия (электрические или температурные). Операционная система должна с о ­ ответствовать оценочному уровню доверия не н и ж е четвертого. Далее будут детально рассмотрены наиболее содержательные группы требований. Здесь ж е обратим в н и м а н и е на параллель с профилем защи¬ ты для смарт-карт, общность целого ряда целей, предположений и требо­ ваний безопасности для криптографических модулей и смарт-карт (что, разумеется, вполне естественно). На н а ш взгляд, сравнительный анализ этого п р о ф и л я и стандарта FIPS 140-2 позволяет в полной мере оценить 236

Федеральный стандарт США FIPS 140-2

Лекция 16

достоинства «Общих критериев» и ассоциированных с п е ц и ф и к а ц и й , вы¬ сокую степень их полноты и систематичности. К о н е ч н о , «Общие крите¬ рии» м о ж н о критиковать, их нужно развивать и совершенствовать, н о пе¬ ревод стандарта FIPS 140-2 на рельсы «Общих критериев», н е с о м н е н н о , повысил бы его качество.

Требования безопасности Часть 1. Спецификация, порты и интерфейсы, роли, сервисы и аутентификация М ы приступаем к детальному рассмотрению первых трех из пере¬ численных в ы ш е одиннадцати групп требований безопасности. В с п е ц и ф и к а ц и и криптографического модуля д о л ж н ы фигурировать аппаратные и / и л и программные к о м п о н е н т ы , в л и я ю щ и е на его безопас¬ ность и заключенные в пределах определенных физических границ — криптографического периметра. Если модуль является программным, в пределах периметра окажутся процессор и другие аппаратные к о м п о н е н ­ ты, хранящие и з а щ и щ а ю щ и е программы. В с п е ц и ф и к а ц и и д о л ж н ы быть определены физические порты и ло¬ гические интерфейсы, все входные и выходные маршруты данных. Следует описать ручные и логические средства управления крипто­ графическим модулем, физические или логические индикаторы состоя­ н и я , п р и м е н и м ы е физические (в частности, электрические) и логические характеристики. В проектной документации необходимо представить схемы взаимо¬ связей таких компонентов, к а к микропроцессоры, буферы ввода/вывода, буферы открытых и ш и ф р о в а н н ы х данных, управляющие буферы, ключе­ вая, рабочая и программная память. Проект должен выполняться с и с ­ пользованием я з ы к а с п е ц и ф и к а ц и й высокого уровня. Следует специфицировать все данные, критичные для безопасности, в том числе криптографические ключи, аутентификационные данные, па¬ раметры криптографических алгоритмов, регистрационные д а н н ы е и т.д. Обязательный элемент документации — политика безопасности криптографического модуля. Прохождение всех и н ф о р м а ц и о н н ы х потоков, к а к и физический до¬ ступ к модулю, производится через определенный набор физических пор¬ тов и логических интерфейсов. И н т е р ф е й с ы д о л ж н ы логически разли¬ чаться, хотя о н и могут разделять один порт (например, для ввода и выво¬ да данных) или охватывать несколько портов (например, вывод данных может осуществляться через последовательный и параллельный порты). П р и к л а д н о й программный интерфейс программного компонента модуля может трактоваться к а к один и л и несколько логических интерфейсов. 237

Курс

Информационная безопасность: основные стандарты и спецификации

Следующие четыре логических интерфейса являются обязательными: • интерфейс ввода данных. Все д а н н ы е , поступающие в модуль для об­ работки и / и л и использования (кроме управляющих данных, см. да­ лее) д о л ж н ы вводиться через этот интерфейс; • интерфейс вывода данных. Все выходные д а н н ы е (кроме информа¬ ции о состоянии, см. далее) д о л ж н ы покидать модуль через этот и н ­ терфейс. П р и возникновении ошибочных ситуаций и во время в ы ­ полнения тестов вывод должен быть запрещен; • входной управляющий интерфейс. Через него д о л ж н ы подаваться все команды и сигналы (в том числе вызовы ф у н к ц и й и ручные уп¬ равляющие воздействия, например, нажатие на переключатель или клавишу), п р и м е н я е м ы е для управления ф у н к ц и о н и р о в а н и е м к р и п ­ тографического модуля; • выходной интерфейс состояния. Через этот интерфейс выдаются все выходные сигналы, индикаторы и и н ф о р м а ц и я о состоянии (в том числе коды завершения и физические индикаторы, в частности, п о ­ казания светодиодов), отображающие состояние криптографичес­ кого модуля. Все внешнее электрическое питание должно поступать через порт питания. Его может и не быть, если применяются внутренние батарейки. Каждому обязательному логическому интерфейсу соответствует свой маршрут данных. Маршрут вывода данных логически отсоединяется от средств обработки в момент генерации, ручного ввода или обнуления клю­ чей. Чтобы предотвратить непреднамеренный вывод данных, критичных для безопасности, следует предусмотреть два независимых внутренних действия, необходимых для использования интерфейсов, применяемых при выводе криптографических ключей, информации ограниченного доступа и т.п. На третьем и четвертом уровнях безопасности порты (интерфейсы), предназначенные для ввода или вывода данных, критичных для безопасно¬ сти, необходимо физически (логически) отделить от других портов (интер¬ фейсов), а критичные данные должны поступать прямо в модуль (например, по непосредственно подсоединенному кабелю или доверенному маршруту). В рамках криптографического модуля для операторов поддержива­ ются роли и ассоциированные с н и м и сервисы и права доступа (ролевой доступ рассматривался в курсе «Основы и н ф о р м а ц и о н н о й безопасности» [3]). Один оператор может быть п р и п и с а н нескольким ролям. Если мо¬ дуль поддерживает параллельную работу нескольких операторов, о н дол¬ ж е н управлять разделением ролей. Требуется поддержка по крайней мере следующих ролей: • роль пользователя. В рамках этой роли выполняются обычные сер­ висы безопасности, включая криптографические операции и другие утвержденные ф у н к ц и и ; 238

Федеральный стандарт США FIPS 140-2

Лекция 16

• роль крипто-офицера. Она предназначена для выполнения крипто­ графической инициализации и иных функций управления — инициа­ лизация модуля, ввод/вывод криптографических ключей, аудит и т.п. Если операторам разрешается производить обслуживание модуля (например, диагностирование аппаратуры и / и л и программ), поддержи¬ вается роль инженера, п р и активизации и завершении которой следует обнулять все н е з а щ и щ е н н ы е критичные данные. Криптографический модуль должен предоставлять следующие сер¬ висы: • отображение состояния; • в ы п о л н е н и е тестов; • в ы п о л н е н и е утвержденной ф у н к ц и и безопасности. Если модуль поддерживает режим обхода (режим без выполнения криптографической обработки данных), то для его активизации необхо­ д и м ы два независимых внутренних действия, а текущее состояние долж­ но соответствующим образом отображаться. Если н е производится чтение, м о д и ф и к а ц и я или замена критичных данных (например, выполняется л и ш ь изучение состояния и л и тестиро­ вание модуля), оператор н е обязан активизировать какую-либо роль. Начиная со второго уровня безопасности, активизации роли должна предшествовать аутентификация оператора: ролевая или (на третьем и четвертом уровнях безопасности) персональная. В стандарте н е оговорены требуемые механизмы аутентификации, с п е ц и ф и ц и р о в а н а л и ш ь их стойкость. Вероятность случайного успеха од­ н о й п о п ы т к и должна составлять менее 1/1000000, вероятность случайно­ го успеха к а к о й - л и б о из нескольких попыток, производимых в течение минуты, — менее 1/100000. Это весьма (а на наш взгляд — чрезмерно) мяг­ к и е требования, если учитывать, что в году 525600 минут. Очевидно, н е ­ обходимы меры противодействия многократным неудачным попыткам аутентификации.

Часть 2. Модель в виде конечного автомата, физическая безопасность В конечноавтоматной модели криптографического модуля д о л ж н ы быть предусмотрены следующие состояния, соответствующие нормаль¬ ному и ошибочному ф у н к ц и о н и р о в а н и ю : • включение/выключение питания (первичного, вторичного, резерв¬ ного); • обслуживание к р и п т о - о ф и ц е р о м (например, управление ключами); • ввод ключей и других критичных данных; • пользовательские состояния (выполнение криптографических опе¬ р а ц и й , предоставление сервисов безопасности); 239

Курс

Информационная безопасность: основные стандарты и спецификации

• самотестирование; • о ш и б о ч н ы е состояния (например, неудача самотестирования или попытка ш и ф р о в а н и я при отсутствии необходимого ключа), кото­ р ы е могут подразделяться на фатальные, требующие сервисного об­ служивания (например, поломка оборудования), и нефатальные, из которых возможен возврат к нормальному ф у н к ц и о н и р о в а н и ю (на¬ пример, путем и н и ц и а л и з а ц и и или перезагрузки модуля). Могут быть предусмотрены и другие, дополнительные состояния: • работа в режиме обхода (передача через модуль открытых данных); • работа в и н ж е н е р н о м режиме (например, физическое и логическое тестирование). Вопросы обеспечения физической безопасности криптографичес­ ких модулей исключительно важны и сложны. В стандарте FIPS 140-2 им уделено очень много в н и м а н и я . М ы , однако, остановимся л и ш ь на ос¬ новных моментах. Стандартом предусмотрены четыре разновидности криптографичес¬ ких модулей: • чисто программные (вопросы физической безопасности для них не рассматриваются); • состоящие из одной микросхемы; • состоящие из нескольких микросхем и встроенные в физически н е ­ з а щ и щ е н н о е окружение (например, плата р а с ш и р е н и я ) ; • состоящие из нескольких микросхем и обладающие автономной за¬ щитой (например, ш и ф р у ю щ и е маршрутизаторы). Меры физической защиты структурированы в стандарте двумя с п о ­ собами. Во-первых, вводится деление на меры выявления свидетельств случившихся ранее нарушений (обнаружение нарушений) и меры в ы я в ­ ления нарушений в реальном времени с выполнением соответствующих ответных действий (реагирование на нарушения). Во-вторых, з а щ и т н ы е меры подразделяются на о б щ и е и с п е ц и ф и ч е ­ ские для той или и н о й разновидности модулей. И, н а к о н е ц , в соответствии с п р и н я т ы м в стандарте подходом, меры группируются по четырем уровням безопасности. М ы ограничимся рассмотрением общих требований физической бе­ зопасности, п р и м е н и м ы х ко всем аппаратным конфигурациям. Если разрешено производить обслуживание модуля и поддерживает­ ся роль инженера, должен быть определен интерфейс обслуживания, включающий все маршруты физического доступа к содержимому модуля, в том числе все съемные оболочки и дверцы (которые необходимо снаб¬ дить подходящими средствами физической защиты). П р и доступе по и н ­ терфейсу обслуживания все хранящиеся в открытом виде секретные клю¬ ч и и другие критичные необходимо обнулить. 240

Федеральный стандарт США FIPS 140-2

Лекция 16

На втором уровне безопасности предусмотрено обнаружение нару¬ ш е н и й , а начиная с третьего — реагирование на нарушения. Для четвертого уровня предусмотрена защита от нештатных в н е ш ­ них условий (электрических или температурных), которая может быть ре­ ализована двояко: • путем постоянного отслеживания электрических и температурных параметров с выключением модуля или обнулением данных, к р и ­ тичных для безопасности, при выходе параметров за допустимые границы; • путем обеспечения устойчивости модуля к нештатным в н е ш н и м ус­ ловиям (например, модуль должен нормально работать при темпера­ турах от -100 до +200 градусов).

Часть 3. Эксплуатационное окружение, управление криптографическими ключами Эксплуатационное окружение — это совокупность необходимых для ф у н к ц и о н и р о в а н и я модуля средств управления аппаратными и п р о ­ граммными компонентами. В стандарте FIPS 140-2 рассматривается н е ­ сколько видов окружения: • универсальное, с коммерческой операционной системой, управляю­ щей как компонентами модуля, так и другими процессами и п р и л о ­ жениями; • ограниченное, являющееся статическим, немодифицируемым (на­ пример, виртуальная Java-машина на непрограммируемой плате для персонального компьютера); • модифицируемое, которое может быть реконфигурировано и вклю¬ чать средства универсальных ОС. Ядро универсального и модифицируемого окружения — о п е р а ц и о н ­ ная система. Н а первом уровне безопасности к ней предъявляются следу­ ю щ и е требования: • используется только однопользовательский режим, параллельная работа нескольких операторов я в н ы м образом запрещается; • доступ процессов, внешних по о т н о ш е н и ю к модулю, к д а н н ы м , к р и т и ч н ы м для безопасности, запрещается, некриптографические процессы не д о л ж н ы прерывать работу криптографического модуля; • программное обеспечение модуля следует защитить от н е с а н к ц и о ­ нированного раскрытия и м о д и ф и к а ц и и ; • целостность П О модуля контролируется утвержденными средствами. Для второго уровня безопасности требуется использование О С , сер­ т и ф и ц и р о в а н н ы х на соответствие определенным п р о ф и л я м защиты на основе «Общих критериев» с оценочным уровнем доверия не н и ж е второ­ го. Для защиты критичных данных должно применяться произвольное 241

Курс

Информационная безопасность: основные стандарты и спецификации

управление доступом с определением соответствующих ролей. Необходи¬ мо протоколирование действий крипто-офицера. Характерная черта третьего уровня безопасности — использование доверенного маршрута. На четвертом уровне безопасности криптографического модуля нужна О С с о ц е н о ч н ы м уровнем доверия не н и ж е четвертого. Требования безопасного управления криптографическими ключами охватывают весь ж и з н е н н ы й ц и к л критичных данных модуля. Рассматри­ ваются следующие управляющие функции: • генерация случайных чисел; • генерация ключей; • распределение ключей; • ввод/вывод ключей; • хранение ключей; • обнуление ключей. Секретные ключи необходимо защищать от несанкционированного раскрытия, м о д и ф и к а ц и и и подмены, открытие — от м о д и ф и к а ц и и и подмены. Компрометация методов генерации или распределения ключей (на­ пример, угадывание затравочного значения, инициализирующего детер¬ м и н и р о в а н н ы й генератор случайных чисел) должна быть не п р о щ е опре¬ деления значений ключей. Для распределения ключей может применяться как ручная транс­ портировка, так и автоматические процедуры согласования ключей. Допускается ручной (с клавиатуры) и автоматический (например, при п о м о щ и смарт-карты) ввод ключей. На двух н и ж н и х уровнях безо¬ пасности при автоматическом вводе секретные ключи д о л ж н ы быть за¬ ш и ф р о в а н ы ; ручной ввод может осуществляться в открытом виде. На тре­ тьем и четвертом уровнях при ручном вводе ключей в открытом виде п р и ­ меняются процедуры разделения знаний. Модуль должен ассоциировать введенный ключ (секретный или от¬ крытый) с владельцем (лицом, процессом и т.п.).

Часть 4. Самотестирование, доверие проектированию, сдерживание прочих атак, другие рекомендации М ы приступаем к рассмотрению трех последних из одиннадцати предусмотренных стандартом FIPS 140-2 групп требований безопасности для криптографических модулей. Криптографический модуль должен выполнять самотестирование при включении питания, при в ы п о л н е н и и некоторых условий (когда в ы ­ зывается ф у н к ц и я безопасности, для которой предусмотрено тестирова¬ ние), а также по требованию оператора. 242

Федеральный стандарт США FIPS 140-2

Лекция 16

Необходимо, чтобы тесты покрывали все ф у н к ц и и модуля ( з а ш и ф ­ рование, р а с ш и ф р о в а н и е , аутентификацию и т.д.). Для определения пра­ вильности прохождения тестов может применяться как сравнение с зара¬ нее известными, эталонными результатами, так и анализ согласованнос¬ ти результатов двух независимых реализаций одной и той ж е ф у н к ц и и . С п е ц и ф и ц и р о в а н ы следующие виды проверок: • тесты криптографических алгоритмов; • контроль целостности программного обеспечения; • тесты ф у н к ц и й , критичных для безопасности модуля. В число проверок, выполняемых по условию, входят: • проверка взаимной согласованности парных ключей; • контроль загружаемых программ; • контроль ключей, вводимых вручную; • тест генератора случайных чисел; • тест режима обхода. Меры доверия проектированию, заданные стандартом, распространя­ ются на конфигурационное управление, процедуры безопасной установки, генерации и распространения, процесс разработки и документацию. Документация, представляемая разработчиком на первом уровне бе¬ зопасности, должна специфицировать соответствие между проектом крип¬ тографического модуля и его политикой безопасности, а комментарии в исходном тексте — между проектом и программными компонентами. На втором уровне предусмотрена функциональная с п е ц и ф и к а ц и я с н е ф о р м а л ь н ы м описанием модуля, внешних портов и интерфейсов, их назначения. На третьем уровне программные к о м п о н е н т ы д о л ж н ы быть реализо¬ ваны на я з ы к е высокого уровня, за исключением, быть может, небольшо­ го числа ассемблерных вставок. Высокоуровневая с п е ц и ф и к а ц и я требу­ ется и для аппаратуры. На четвертом уровне устанавливается формальная модель политики безопасности с обоснованием ее полноты и непротиворечивости и не¬ формальной демонстрацией соответствия ф у н к ц и о н а л ь н ы м с п е ц и ф и к а ­ ц и я м . В исходных текстах программных компонентов должны быть пред­ ставлены необходимые предусловия и ожидаемые постусловия. Комплект документации состоит из руководства крипто-офицера (аналог руководства администратора) и пользователя. Криптографические модули могут стать объектом самых разных атак, основанных, например, на анализе потребляемого электропитания или времени выполнения операций, на переводе модуля в с б о й н ы й ре¬ ж и м , на анализе побочных электромагнитных излучений и наводок и т.д. Для противодействия анализу потребляемого электропитания в м о ­ дуль могут встраиваться конденсаторы, использоваться внутренние и с 243

Курс

Информационная безопасность: основные стандарты и спецификации

точники питания, вставляться специальные инструкции для выравнива­ н и я потребления электропитания в процессе в ы п о л н е н и я криптографи¬ ческих ф у н к ц и й . Средство сдерживания атак, основанных на анализе времени выпол­ н е н и я операций, — вставка дополнительных инструкций, сглаживающих различия во времени работы. Для противодействия атакам, о с н о в а н н ы м на переводе модуля в сбойный режим, стандарт рекомендует о п и с а н н ы е в ы ш е меры физичес¬ кой защиты. В качестве приложений стандарт F I P S 140-2 содержит рекоменда¬ ц и и , д о п о л н я ю щ и е одиннадцать групп требований безопасности. К н и м относятся: • сводка требований к документации; • рекомендуемые правила разработки программного обеспечения; • рекомендуемое содержание политики безопасности криптографиче¬ ского модуля. В заключение еще раз подчеркнем роль стандарта F I P S 140-2 как ба¬ зового элемента других с п е ц и ф и к а ц и й в области и н ф о р м а ц и о н н о й безо¬ пасности, включая п р о ф и л и защиты сервисов безопасности, их комбина¬ ц и й и приложений. Очевидно, весьма желательна разработка российско¬ го аналога данного документа.

244

Лекция 17

Заключение

Л е к ц и я 17. З а к л ю ч е н и е Подводится итог курса, кратко суммируются полученные знания.

Ключевые слова: закон, стандарт, с п е ц и ф и к а ц и я , н а к о п л е н и е и и с ­ пользование з н а н и й , административный уровень И Б , процедурный уровень И Б , программно-технический уровень И Б , профилактичес­ кие меры, меры реагирования, ц и ф р о в о й сертификат, О б щ и е крите­ р и и , Проект О К , требования безопасности, ф у н к ц и о н а л ь н ы е требо­ вания, требования доверия, профиль защиты, сервис безопасности, к о м б и н а ц и я сервисов безопасности, приложения сервисов безопас­ ности, и д е н т и ф и к а ц и я , аутентификация, управление доступом, ау¬ дит б е з о п а с н о с т и , у п р а в л е н и е к р и п т о г р а ф и ч е с к и м и к л ю ч а м и , криптографические операции, надежное восстановление, посредни¬ чество при обращениях, разделение доменов, доверенный канал, д о ­ веренный маршрут, функциональная с п е ц и ф и к а ц и я , проект верхне­ го уровня, стойкость ф у н к ц и и безопасности, уязвимость, управле¬ ние конфигурацией, экранирование, анализ з а щ и щ е н н о с т и , архи¬ тектурные требования, многоаспектная и н ф о р м а ц и о н н а я безопас­ ность, к л а с с и ф и к а ц и о н н а я схема, квота, собственная з а щ и щ е н ­ ность, эталонная семиуровневая модель, сетевой уровень, транс­ портный уровень, избирательная конфиденциальность, неотказуемость, конфиденциальность трафика, целостность с восстановлени¬ ем, целостность вне соединения, аутентификация источника д а н ­ ных, защита от воспроизведения, протокол аутентифицирующего заголовка, п р о т о к о л и н к а п с у л и р у ю щ е й з а щ и т ы с о д е р ж и м о г о , транспортный режим, туннельный режим, контекст безопасности, управляющий контекст, протокольный контекст, база данных поли¬ тики безопасности, база данных протокольных контекстов безопас¬ ности, правило политики безопасности, фильтрация потоков дан¬ ных, п р е о б р а з о в а н и е п о т о к о в д а н н ы х , п р о т о к о л б е з о п а с н о с т и транспортного уровня, пассивное прослушивание сети, активное прослушивание сети, подделка сообщений, протокол передачи за¬ писей, протокол установления соединений, компьютерная крипто­ графия, алгоритмический аспект, и н т е р ф е й с н ы й аспект, удостовере¬ ние, токен безопасности, механизм безопасности, мобильность при¬ л о ж е н и й , открытость приложений, Internet, угроза, риск, ущерб, ре­ агирование на нарушение, ликвидация нарушения, группа реагиро­ вания на нарушения и н ф о р м а ц и о н н о й безопасности, опекаемое с о ­ общество, доклад о нарушении, поставщик Internet-услуг, потреби­ тель Internet-услуг. 245

Курс

Информационная безопасность: основные стандарты и спецификации

Основные идеи курса З н а н и е стандартов и с п е ц и ф и к а ц и й важно для специалистов в обла­ сти и н ф о р м а ц и о н н о й безопасности по целому ряду п р и ч и н , главная из которых состоит в том, что стандарты и с п е ц и ф и к а ц и и — одна из ф о р м накопления з н а н и й , в первую очередь о процедурном и программно-тех­ ническом уровнях И Б . В них зафиксированы апробированные, высоко­ качественные решения и методологии, разработанные наиболее квали¬ ф и ц и р о в а н н ы м и специалистами. В статье 12 з а к о н а Р Ф «О т е х н и ч е с к о м р е г у л и р о в а н и и » о п р е д е л е н п р и н ц и п п р и м е н е н и я м е ж д у н а р о д н о г о стандарта к а к о с н о в ы разра¬ ботки н а ц и о н а л ь н о г о стандарта. Это означает, что з н а н и е междуна¬ р о д н ы х стандартов требуется д л я п о н и м а н и я н а п р а в л е н и й р а з в и т и я о т е ч е с т в е н н о й н о р м а т и в н о й б а з ы , ч т о , в с в о ю очередь, в а ж н о для в ы ­ р а б о т к и стратегии п о с т р о е н и я и с о в е р ш е н с т в о в а н и я и н ф о р м а ц и о н ¬ н ы х систем. Количество стандартов и с п е ц и ф и к а ц и й в области И Б велико. В курсе рассмотрены наиболее существенные из них, изучение которых не¬ обходимо всем или почти всем разработчикам, о ц е н щ и к а м , администра¬ торам, руководителям, пользователям. В курсе выделены две группы стандартов и с п е ц и ф и к а ц и й : • оценочные стандарты, направленные на оценивание и классифика¬ цию и н ф о р м а ц и о н н ы х систем и средств защиты по требованиям бе¬ зопасности; • с п е ц и ф и к а ц и и , регламентирующие различные аспекты реализации и использования средств и методов защиты. Обе группы д о п о л н я ю т друг друга. О ц е н о ч н ы е стандарты выделя­ ют в а ж н е й ш и е п о н я т и я и аспекты И С , играя роль о р г а н и з а ц и о н н ы х и архитектурных с п е ц и ф и к а ц и й . Другие с п е ц и ф и к а ц и и определяют, к а к строить И С п р е д п и с а н н о й архитектуры и в ы п о л н я т ь о р г а н и з а ц и о н н ы е требования. И з числа рассмотренных в курсе оценочных стандартов необходимо выделить международный стандарт «Критерии о ц е н к и безопасности ин¬ ф о р м а ц и о н н ы х технологий» (точнее, его первоисточник — «Общие кри¬ терии») и разработанные на его основе п р о ф и л и защиты. Это — основа современной системы сертификации по требованиям безопасности, с и с ­ темы, к которой стремится присоединиться и Россия. О с н о в н ы м источником технических с п е ц и ф и к а ц и й , п р и м е н и м ы х к современным распределенным И С , является Internet-сообщество, уделя¬ ющее в н и м а н и е не только программно-техническому, но также админис¬ тративному и процедурному уровням и н ф о р м а ц и о н н о й безопасности. Комплексность подхода Internet-сообщества к проблемам И Б проявляет246

Лекция 17

Заключение

ся и в том, что в с п е ц и ф и к а ц и я х рассматриваются к а к профилактические меры, направленные на предупреждение нарушений И Б , так и меры реа¬ гирования на нарушения. Вероятно, среди многих международных стан¬ дартов, затрагивающих вопросы сетевой безопасности, наиболее часто цитируется документ X.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибутов». Этот стандарт важен и к а к образец тща¬ тельной проработки и продуманного развития простой, н о весьма глубо¬ кой идеи — идеи цифрового сертификата, способного хранить атрибуты произвольной природы. Очень ц е н н о , когда стандарт н е просто что-то требует, н о предлагает образцы, помогающие выполнить те или и н ы е требования. К числу таких конструктивных стандартов принадлежит BS 7799 ( I S O / I E C 17799), д а ю ­ щ и й возможность справиться с проблемами административного и проце¬ дурного уровней и н ф о р м а ц и о н н о й безопасности.

«Общие к р и т е р и и » и п р о ф и л и з а щ и т ы на и х о с н о в е « П р о е к т О К » , результатом к о т о р о г о с т а л и « О б щ и е к р и т е р и и о ц е н к и б е з о п а с н о с т и и н ф о р м а ц и о н н ы х технологий», н о с и т н е т о л ь к о т е х н и ч е с к и й , н о и э к о н о м и к о - п о л и т и ч е с к и й характер. Его цель состо¬ ит, в ч а с т н о с т и , в т о м , ч т о б ы у п р о с т и т ь , удешевить и ускорить путь с е р т и ф и ц и р о в а н н ы х и з д е л и й и н ф о р м а ц и о н н ы х технологий н а миро¬ вой р ы н о к . Эта цель близка и п о н я т н а р о с с и й с к и м специалистам. В 2002 году был о ф и ц и а л ь н о издан Г О С Т Р И С О / М Э К 15408-2002 «Критерии о ц е н ­ ки безопасности и н ф о р м а ц и о н н ы х технологий» с датой введения в д е й ­ ствие первого я н в а р я 2004 г. Таким образом, и Россия фактически живет по «Общим критериям» со всеми в ы т е к а ю щ и м и и з данного факта п о ­ следствиями. В рамках «Проекта О К » , п о м и м о «Общих критериев», разработан целый р я д документов, среди которых выделяется «Общая методология о ц е н к и безопасности и н ф о р м а ц и о н н ы х технологий», облегчающая и у н и ф и ц и р у ю щ а я п р и м е н е н и е ОК. С о г л а с н о подходу, п р и н я т о м у в « О б щ и х критериях», н а основа¬ н и и п р е д п о л о ж е н и й б е з о п а с н о с т и , п р и учете угроз и п о л о ж е н и й поли¬ т и к и б е з о п а с н о с т и ф о р м у л и р у ю т с я ц е л и б е з о п а с н о с т и д л я объекта о ц е н к и . Д л я их д о с т и ж е н и я к объекту и его среде п р е д ъ я в л я ю т с я т р е ­ бования безопасности. «Общие критерии» в главной своей части являются каталогом (биб­ лиотекой) требований безопасности. Спектр стандартизованных требова¬ н и й чрезвычайно ш и р о к , что способствует универсальности О К . Высо¬ к и й уровень детализации делает их к о н к р е т н ы м и , допускающими о д н о 247

Курс

Информационная безопасность: основные стандарты и спецификации

значную проверку, способствует повторяемости результатов оценки. Тре­ бования параметризованы, что обеспечивает их гибкость. «Общие критерии» содержат два основных вида требований безопас¬ ности: • ф у н к ц и о н а л ь н ы е , соответствующие активному аспекту з а щ и т ы , предъявляемые к ф у н к ц и я м безопасности объекта о ц е н к и и реали¬ зующим их механизмам; • требования доверия, соответствующие пассивному аспекту, предъ­ являемые к технологии и процессу разработки и эксплуатации объ¬ екта оценки. Библиотека функциональных требований составляет вторую часть «Общих критериев», а каталог требований доверия — третью часть (первая содержит изложение основных к о н ц е п ц и й О К ) . После того как сформулированы ф у н к ц и о н а л ь н ы е требования, тре­ бования доверия и требования к среде, возможна оценка безопасности изделия ИТ. Для типовых изделий «Общие критерии» предусматривают разработку типовых совокупностей требований безопасности — профи¬ лей защиты. Рассматриваемые в курсе п р о ф и л и делятся на следующие категории: • п р о ф и л и защиты для отдельных сервисов безопасности; • п р о ф и л и з а щ и т ы для к о м б и н а ц и й и п р и л о ж е н и й сервисов безо¬ пасности. К р о м е того, в ы д е л я ю т с я о б щ и е т р е б о в а н и я к с е р в и с а м безопас¬ н о с т и . К ч и с л у в а ж н е й ш и х в и д о в ф у н к ц и о н а л ь н ы х т р е б о в а н и й при¬ надлежат: • идентификация ( F I A U I D ) и аутентификация ( F I A U A U ) ; • определение атрибутов пользователя ( F I A A T D ) ; • связывание пользователь-субъект ( F I A U S B ) ; • политика управления доступом ( F D P A C C ) ; • ф у н к ц и и управления доступом ( F D P A C F ) ; • генерация данных аудита безопасности ( F A U G E N ) ; • анализ аудита безопасности ( F A U S A A ) ; • управление криптографическими ключами ( F C S C K M ) ; • криптографические операции ( F C S C O P ) ; • базовая защита внутренней передачи ( F D P ITT); • защита остаточной и н ф о р м а ц и и ( F D P R I P ) ; • целостность экспортируемых данных ( F P T I T I ) ; • управление отдельными ф у н к ц и я м и безопасности ( F M T M O F ) ; • управление д а н н ы м и ф у н к ц и й безопасности ( F M T M T D ) ; • безопасность при сбое ( F P T F L S ) ; • надежное восстановление ( F P T R C V ) ; • посредничество при обращениях ( F P T R V M ) ; 248

Лекция 17

Заключение

• разделение доменов ( F P T S E P ) ; • д о в е р е н н ы й к а н а л передачи между ф у н к ц и я м и б е з о п а с н о с т и (FTPITC); • доверенный маршрут ( F T P T R P ) . В качестве важнейших общих требований доверия безопасности в ы ­ деляются: • анализ ф у н к ц и о н а л ь н о й с п е ц и ф и к а ц и и , с п е ц и ф и к а ц и и интерфей¬ сов, эксплуатационной документации; • независимое тестирование; • наличие проекта верхнего уровня; • анализ стойкости ф у н к ц и й безопасности; • п о и с к разработчиком я в н ы х уязвимостей; • контроль среды разработки; • управление конфигурацией. П р о ф и л и защиты и их проекты, рассматриваемые в курсе, примени¬ м ы к следующим сервисам безопасности: • (биометрическая) идентификация и аутентификация; • управление доступом (произвольное, принудительное, ролевое); • (межсетевое) экранирование; • (активный) аудит; • анализ защищенности. Изучаются также инфраструктурные элементы и н ф о р м а ц и о н н о й безопасности: • анонимизаторы; • выпуск и управление сертификатами. Выделим представленный в курсе профиль защиты для одной из раз¬ новидностей анонимизаторов. О н поучителен по крайней мере по двум причинам: • в нем продемонстрирована важность архитектурных требований для обеспечения и н ф о р м а ц и о н н о й безопасности и недостаточность со¬ ответствующих средств «Общих критериев»; • он характеризует становление так называемой многоаспектной ин¬ ф о р м а ц и о н н о й безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих) всех субъектов информа¬ ц и о н н ы х отношений. В свою очередь, изучение упорядоченного семейства из четырех п р о ф и л е й защиты для аппаратно-программных компонентов, реализую¬ щ и х выпуск, аннулирование и управление сертификатами открытых клю¬ чей, способствует активному овладению идеями и п о н я т и я м и стандарта X.509. К р о м е того, д а н н о е семейство может служить примером при пост¬ роении к л а с с и ф и к а ц и о н н ы х схем в Руководящих документах Гостехко¬ миссии России. 249

Курс

Информационная безопасность: основные стандарты и спецификации

Важнейшей (и наиболее привычной) комбинацией сервисов безопас¬ ности являются операционные системы. К а к таковые они содержат л и ш ь небольшое число специфических требований, среди которых выделяются: • максимальные квоты ( F R U R S A . 1 ) ; • дополнительный элемент F A U G E N . 1 - C S P P . 3 , предписывающий предоставление прикладного программного интерфейса для добав­ ления собственных данных к общему регистрационному журналу и / и л и для ведения п р и л о ж е н и я м и собственных журналов; • ряд дополнительных требований, направленных на обеспечение к о н ­ фиденциальности ( F P T ITC.1.1-CSPP), целостности ( F P T ITI.1.1C S P P ) , согласованности ( F P T SYN-CSPP.1.1) критичных данных функций безопасности в распределенных конфигурациях. Анализ п р о ф и л я защиты для систем управления базами данных по¬ казывает, что при использовании стандартных требований «Общих кри¬ териев» существует опасность оставить за рамками рассмотрения специ¬ фические свойства приложений и присущие и м угрозы. Весьма поучителен профиль защиты для смарт-карт, при его изуче¬ н и и м о ж н о усмотреть множество аналогий со стандартом FIPS 140-2 «Требования безопасности для криптографических модулей». И профиль, и стандарт — хорошие п р и м е р ы систематического подхода к вопросам собственной защищенности средств безопасности. И з числа специфических функциональных требований п р о ф и л я особого в н и м а н и я заслуживают: • автоматическая реакция аудита безопасности ( F A U A R P ) ; • противодействие физическому нападению ( F P T P H P . 3 ) . Отметим также выделение двух функциональных пакетов: для интег¬ ральной схемы и базового П О . Это — пример модульности, важной не толь¬ ко для программирования, но и вообще для работы с большими системами. «Общие критерии» — исключительно м о щ н о е , гибкое средство раз¬ работки требований безопасности для изделий и н ф о р м а ц и о н н ы х техно­ логий. В то ж е время, сама гибкость «Общих критериев» является источ­ н и к о м сложных проблем, в первую очередь относящихся к методологии разработки п р о ф и л е й защиты. П о результатам рассмотрения О К м о ж н о наметить следующие н а ­ правления дальнейших исследований и разработок: • создание новых профилей защиты, охватывающих все сервисы безо¬ пасности; • разработка д и с ц и п л и н ы и инструментальных средств для работы с множеством профилей защиты; • развитие «Общих критериев», разработка новых стандартных требо¬ ваний безопасности, как «точечных», так и концептуальных, архи¬ тектурных. 250

Лекция 17

Заключение

Спецификации Internet-сообщества д л я п р о г р а м м н о - т е х н и ч е с к о г о у р о в н я ИБ И з множества с п е ц и ф и к а ц и й Internet-сообщества, относящихся к программно-техническому уровню и н ф о р м а ц и о н н о й безопасности, для данного курса были выбраны три: IPsec, T L S и G S S - A P I . Выбор IPsec и T L S основан на том, что к а к на сетевом, так и на транспортном уровне эталонной семиуровневой модели могут быть реа¬ лизованы практически все ф у н к ц и и безопасности, выделенные в специ¬ ф и к а ц и и X.800 (см. курс «Основы и н ф о р м а ц и о н н о й безопасности» [3]). (Исключение составляют избирательная конфиденциальность и неотказуемость; кроме того, конфиденциальность трафика реализуется на сете¬ вом, н о н е на транспортном уровне, а целостность с восстановлением — наоборот, на транспортном, н о н е на сетевом уровне.) П р о т о к о л ы IPsec обеспечивают у п р а в л е н и е доступом, целостность в н е с о е д и н е н и я , а у т е н т и ф и к а ц и ю и с т о ч н и к а д а н н ы х , защиту от в о с ­ п р о и з в е д е н и я , к о н ф и д е н ц и а л ь н о с т ь и частичную защиту от анализа трафика. О с н о в н ы м и элементами архитектуры средств безопасности для IPуровня являются протокол аутентифицирующего заголовка и протокол инкапсулирующей защиты содержимого, а также механизмы управления криптографическими ключами. Протокол аутентифицирующего заголовка служит в IPsec для обес­ печения целостности пакетов и аутентификации источника данных, а также для защиты от воспроизведения ранее посланных пакетов. О н за­ щищает д а н н ы е протоколов более высоких уровней и те поля IP-заголов­ ков, которые н е меняются на маршруте доставки или меняются предска¬ зуемым образом. Протокол инкапсулирующей защиты содержимого предоставляет три вида сервисов безопасности: • обеспечение конфиденциальности ( ш и ф р о в а н и е содержимого IPпакетов, а также частичная защита от анализа трафика путем п р и м е ­ н е н и я туннельного режима); • обеспечение целостности IP-пакетов и аутентификации источника данных; • обеспечение защиты от воспроизведения IP-пакетов. Протоколы обеспечения аутентичности и конфиденциальности м о ­ гут использоваться в двух режимах: транспортном и туннельном. В п е р ­ вом случае защищается только содержимое пакетов и, быть может, н е к о ­ торые поля заголовков. В туннельном режиме защищается весь пакет. П р и взаимодействии средствами IPsec стороны д о л ж н ы выработать о б щ и й контекст безопасности и затем применять элементы этого контек251

Курс

Информационная безопасность: основные стандарты и спецификации

ста, такие к а к алгоритмы и их ключи. За ф о р м и р о в а н и е контекстов безо¬ пасности в IPsec отвечает особое семейство протоколов. Ф о р м и р о в а н и е контекстов безопасности в IPsec разделено на две фазы. Сначала создается управляющий контекст, назначение которого — предоставить доверенный канал для выработки (в рамках второй фазы) протокольных контекстов. Протокольный контекст безопасности в IPsec — это однонаправлен¬ ное «соединение» (от источника к получателю), предоставляющее обслу­ ж и в а е м ы м потокам данных набор защитных сервисов. Пользователями протокольных контекстов, к а к правило, являются прикладные процессы. Системы, реализующие IPsec, должны поддерживать две базы дан¬ ных: • базу данных политики безопасности; • базу данных протокольных контекстов безопасности. Все I P - п а к е т ы ( в х о д я щ и е и и с х о д я щ и е ) с о п о с т а в л я ю т с я с упоря¬ д о ч е н н ы м н а б о р о м п р а в и л п о л и т и к и б е з о п а с н о с т и . П р и сопоставле¬ н и и используется ф и г у р и р у ю щ и й в к а ж д о м п р а в и л е селектор — сово¬ к у п н о с т ь а н а л и з и р у е м ы х п о л е й сетевого и более в ы с о к и х протоколь¬ н ы х у р о в н е й . П е р в о е п о д х о д я щ е е п р а в и л о определяет характер обра¬ ботки пакета. Таким образом, системы, реализующие IPsec, функционируют в ду¬ хе межсетевых экранов, фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности. Протокол безопасности транспортного уровня (TLS) — развитие версии 3.0 протокола SSL. Посредством протокола T L S приложения, п о ­ строенные в архитектуре клиент/сервер, могут защититься от пассивного и активного прослушивания сети и подделки сообщений. T L S имеет двухуровневую организацию. Н а первом уровне, о п и р а ю ­ щемся на надежный транспортный сервис, располагается протокол пере­ дачи записей, на втором — протокол установления соединений. П р о т о к о л передачи записей обеспечивает к о н ф и д е н ц и а л ь н о с т ь и целостность передаваемых д а н н ы х . П р е д с т а в и м его ф у н к ц и о н и р о в а н и е в о б щ е м виде. С о о б щ е н и е разбивается н а б л о к и ( з а п и с и ) , с ж и м а е т с я , снабжается и м и т о в с т а в к о й , ш и ф р у е т с я , после чего в ы п о л н я е т с я п е р е ­ дача результата. Н а с т о р о н е получателя п р и н я т ы е д а н н ы е р а с ш и ф р о ­ вываются, в е р и ф и ц и р у ю т с я , подвергаются д е к о м п р е с с и и и сборке, и затем с о о б щ е н и е доставляется клиенту н а в ы ш е л е ж а щ е м протоколь¬ н о м уровне. Протокол установления соединений позволяет серверу и клиенту провести взаимную аутентификацию, согласованно выбрать алгоритм ш и ф р о в а н и я и криптографические ключи, прежде ч е м прикладной про¬ токол начнет передачу данных. П р и выработке совместных секретов 252

Лекция 17

Заключение

обеспечивается конфиденциальность, целостность и защита от нелегаль¬ ного посредника. В с п е ц и ф и к а ц и я х T L S фигурируют четыре криптографические опе­ рации: цифровая подпись, потоковое ш и ф р о в а н и е , блочное ш и ф р о в а н и е и ш и ф р о в а н и е открытым ключом. Компьютерная криптография — это большая и сложная тема, для ко¬ торой особенно важно разбиение на относительно независимые аспекты. М ы выделим три из них: • алгоритмический; • интерфейсный; • собственной защищенности. Алгоритмического аспекта м ы не касаемся. Вопросам собственной з а щ и щ е н н о с т и криптографических средств п о с в я щ е н ы стандарт FIPS 140-2 и профиль защиты для смарт-карт. И н т е р ф е й с н ы й аспект — пред­ мет с п е ц и ф и к а ц и и Internet-сообщества «Обобщенный прикладной про¬ граммный интерфейс службы безопасности» (некоторое в н и м а н и е этому аспекту уделено и в стандарте FIPS 140-2). Интерфейс G S S - A P I преследует цель защиты к о м м у н и к а ц и й между к о м п о н е н т а м и программных систем, построенных в архитектуре кли¬ ент/сервер. О н предоставляет услуги по взаимной аутентификации обща­ ющихся партнеров и по контролю целостности и обеспечению конфи¬ денциальности пересылаемых сообщений. О с н о в н ы м и п о н я т и я м и обобщенного прикладного программного интерфейса службы безопасности являются: • удостоверение; • контекст безопасности; • токен безопасности; • механизм безопасности; • имя; • канал передачи данных. И н т е р ф е й с G S S - A P I предоставляет следующие о с н о в н ы е виды функций: • работа с удостоверениями; • создание и уничтожение контекстов безопасности; • защита сообщений; • вспомогательные функции. О б о б щ е н н ы й и н т е р ф е й с безопасности н е зависит от я з ы к о в о й сре¬ д ы и механизмов безопасности, о б е с п е ч и в а ю щ и х реальную защиту. П р и л о ж е н и я , и с п о л ь з у ю щ и е G S S - A P I , на уровне исходного текста мо¬ бильны по о т н о ш е н и ю к с м е н е механизмов безопасности. Тем с а м ы м реализуется открытость п р и к л а д н ы х систем и соответствующих средств защиты. 253

Курс

Информационная безопасность: основные стандарты и спецификации

Спецификации Internet- сообщества д л я а д м и н и с т р а т и в н о г о и п р о ц е д у р н о г о у р о в н е й ИБ В курсе рассматривается три с п е ц и ф и к а ц и и Internet-сообщества для административного и процедурного уровней и н ф о р м а ц и о н н о й безопас¬ ности: • «Руководство по и н ф о р м а ц и о н н о й безопасности предприятия»; • «Как реагировать на нарушения и н ф о р м а ц и о н н о й безопасности»; • «Как выбирать поставщика Интернет-услуг». Центральную роль играет «Руководство по и н ф о р м а ц и о н н о й безо­ пасности предприятия». В Руководстве перечисляются вопросы и факто¬ р ы , которые следует проанализировать при ф о р м и р о в а н и и политики бе¬ зопасности, о н о отвечает на вопросы о том, что входит в политику безо¬ пасности, какие процедуры необходимы для обеспечения безопасности, что нужно делать в ситуациях, угрожающих безопасности. Ф о р м и р о в а н и е политики и процедур безопасности означает выра¬ ботку плана действий по и н ф о р м а ц и о н н о й защите, для чего необходимо: • выяснить, что следует защищать; • выяснить, от чего следует защищаться; • определить вероятность угроз; • реализовать меры, которые позволят защитить активы экономичес¬ ки оправданным образом; • постоянно возвращаться к предыдущим этапам и совершенствовать защиту после выявления новых уязвимых мест. В Руководстве основной упор делается на два последних этапа. Когда политика выработана, м о ж н о приступать к созданию проце¬ дур, решающих проблемы безопасности. С и с т е м н ы е а д м и н и с т р а т о р ы и р у к о в о д и т е л и д о л ж н ы з н а т ь со¬ временные угрозы, связанные с ними риски, размер возможного ущерба, а также набор доступных мер для предотвращения и отраже­ ния нападений. Очень важны рассматриваемые в Руководстве меры реагирования на нарушения, а также действия, предпринимаемые после ликвидации нару¬ ш е н и й безопасности. Следует помнить, что планирование защитных дей¬ ствий — это непрерывный циклический процесс. Тема реагирования развивается в с п е ц и ф и к а ц и и Internet-сообщест­ ва «Как реагировать на нарушения и н ф о р м а ц и о н н о й безопасности». Цель данной с п е ц и ф и к а ц и и — сформулировать ожидания Internetсообщества по о т н о ш е н и ю к группам реагирования на нарушения ин¬ ф о р м а ц и о н н о й безопасности. Потребители имеют право понимать пра¬ вила и процедуры работы своей группы реагирования и нуждаются в этих знаниях. 254

Лекция 17

Заключение

Коллектив, называющий себя группой реагирования, должен реаги­ ровать на выявленные нарушения безопасности и на угрозы своим подо­ п е ч н ы м , действуя в интересах конкретного сообщества и способами, п р и ­ н я т ы м и в этом сообществе. Чтобы считаться группой реагирования, необходимо: • предоставлять з а щ и щ е н н ы й канал для приема сообщений о предпо­ лагаемых нарушениях; • оказывать п о м о щ ь членам опекаемого сообщества в ликвидации на¬ рушений; • распространять и н ф о р м а ц и ю , относящуюся к нарушению, в преде¬ лах опекаемого сообщества и другим заинтересованным сторонам. Группа реагирования должна объяснить, кого она опекает, и опреде­ лить предоставляемые услуги, опубликовать свои правила и регламенты, порядок доклада о нарушениях. С практической точки зрения, очень важно «Дополнение к Руковод­ ству по и н ф о р м а ц и о н н о й безопасности предприятия: К а к выбирать п о ­ ставщика Internet-услуг», призванное помочь в выработке политики и процедур безопасности в тех организациях, и н ф о р м а ц и о н н ы е системы которых подключены к Internet, а также служить для потребителей кон¬ трольным перечнем при обсуждении вопросов и н ф о р м а ц и о н н о й безо¬ пасности с поставщиками Internet-услуг. В заключение еще раз подчеркнем важность внимательного изуче¬ н и я и активного овладения з н а н и я м и , заложенными в стандарты и спе­ ц и ф и к а ц и и в области и н ф о р м а ц и о н н о й безопасности. Это необходимо к а к отдельным специалистам для получения базовой к в а л и ф и к а ц и и , так и организациям, выстраивающим долгосрочную стратегию и заботящим­ ся о защите своих интересов.

255

Обязательная литература 1. Галатенко В.А. Информационная безопасность — практический подход. П о д ред. В.Б. Бетелина. — М.: Наука, 1998. — 301 с. 2. Трубачев А . П . и д р . Оценка безопасности информационных технологий. П о д общ. ред. В.А. Галатенко. — М.: С И П РИА, 2001. — 356 с. 3. Галатенко В.А. Основы информационной безопасности. Под. ред. В.Б. Бетелина. — М.: И н т е р н е т - у н и в е р с и т е т информационных технологий, 2006, 208 с. 4. Гайкович В., П е р ш и н А. Безопасность электронных банковских систем. — М.: «Единая Европа», 1994. 5. Russel D . , Gangemi G.T. Sr. Computer Security Basics. — O'Reilly & Associates, Inc., 1992. 6. Буч Г. Объектно—ориентированный анализ и проектирование с примерами приложений на C+ + , 2—е и з д . / П е р . с англ. — М . : «Издательство Бином», СПб.: «Невский диалект», 2001. — 560 с.

256

Статьи по т е м е к у р с а 7. Безопасность и н ф о р м а ц и о н н ы х технологий. Контролируемый доступ. П р о ф и л ь защиты (первая редакция). — Центр безопасности ин¬ ф о р м а ц и и , 2002. 8. Безопасность и н ф о р м а ц и о н н ы х технологий. Меточная защита. П р о ф и л ь защиты (первая редакция). — Центр безопасности информа¬ ц и и , 2002. 9. Безопасность и н ф о р м а ц и о н н ы х технологий. Многоуровневые о п е р а ц и о н н ы е системы в средах, требующих среднюю робастность. Про¬ ф и л ь защиты (вторая редакция). — Центр безопасности и н ф о р м а ц и и , 2002. 10. Безопасность и н ф о р м а ц и о н н ы х технологий. Одноуровневые о п е р а ц и о н н ы е системы в средах, требующих среднюю робастность. Про¬ ф и л ь защиты (вторая редакция). — Центр безопасности и н ф о р м а ц и и , 2002. 11. Безопасность и н ф о р м а ц и о н н ы х технологий. Система управле¬ н и я базой данных. П р о ф и л ь защиты (первая редакция). — Центр безопас¬ ности и н ф о р м а ц и и , 2002. 12. Бетелин В.Б., Галатенко А.В., Галатенко В.А., Кобзарь М.Т., С и дак А.А. К л а с с и ф и к а ц и я средств активного аудита в терминах " О б щ и х критериев". — В сб. " И н ф о р м а ц и о н н а я безопасность. Инструменталь­ н ы е средства программирования. Базы д а н н ы х " под ред. чл.—корр. РАН В.Б. Бетелина. — М.: Н И И С И РАН, 2001, с. 4—26. 13. Браунли Н., Гатмэн Э. К а к реагировать на нарушения и н ф о р м а ­ ц и о н н о й безопасности ( R F C 2350, B C P 21). — Jet Info, 2000, 5. 14. Галатенко А.В. О скрытых каналах и н е только. — Jet Info, 2002, 11. 15. Галатенко В., Макстенек М., Трифаленков И . Сетевые протоко¬ л ы нового поколения. — Jet Info, 1998, 7—8. 16. ГОСТ Р И С О / М Э К 15408—1—2002. И н ф о р м а ц и о н н а я техноло­ гия. Методы и средства обеспечения безопасности. Критерии о ц е н к и бе­ зопасности и н ф о р м а ц и о н н ы х технологий. Часть 1. Введение и общая мо¬ дель. — М.: И П К Издательство стандартов, 2002. 17. ГОСТ Р И С О / М Э К 15408—2—2002. И н ф о р м а ц и о н н а я техноло­ гия. Методы и средства обеспечения безопасности. Критерии оценки бе¬ зопасности и н ф о р м а ц и о н н ы х технологий. Часть 2. Функциональные тре¬ бования безопасности. — М.: И П К Издательство стандартов, 2002. 18. ГОСТ Р И С О / М Э К 15408—3—2002. И н ф о р м а ц и о н н а я техноло­ гия. Методы и средства обеспечения безопасности. Критерии о ц е н к и бе­ зопасности и н ф о р м а ц и о н н ы х технологий. Часть 3. Требования доверия к безопасности. — М.: И П К Издательство стандартов, 2002. 257

19. Гостехкомиссия России. Руководящий документ. К о н ц е п ц и я за¬ щ и т ы С В Т и АС от Н С Д к и н ф о р м а ц и и . — Москва, 1992. 20. Гостехкомиссия России. Руководящий документ. Защита от н е ­ санкционированного доступа к и н ф о р м а ц и и . Термины и определения. — Москва, 1992. 21. Гостехкомиссия России. Руководящий документ. Автоматизиро¬ в а н н ы е системы. Защита от несанкционированного доступа к информа¬ ц и и . К л а с с и ф и к а ц и я автоматизированных систем и требования по защи¬ те и н ф о р м а ц и и . — Москва, 1992. 22. Гостехкомиссия России. Руководящий документ. Временное п о ­ ложение п о организации разработки, изготовления и эксплуатации про¬ граммных и технических средств защиты и н ф о р м а ц и и от Н С Д в автома¬ тизированных системах и средствах вычислительной техники. — Москва, 1992. 23. Гостехкомиссия России. Руководящий документ. Средства вы¬ числительной техники. Защита от несанкционированного доступа к ин¬ ф о р м а ц и и . Показатели з а щ и щ е н н о с т и от несанкционированного досту¬ па к и н ф о р м а ц и и . — Москва, 1992. 24. Гостехкомиссия России. Руководящий документ. Средства вы¬ числительной техники. Межсетевые экраны. Защита от несанкциониро¬ ванного доступа к и н ф о р м а ц и и . Показатели з а щ и щ е н н о с т и от несанкци¬ онированного доступа к и н ф о р м а ц и и . — Москва, 1997. 25. Гостехкомиссия России. Руководящий документ. Безопасность и н ф о р м а ц и о н н ы х технологий. Критерии оценки безопасности информа¬ ц и о н н ы х технологий. — Москва, 2002. 26. Гостехкомиссия России. Руководство по разработке профилей за¬ щ и т ы и заданий по безопасности (проект). — Москва, 2002. 27. Гостехкомиссия России. Руководящий документ. Руководство по регистрации профилей защиты (проект). — Москва, 2002. 28. Дебопюи Т. (редактор). Д о п о л н е н и е к Руководству п о информа¬ ц и о н н о й безопасности предприятия: К а к выбирать поставщика Интер¬ нет—услуг. — Jet Info, 2000, 3. 29. П р о ф и л ь защиты для межсетевых экранов корпоративного уров­ ня. — И н ф о с и с т е м ы Джет, 2002. 30. П р о ф и л ь защиты для межсетевых экранов провайдерского уров­ ня. — И н ф о с и с т е м ы Джет, 2002. 31. Средства построения виртуальных локальных вычислительных сетей. Защита от несанкционированного доступа к и н ф о р м а ц и и . Базовый профиль защиты (проект, редакция 01). — М И Ф И , 2002. 32. Средства построения виртуальных частных вычислительных се¬ тей. Защита от несанкционированного доступа к и н ф о р м а ц и и . Базовый профиль защиты (проект, редакция 01). — М И Ф И , 2002. 258

33. Таранов А., Ц и ш е в с к и й В. Java в три года. — Jet Info, 1998, 11—12. 34. Управление и н ф о р м а ц и о н н о й безопасностью. П р а к т и ч е с к и е правила. — П р и л о ж е н и е к и н ф о р м а ц и о н н о м у бюллетеню Jet Info. 35. Холбрук П., Рейнольдс Дж. (редакторы). Руководство по и н ф о р ­ м а ц и о н н о й безопасности предприятия. — Jet Info, 1996, 10—11. 36. Bainer C . , Hines J . , Shah S. U . S . Department of Defense Biometric System Protection Profile For M e d i u m Robustness Environments. Version 1.01. — D o D Biometrics Management Office, June 29, 2001. 37. British Standard. Code of practice for information security manage¬ ment. — British Standards Institution, BS 7799:1995. 38. British Standard. Information security management systems — Specification with guidance for use. — British Standards Institution, BS 7799— 2:2002. 39. Brownlee N . , Guttman E . Expectations for Computer Security Incident Response. — Request for Comments: 2350, B C P : 21, June 1998. 40. Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. Version 2.1. — CCIMB—99—031, August, 1999. 41. Common Criteria for Information Technology Security Evaluation. Part 2: Security functional requirements. Version 2.1. — CCIMB—99—032, August, 1999. 42. Common Criteria for Information Technology Security Evaluation. Part 3: Security assurance requirements. Version 2.1. — CCIMB—99—033, August, 1999. 43. C o m m o n Methodology for Information Technology Security Evaluation. Part 2: Evaluation Methodology. Version 1.0. — CEM—99/045, August, 1999. 44. Controlled Access Protection Profile. Version 1.d. — U . S . Information Systems Security Organization. U . S . National Security Agency, 8 October 1999. 45. Cryptographic Module Validation Program. — http://csrc.nist.gov/cryptval/. 46. Debeaupuis T. (Editor). Site Security Handbook Addendum for ISPs. — Internet Draft, August 1999. 47. Department of Defense Trusted Computer System Evaliation Criteria. — D o D 5200.28—STD, December 26, 1985. 48. Dierks T., Allen C . The T L S Protocol. Version 1.0. — Request for Comments: 2246, January 1999. 49. Dolan K . , Wright P., Montequin R., Mayer B . , Gilmore L . , Hall C . Final U . S . Department of Defense Traffic—Filter Firewall Protection Profile For Medium Robustness Environments. Version 1.4. — U . S . National Security Agency, May 1, 2000.

259

50. F I P S P U B 140—2: Security Requirements for Cryptographic Modules. — U . S . Department of Commerce, NIST, May, 25, 2001. 51. Fraser B. (Editor). Site Security Handbook. — Request for Comments: 2196, FYI: 8, September 1997. 52. Harkins D . , Carrel D . The Internet Key Exchange ( I K E ) . — Request for Comments: 2409, November 1998. 53. Holbrook P., Reynolds J. (Editors). Site Security Handbook. — Request for Comments: 1244, F Y I : 8, July 1991. 54. Iachello G . User—Oriented Protection Profile for Unobservable Message Delivery using M I X networks, Revision 2.4. — June 6, 1999. http://www.iig.uni—freiburg.de/~giac/User_MIX_PP.pdf 55. Information technology — Open Systems Interconnection — The Directory: Overview of concepts, models and services. — I S O / I E C International Standard 9594—1:2001, I T U — T Recommendation X.500 (2001 E). 56. Information technology — Open Systems Interconnection — The Directory: Models. — I S O / I E C International Standard 9594—2:2001, I T U — T Recommendation X.501 (2001 E). 57. Information technology — Open Systems Interconnection — The Directory: Public—key and attribute certificate frameworks. — I S O / I E C International Standard 9594—8:2000, I T U — T Recommendation X.509 (2000 E ) . 58. Information technology — Open Systems Interconnection — The Directory: Abstract service definition. — I S O / I E C International Standard 9594—3:2001, I T U — T Recommendation X.501 (2001 E ) . 59. Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model. — I S O / I E C 15408— 1.1999. 60. Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional requirements. — I S O / I E C 15408— 2.1999. 61. Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance requirements. — I S O / I E C 15408— 3.1999. 62. Information technology — Security techniques — Guide for Production of Protection Profiles and Security Targets. Version. 0.9. — I S O / I E C P D T R 15446, January 4, 2000. 63. Intrusion Detection System Analyser Protection Profile. Draft 3. — U . S . N a t i o n a l Security Agency. Science Applications International Corporation. Center for Information Security Technology, September 15, 2000.

260

64. Intrusion Detection System Sensor Protection Profile. Draft 3. — U . S . National Security Agency. Science Applications International Corporation. Center for Information Security Technology, September 15, 2000. 65. Jansen W., Walsh J. Draft U . S . Government Application—Level Firewall Protection Profile for Low—Risk Environments. Version 1.b. — September, 1998. 66. Jansen W., Walsh J., Dolan K . , Wright P. Final U . S . Government Traffic—Filter Firewall Protection Profile for Low—Risk Environments. Version 1.1. — April, 1998. 67. Kent S., Atkinson R. IP Authentication Header. — Request for Comments: 2402, November 1998. 68. Kent S., Atkinson R. IP Encapsulating Security Payload (ESP). — Request for Comments: 2406, November 1998. 69. Kent S., Atkinson R. Security Architecture for the Internet Protocol. — Request for Comments: 2401, November 1998. 70. K o h l J. The Kerberos Network Authentication Service (V5). — Request for Comments: 1510, September 1993. 71. Labeled Security Protection Profile. Version 1.b. — U . S . Information Systems Security Organization. U . S . National Security Agency, 8 October 1999. 72. Lee A . , et. al. Certificate Issuing and Management Components Family of Protection Profiles. Version 1.0. — U . S . National Security Agency, October 31, 2001. 73. L i n n J. Generic Security Service Application Program Interface. Version 2, Update 1. — Request for Comments: 2743, January 2000. 74. Madson C . , Glenn R. The Use of H M A C — M D 5 — 9 6 within E S P and A H . — Request for Comments: 2403, November 1998. 75. Madson C . , Glenn R. The Use of H M A C — S H A — 1 — 9 6 within E S P and A H . — Request for Comments: 2404, November 1998. 76. Maughan D . , Schertler M . , Schneider M . , Turner J. Internet Security Association and K e y Management Protocol ( I S A K M P ) — Request for Comments: 2408, November 1998. 77. National Computer Security Center. Trusted Network Interpretation. — N C S C — T G — 0 0 5 , 1987. 78. Protection Profile for Multilevel Operation Systems i n Environments Requiring Medium Robustness. Version 1.22. — Information Systems Assurance Directorate. U . S . National Security Agency, 23 May 2001. 79. Protection Profile For Single—level Operating Systems In Environments Requiring Medium Robustness. Version 1.22. — Information Systems Assurance Directorate. U . S . National Security Agency, 23 May 2001. 80. Rannenberg K . , Iachello G . Protection Profiles for Remailer Mixes — D o the New Evaluation Criteria Help? — Proceedings of the 16th Annual

261

Computer Security Applications Conference (ACSAC'00). — I E E E Press, 2000, pp. 107—118. 81. Rational for R B A C Protection Profile. Version 1.0 — July 30, 1998. 82. Rescorla E . H T T P Over T L S . — Request for Comments: 2818, May 2000. 83. Reynolds J., Chandramouli R. Role—Based Access Control Protection Profile. Version 1.0 — July 30, 1998. 84. Security Architecture for Open Systems Interconnection for C C I T T Applications. Recommendation X.800. — C C I T T , Geneva, 1991. 85. Sheridan M . , Sohmer E . , Varnum R. A Goal V P N Protection Profile For Protecting Sensitive Information. Release 2.0. — U . S . National Security Agency, 10 July, 2000. 86. Smart Card Protection Profile ( S C S U G — S C P P ) . Version 3.0. — Smart Card Security User Group, 9 September 2001. 87. Smith H . Database Management System Protection Profile ( D B M S PP). Version 2.1. — Oracle Corporation, May, 2000. 88. Stoneburner G . C S P P — Guidance for C O T S Security Protection Profiles. Version 1.0. N I S T I R 6462. — U . S . Department of Commerce, NIST, December, 1999. 89. Stoneburner G . C S P P — O S — C O T S Security Protection Profile — Operating Systems. Draft Version 0.4. — U . S . Department of Commerce, NIST, February 5, 2001. 90. Stoneburner G . Rationale for C S P P — C O T S Security Protection Profile — Operating Systems. Draft Version 0.4. — U . S . Department of Commerce, NIST, February 5, 2001. 91. Wray J. Generic Security Service A P I Version 2: C—bindings. — Request for Comments: 2744, January 2000.

262

С а й т ы по т е м е к у р с а 92. Web—сервер Международной организации п о стандартизации: http://www.iso.ch/. 93. Web—сервер Международного телекоммуникационного союза: http://www.itu.int/. 94. Сервер Тематической группы по технологии Internet, на котором располагаются стандарты и проекты стандартов Internet—сообщества: http://www.ietf.org/. 95. Web—сервер с материалами п о " О б щ и м критериям": http://www.commoncriteria.org/. 96. Web—сервер Федерального агентства правительственной связи и и н ф о р м а ц и и п р и Президенте Российской Федерации: http://www.fagci.ru/. 97. Сервер Государственной технической комиссии п р и Президенте Российской Федерации: http://www.infotecs.ru/gtc/. 98. Информационный бюллетень "Jet Info" уделяет много внимания стандартам и спецификациям в области информационной безопасности: http://www.jetinfo.ru/. 99. Раздел на сервере Национального института стандартов С Ш А , содержащий много материалов п о и н ф о р м а ц и о н н о й безопасности, в ча¬ стности, по стандартам и с п е ц и ф и к а ц и я м в этой области: http://csrc.nist.gov/. 100. П о адресу http://csrc.nist.gov/cc/ располагаются материалы по " О б щ и м критериям". 101. Web—сервер Британского института стандартов: http://www.bsi—global.com/.

263

Серия «Основы информационных технологий» В. А. Галатенко Под редакцией академика РАН В. Б. Бетелина Стандарты информационной безопасности Курс лекций. Учебное пособие Второе издание

Редакторы Е. Петровичева Компьютерная верстка Н. Дородницына Обложка М. Автономова

1

Формат 60x90 /16. Усл. печ. л. 20,5. Бумага офсетная. Подписано в печать 20.10.2005. Тираж 2000 экз. Заказ № . Санитарно-эпидемиологическое заключение о соотвествии санитарным правилам №77.99.02.953.Д.006052.08.03 от 12.08.2003 ООО «ИНТУИТ.ру» Интернет-Университет И н ф о р м а ц и о н н ы х Технологий, www.intuit.ru 123056, Москва, Электрический пер., 8, стр.3.

Отпечатано с готовых диапозитивов на Ф Г У П ордена «Знак Почета» Смоленская областная типография и м . В.И.Смирнова. Адрес: 214000, г.Смоленск, проспект им. Ю.Гагарина, д.2.