Опорный конспект

першими 50 адресами з адресної книги Microsoft Outlook. В результаті поштові сервери піддаються атаці на доступність.

В даному випадку нам хотілося б відзначити два моменти.

1.Як вже мовилося, пасивні об’єкти відходять в минуле; так званий активний вміст стає нормою. Файли, які по всіх ознаках були б повинні були відноситися до даних (наприклад, документи у форматах MS-Word або Postscript, тексти поштових повідомлень), здатні містити компоненти, які можуть запускатися неявним чином при відкритті файлу, що інтерпретуються. Як і всяке в цілому прогресивне явище, таке "підвищення активності даних" має свою оборотну сторону (в даному випадку - відставання в розробці механізмів безпеки і помилки в їх реалізації). Звичайні користувачі ще не скоро навчаться застосовувати компоненти, що інтерпретуються, "в мирних цілях" (або хоча б дізнаються про їх існування), а перед зловмисниками відкрилося по суті необмежене поле діяльності. Як не банально це звучить, але якщо для стрільби по горобцях викочується гармата, то постраждає в основному стріляючий.

2.Інтеграція різних сервісів, наявність серед них мережних, загальна зв’язність багато разів збільшують потенціал для атак на доступність, полегшують розповсюдження шкідливого ПО (вірус "Melissa" - класичний тому приклад). Образно кажучи, багато інформаційних систем, якщо не вжити захисних заходів, опиняються "в одному човні" (точніше - в кораблі без перегородок), так що достатньо однієї пробоїни, щоб "човен" тут же пішов до дна.

Як це часто буває, вслід за "Melissa" з’явилася на світ ціла серія вірусів, "черв’яків" і їх

комбінацій: "Explorer.zip" (1999 червня), "Bubble Boy" (1999 листопаду), "ILOVEYOU" (2000 травня) і

т.д. Не те що б від них був особливо великий збиток, але суспільний резонанс вони викликали чималий. Активний вміст, крім компонентів документів і інших файлів даних, що інтерпретуються, має ще один популярний вигляд - так звані мобільні агенти. Це програми, які завантажуються на інші

комп’ютери і там виконуються. Найвідоміші приклади мобільних агентів - Java-апплеты, завантажувані на призначений для користувача комп’ютер і що інтерпретуються Internet-навігаторами. Виявилося, що розробити для них модель безпеки, що залишає достатньо можливостей для корисних дій, не так-то просто; ще складніше реалізувати таку модель без помилок. В серпні 1999 року стали відомі недоліки в реалізації технологій ActiveX і Java в рамках Microsoft Internet Explorer, які давали можливість розміщувати на Web-серверах шкідливі апплеты, що дозволяють одержувати повний контроль над системою-візитером.

Для упровадження "бомб" часто використовуються помилки типу "переповнювання буфера", коли програма, працюючи з областю пам’яті, виходить за межі допустимого і записує в потрібні зловмиснику місця певні дані. Так діяв ще в 1988 році знаменитий "черв’як Моріса"; в червні 1999 року хакери знайшли спосіб використовувати аналогічний метод по відношенню до Microsoft Internet Information Server (IIS), щоб одержати контроль над Web-сервером. Вікно небезпеки охопило відразу близько півтора мільйонів серверних систем...

Не забуті сучасними зловмисниками і випробувані троянські програми. Наприклад, "Троя" Back Orifice і Netbus дозволяє одержати контроль над призначеними для користувача системами з різними варіантами MS-Windows.

Таким чином, дія шкідливого ПО може бути направлене не тільки проти доступності, але і проти інших основних аспектів інформаційної безпеки.

4 Основні загрози цілісності

На другому місці за розмірами збитку (після ненавмисних помилок і упущень) стоять крадіжки і фальсифікації. За даними газети USA Today, ще в 1992 році в результаті подібних протиправних дій з використанням персональних комп’ютерів американським організаціям був завданий загального збитку у розмірі 882 мільйонів доларів. Можна припустити, що реальний збиток був набагато більше, оскільки багато організацій із зрозумілих причин приховують такі інциденти; не викликає сумнівів, що в наші дні збиток від такого роду дій виріс багато разів.

В більшості випадків винуватцями виявлялися штатні співробітники організацій, відмінно знайомі з режимом роботи і заходами захисту. Це ще раз підтверджує небезпеку внутрішніх загроз, хоча говорять і пишуть про них значно менше ніж про зовнішні.

Раніше ми проводили відмінність між статичною і динамічною цілісністю. З метою порушення статичної цілісності зловмисник (як правило, штатний співробітник) може:

ввести невірні дані;

91

змінити дані.

Іноді змінюються змістовні дані, іноді - службова інформація. Показовий випадок порушення

цілісності мав місце в 1996 році. Oracle (особистий секретар віце-президента), що служить, пред’явила судовий позов, звинувачувавши президента корпорації в незаконному звільненні після того, як вона відкинула його залицяння. На доказ своєї правоти жінка привела електронний лист, нібито відправлене її начальником президенту. Зміст листа для нас зараз не важливий; важливий час відправки. Річ у тому, що віце-президент пред’явив, у свою чергу, файл з реєстраційною інформацією компанії стільникового зв’язку, з якого виявлялося, що в указаний час він розмовляв по мобільному телефону, знаходячись далеко від свого робочого місця. Таким чином, в суді відбулося протистояння "файл проти файлу". Очевидно, один з них був фальсифікований або змінений, тобто була порушена його цілісність. Суд вирішив, що підроблювали електронний лист (секретарка знала пароль віце-президента, оскільки їй було доручено його міняти), і позов був знехтуваний...

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

Зприведеного випадку можна зробити висновок не тільки про загрози порушення цілісності, але

іпро небезпеку сліпого довір’я комп’ютерній інформації. Заголовки електронного листа можуть бути підроблені; лист в цілому може бути фальсифіковане особою, що знає пароль відправника (ми наводили відповідні приклади). Відзначимо, що останнє можливе навіть тоді, коли цілісність контролюється криптографічними засобами. Тут має місце взаємодія різних аспектів інформаційної безпеки: якщо порушена конфіденційність, може постраждати цілісність.

Ще один урок: загрозою цілісності є не тільки фальсифікація або зміна даних, але і відмова від досконалих дій. Якщо немає засобів забезпечити "неотказуемость", комп’ютерні дані не можуть розглядатися як доказ.

Потенційно уразливі з погляду порушення цілісності не тільки дані, але і програми. Упровадження розглянутого вище за шкідливий ПО - приклад подібного порушення.

Загрозами динамічної цілісності є порушення атомарності транзакцій, переупорядковування, крадіжка, дублювання даних або внесення додаткових повідомлень (мережних пакетів і т.п.). Відповідні дії в мережному середовищі називаються активним прослуховуванням.

5 Основні загрози конфіденційності

Конфіденційну інформацію можна розділити на наочну і службову. Службова інформація (наприклад, паролі користувачів) не відноситься до певної наочної області, в інформаційній системі вона грає технічну роль, але її розкриття особливо небезпечне, оскільки воно чревате отриманням несанкціонованого доступу до всієї інформації, у тому числі наочної.

Навіть якщо інформація зберігається в комп’ютері або призначена для комп’ютерного використовування, загрози її конфіденційності можуть носити некомп’ютерний і взагалі нетехнічний характер.

Багатьом людям доводиться виступати як користувачі не однієї, а цілого ряду систем (інформаційних сервісів). Якщо для доступу до таких систем використовуються багаторазові паролі або інша конфіденційна інформація, то напевно ці дані зберігатимуться не тільки в голові, але і в записнику або на листках паперу, які користувач часто залишає на робочому столі, а то і просто втрачає. І справа тут не в неорганізованості людей, а в початковій непридатності парольної схеми. Неможливо пам’ятати багато різних паролів; рекомендації по їх регулярній (по можливості - частої) зміні тільки усугубляють положення, примушуючи застосовувати нескладні схеми чергування або взагалі прагнути звести справу до двох-трьом паролів, що легко запам’ятовуються (і так же легко вгадуваним).

Описаний клас вразливих місць можна назвати розміщенням конфіденційних даних в середовищі, де ним не забезпечений (часто - і не може бути забезпечена) необхідний захист. Загроза ж полягає в тому, що хтось не відмовиться взнати секрети, які самі просяться в руки. Крім паролів, що зберігаються в записниках користувачів, в цей клас потрапляє передача конфіденційних даних у відкритому вигляді (в розмові, в листі, по мережі), яка робить можливим перехоплення даних. Для атаки можуть використовуватися різні технічні засоби (підслуховування або прослуховування розмов, пасивне прослуховування мережі і т.п.), але ідея одна - здійснити доступ до даних в той момент, коли вони якнайменше захищені.

92

Загрозу перехоплення даних слід брати до уваги не тільки при початковому конфігуруванні ІС, але і, що дуже важливе, при всіх змінах. Вельми небезпечною загрозою є... виставки, на які багато організацій, недовго думаючи, відправляють устаткування з виробничої мережі, зі всіма даними, що зберігаються на них. Залишаються колишніми паролі, при видаленому доступі вони продовжують передаватися у відкритому вигляді. Це погано навіть в межах захищеної мережі організації; в з’єднаній мережі виставки - це дуже суворе випробування чесності всіх учасників.

Ще один приклад зміни, про яку часто забувають, - зберігання даних на резервних носіях. Для захисту даних на основних носіях застосовуються розвинені системи управління доступом; копії ж нерідко просто лежать в шафах і дістати доступ до них може багато хто.

Перехоплення даних - дуже серйозна загроза, і якщо конфіденційність дійсно є критичною, а дані передаються по багатьох каналах, їх захист може виявитися вельми складним і дорогим. Технічні засоби перехоплення добре пропрацювали, доступні, прості в експлуатації, а встановити їх, наприклад на кабельну мережу, може хто завгодно, так що цю загрозу потрібно брати до уваги по відношенню не тільки до зовнішніх, але і до внутрішніх комунікацій.

Крадіжки устаткування є загрозою не тільки для резервних носіїв, але і для комп’ютерів, особливо портативних. Часто ноутбуки залишають без нагляду на роботі або в автомобілі, іноді просто втрачають.

Небезпечною нетехнічною загрозою конфіденційності є методи морально-психологічної дії, такі як маскарад - виконання дій під виглядом особи, що володіє повноваженнями для доступу до даних (див., наприклад, статтю Айре Вінклера "Завдання: шпигунство" в Jet Info, 1996, 19).

До неприємних загроз, від яких важко захищатися, можна віднести зловживання повноваженнями. На багатьох типах систем привілейований користувач (наприклад системний адміністратор) здатний прочитати будь-який (незашифрований) файл, дістати доступ до пошти будьякого користувача і т.д. Інший приклад - нанесення збитку при сервісному обслуговуванні. Звичайно сервісний інженер дістає необмежений доступ до устаткування і має нагоду діяти в обхід програмних захисних механізмів.

Такі основні загрози, які завдають найбільшого збитку суб’єктам інформаційних відносин.

Список літератури

74 Столлингс Вильям. Криптография и защита сетей: принципы и практика /Пер. с англ – М.: Издательский дом «Вильямс», 2001.

75Иванов М.А. Криптографические методы защиты информации в компьютерных системах и сетях.

– М.: КУДИЦ-ОБРАЗ, 2001.

76Жельников В. Криптография от папируса до компьютера. – М.: ABF, 1996.

77Бабенко Л.К. Введение в специальность «Организация и технология защиты информации». – Таганрог: Изд-во ТРТУ, 1999. –54с.

78Брюхомицкий Ю.А. Введение в информационные системы. – Таганрог: Изд-во ТРТУ, 2001. – 151 с.

79Зегжда Д.П., Ивашко А.М. Как построить защищенную информационную систему Под научной редакцией Зегжды Д.П. и Платонова В.В. – СПб: Мир и семья-95,1997. – 312 с.

80Гайкович В.Ю., Ершов Д.В. «Основы безопасности информационных технологий»

81Котухов М.М., Марков А.С. Законодательно-правовое и организационно-техническое обеспечение информационной безопасности автоматизированных систем. – 1998. – 158 с.

82Информационно-безопасные системы. Анализ проблемы: Учеб. пособие Алешин Н. В, Коэлод В. Н., Нечаев Д. А., Смирнов А. С., Сычев М. П., Пальчун Б. П., Черноруцкий И. Г., Черносвитов А. В. Под ред. В. Н. Козлова. – СПб.: Издательство С.-Петербургского, гос. техн. университета, 1996. – 69 с.

83Громов В.И., Василева Г.А. «Энциклопедия компьютерной безопасности»

93

Інформаційна безпека Стандарти і специфікації в області інформаційної безпеки

План 1 Оцінні стандарти і технічні специфікації. "оранжева книга" як оцінний стандарт

1.1Основні поняття

1.2Механізми безпеки

1.3Класи безпеки

2 Інформаційна безпека розподілених систем. Рекомендації X.800

2.1Мережні сервіси безпеки

2.2Мережні механізми безпеки

2.3Адміністрування засобів безпеки

3 Стандарт ISO/IEC 15408 "Критерії оцінки безпеки інформаційних технологій"

3.1Основні поняття

3.2Функціональні вимоги

3.3Вимоги довір’я безпеці

4 Гармонізовані критерії європейських країн

5 Інтерпретація "Оранжевої книги" для мережних конфігурацій

1 Оцінні стандарти і технічні специфікації. "оранжева книга" як оцінний стандарт 1.1 Основні поняття

Ми приступаємо до огляду стандартів і специфікацій двох різних видів:

оцінних стандартів, направлених на класифікацію інформаційних систем і засобів захисту по вимогах безпеки;

технічних специфікацій, що регламентують різні аспекти реалізації засобів захисту.

Важливо відзначити, що між цими видами нормативних документів немає глухої стіни. Оцінні

стандарти виділяють найважливіші, з погляду ІБ, аспекти ІС, граючи роль архітектурних специфікацій. Інші технічні специфікації визначають, як будувати ІС архітектури, що наказала.

Історично першим оцінним стандартом, що набув широке поширення і що зробив величезний вплив на базу стандартизації ІБ в багатьох країнах, став стандарт Міністерства оборони США "Критерії оцінки довірених комп’ютерних систем".

Дана праця, звана частіше всього за кольором обкладинки "Оранжевою книгою", була вперше опублікована в серпні 1983 року. Вже одна його назва вимагає коментаря. Йдеться не про безпечні, а про довірені системи, тобто системах, яким можна надати певний ступінь довір’я.

"оранжева книга" пояснює поняття безпечної системи, яка "управляє, за допомогою відповідних засобів, доступом до інформації, так що тільки належним чином авторизовані особи або процеси, діючі від їх імені, одержують право читати, записувати, створювати і видаляти інформацію".

Очевидно, проте, що абсолютно безпечних систем не існує, це абстракція. Є значення оцінювати лише ступінь довір’я, яке можна надати тій або іншій системі.

В "Оранжевій книзі" довірена система визначається як "система, що використовує достатні апаратні і програмні засоби, щоб забезпечити одночасну обробку інформації різного ступеня секретності групою користувачів без порушення прав доступу".

Звернемо увагу, що в даних Критеріях і безпека, і довір’я оцінюються виключно з погляду управління доступом до даних, що є одним із засобів забезпечення конфіденційності і цілісності (статичної). Питання доступності "Оранжева книга" не зачіпає.

Ступінь довір’я оцінюється по двох основних критеріях.

1.Політика безпеки - набір законів, правил і норм поведінки, що визначають, як організація обробляє, захищає і поширює інформацію. Зокрема, правила визначають, в яких випадках користувач може оперувати конкретними наборами даних. Чим вище ступінь довір’я системі, тим строго і многообразнее повинна бути політика безпеки. Залежно від сформульованої політики можна вибирати конкретні механізми забезпечення безпеки. Політика безпеки - це активний аспект захисту, що включає аналіз можливих загроз і вибір заходів протидії.

94

2.Рівень гарантовоності - міра довір’я, яка може бути надана архітектурі і реалізації ІС. Довір’я безпеці може виникати як з аналізу результатів тестування, так і з перевірки (формальної чи ні) загального задуму і реалізації системи в цілому і окремих її компонентів. Рівень гарантовонності показує, наскільки коректні механізми, що відповідають за реалізацію політики безпеки. Це

пасивний аспект захисту.

Важливим засобом забезпечення безпеки є механізм підзвітності (протоколювання). Довірена система повинна фіксувати всі події, що стосуються безпеки. Ведення протоколів повинне доповнюватися аудитом, тобто аналізом реєстраційної інформації.

Концепція довіреної обчислювальної бази є центральному при оцінці ступеню довір’я безпеки. Довірена обчислювальна база - це сукупність захисних механізмів ІС (включаючи апаратне і програмне забезпечення), що відповідають за проведення в життя політики безпеки. Якість обчислювальної бази визначається виключно її реалізацією і коректністю початкових даних, які вводить системний адміністратор.

Взагалі кажучи, компоненти зовні обчислювальної бази можуть не бути довіреними, проте це не повинне впливати на безпеку системи в цілому. В результаті, для оцінки довір’я безпеці ІС достатньо розглянути тільки її обчислювальну базу, яка, якомога сподіватися, достатньо компактна.

Основне призначення довіреної обчислювальної бази - виконувати функції монітора обігу, тобто контролювати допустимість виконання суб’єктами (активними єствами ІС, діючими від імені користувачів) певних операцій над об’єктами (пасивними єствами). Монітор перевіряє кожне звернення користувача до програм або даних на предмет узгодженості з набором дій, допустимих для користувача.

Монітор обігу повинен володіти трьома якостями:

1.Ізольованість. Необхідно попередити можливість відстежування роботи монітора.

2.Повнота. Монітор повинен викликатися при кожному обігу, не повинно бути способів обійти його.

3.Веріфіцируємость. Монітор повинен бути компактним, щоб його можна було проаналізувати і

протестувати, будучи упевненим в повноті тестування.

Реалізація монітора обігу називається ядром безпеки. Ядро безпеки - це основа, на якій будуються всі захисні механізми. Крім перерахованих вище властивостей монітора обігу, ядро повинне гарантувати власну незмінність.

Межу довіреної обчислювальної бази називають периметром безпеки. Як вже указувалося, компоненти, що лежать зовні периметра безпеки, взагалі кажучи, можуть не бути довіреними. З розвитком розподілених систем поняттю "периметр безпеки" все частіше додають інше значення, маючи у вигляді межу володінь певної організації. Те, що знаходиться усередині володінь, вважається довіреним, а то, що зовні, - ні.

1.2 Механізми безпеки

Згідно "Оранжевій книзі", політика безпеки повинна обов’язково включати наступні елементи:

довільне управління доступом;

безпека повторного використовування об’єктів;

мітки безпеки;

примусове управління доступом.

Довільне управління доступом (зване іноді дискреційним) - це метод розмежування доступу до

об’єктів, заснований на обліку особи суб’єкта або групи, в яку суб’єкт входить. Довільність управління полягає в тому, що деяка особа (звичайно власник об’єкту) може на свій розсуд надавати іншим суб’єктам або відбирати у них права доступу до об’єкту.

Безпека повторного використовування об’єктів - важливе доповнення засобів управління доступом, оберігаюче від випадкового або навмисного витягання конфіденційної інформації з "сміття". Безпека повторного використовування повинна гарантуватися для областей оперативної пам’яті (зокрема, для буферів з чинами екрану, розшифрованими паролями і т.п.), для дискових блоків і магнітних носіїв в цілому.

Як ми указували раніше, сучасний об’єктно-орієнтований підхід різко звужує область дії даного елемента безпеки, утрудняє його реалізацію. Те ж вірне і для інтелектуальних пристроїв, здатних буферизувати великі об’єми даних.

95

Для реалізації примусового управління доступом з суб’єктами і об’єктами асоціюються мітки безпеки. Мітка суб’єкта описує його благонадійність, мітка об’єкту - ступінь конфіденційності інформації, що міститься в ньому.

Згідно "Оранжевій книзі", мітки безпеки складаються з двох частин - рівня секретності і списку категорій. Рівні секретності утворюють впорядковану множину, категорії - неврегульоване. Призначення останніх - описати наочну область, до якої відносяться дані.

Примусове (або мандатне) управління доступом засновано на зіставленні міток безпеки суб’єкта і об’єкту.

Суб’єкт може читати інформацію з об’єкту, якщо рівень секретності суб’єкта не нижче, ніж у об’єкту, а всі категорії, перераховані в мітці безпеки об’єкту, присутні в мітці суб’єкта. У такому разі говорять, що мітка суб’єкта домінує над міткою об’єкту. Значення сформульованого правила зрозуміле - читати можна тільки те, що встановлене.

Суб’єкт може записувати інформацію в об’єкт, якщо мітка безпеки об’єкту домінує над міткою суб’єкта. Зокрема, "конфіденційний" суб’єкт може записувати дані в секретні файли, але не може - в несекретні (зрозуміло, повинні також виконуватися обмеження на набір категорій).

Описаний спосіб управління доступом називається примусовим, оскільки він не залежить від волі суб’єктів (навіть системних адміністраторів). Після того, як зафіксовані мітки безпеки суб’єктів і об’єктів, виявляються зафіксованими і права доступу.

Якщо розуміти політику безпеки вузько, тобто як правила розмежування доступу, то механізм підзвітності є доповненням подібної політики. Мета підзвітності - в кожний момент часу знати, хто працює в системі і що робить. Засоби підзвітності діляться на три категорії:

ідентифікація і аутентифікація;

надання довіреного шляху;

аналіз реєстраційної інформації.

Звичайний спосіб ідентифікації - введення імені користувача при вході в систему. Стандартний

засіб перевірки автентичності (аутентифікації) користувача - пароль.

Довірений шлях зв’язує користувача безпосередньо з довіреною обчислювальною базою, минувши інші, потенційно небезпечні компоненти ІС. Мета надання довіреного шляху - дати користувачу можливість переконатися в автентичності обслуговуючої його системи.

Аналіз реєстраційної інформації (аудит) має справу з діями (подіями), що так чи інакше зачіпають безпеку системи.

Якщо фіксувати всі події, об’єм реєстраційної інформації, швидше за все, ростиме дуже швидко, а її ефективний аналіз стане неможливим. "оранжева книга" передбачає наявність засобів вибіркового протоколювання, як відносно користувачів (уважно стежити тільки за підозрілими), так і відносно подій.

Переходячи до пасивних аспектів захисту, вкажемо, що в "Оранжевій книзі" розглядається два види гарантованності - операційна і технологічна. Операційна гарантованності відноситься до архітектурних і реалізаційних аспектів системи, тоді як технологічна - до методів побудови і супроводу.

Операційна гарантованність включає перевірку наступних елементів:

архітектура системи;

цілісність системи;

перевірка таємних каналів передачі інформації;

довірене адміністрування;

довірене відновлення після збоїв.

Операційна гарантованність - це спосіб переконатися в тому, що архітектура системи і її реалізація дійсно реалізують вибрану політику безпеки.

Технологічна гарантованність охоплює весь життєвий цикл ІС, тобто періоди проектування, реалізації, тестування, продажу і супроводу. Всі перераховані дії повинні виконуватися відповідно до жорстких стандартів, щоб виключити просочування інформації і нелегальні "закладки".

1.3 Класи безпеки

"критерії ..." Міністерства оборони США відкрили шлях до ранжирування інформаційних систем по ступеню довір’я безпеки.

В "Оранжевій книзі" визначається чотири рівні довір’я - D, З, B і А. Рівень D призначений для систем, визнаних незадовільними. У міру переходу від рівня З до А до систем пред’являються все більш

96

жорсткі вимоги. Рівні З і B підрозділяються на класи (C1, C2, B1, B2, B3) з поступовим зростанням ступеня довір’я.

Всього є шість класів безпеки - C1, C2, B1, B2, B3, A1. Щоб в результаті процедури сертифікації систему можна було віднести до деякого класу, її політика безпеки і рівень гарантованності повинні задовольняти заданим вимогам, з яких ми згадаємо лише найважливіші.

Клас C1:

довірена обчислювальна база повинна управляти доступом іменованих користувачів до іменованих об’єктів;

користувачі повинні ідентифікувати себе, перш ніж виконувати які-небудь інші дії, контрольовані довіреною обчислювальною базою. Для аутентифікації повинен використовуватися який-небудь захисний механізм, наприклад паролі. Аутентифікаційна інформація повинна бути захищена від несанкціонованого доступу;

довірена обчислювальна база повинна підтримувати область для власного виконання, захищену від зовнішніх дій (зокрема, від зміни команд і/або даних) і від спроб стеження за ходом роботи;

повинні бути в наявності апаратні і/або програмні засоби, що дозволяють періодично перевіряти коректність функціонування апаратних і мікропрограмних компонентів довіреної обчислювальної бази;

захисні механізми повинні бути протестовані на предмет відповідності їх поведінки системної документації. Тестування повинне підтвердити, що у неавторизованого користувача немає очевидних способів обійти або поруйнувати засоби захисту довіреної обчислювальної бази;

повинні бути описані підхід до безпеки, що використовується виробником, і вживання цього підходу при реалізації довіреної обчислювальної бази.

Клас C2 (на додаток до C1):

права доступу повинні гранулюватися з точністю до користувача. Всі об’єкти повинні піддаватися контролю доступу;

при виділенні береженого об’єкту з пулу ресурсів довіреної обчислювальної бази необхідно ліквідовувати всі сліди його використовування;

кожний користувач системи винен унікальним чином ідентифікуватися. Кожна реєстрована дія повинна асоціюватися з конкретним користувачем;

довірена обчислювальна база повинна створювати, підтримувати і захищати журнал реєстраційної інформації, що відноситься до доступу до об’єктів, контрольованих базою;

тестування повинне підтвердити відсутність очевидних недоліків в механізмах ізоляції ресурсів і захисту реєстраційної інформації.

Клас B1 (на додаток до C2):

довірена обчислювальна база повинна управляти мітками безпеки, асоційованими з кожним суб’єктом і береженим об’єктом;

довірена обчислювальна база повинна забезпечити реалізацію примусового управління доступом всіх суб’єктів до всіх бережених об’єктів;

довірена обчислювальна база повинна забезпечувати взаємну ізоляцію процесів шляхом розділення їх адресних просторів;

група фахівців, що повністю розуміють реалізацію довіреної обчислювальної бази, повинна піддати опис архітектури, початкові і об’єктні коди ретельному аналізу і тестуванню;

повинна існувати неформальна або формальна модель політики безпеки, підтримуваною

довіреною обчислювальною базою. Клас B2 (на додаток до B1):

забезпечуватися мітками повинні всі ресурси системи (наприклад, ПЗП), прямо або побічно доступні суб’єктам;

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

повинна бути передбачена можливість реєстрації подій, пов’язаних з організацією таємних каналів обміну з пам’яттю;

довірена обчислювальна база повинна бути внутрішньо структурована на добре певні, відносно незалежні модулі;

системний архітектор повинен ретельно проаналізувати можливості організації таємних каналів обміну з пам’яттю і оцінити максимальну пропускну спроможність кожного виявленого каналу;

97

повинна бути продемонстрована відносна стійкість довіреної обчислювальної бази до спроб проникнення;

модель політики безпеки повинна бути формальною. Для довіреної обчислювальної бази повинні існувати описові специфікації верхнього рівня, точно і повно визначаючі її інтерфейс;

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

тести повинні підтверджувати дієвість заходів по зменшенню пропускної спроможності таємних каналів передачі інформації.

Клас B3 (на додаток до B2):

для довільного управління доступом повинні обов’язково використовуватися списки управління доступом з вказівкою дозволених режимів;

повинна бути передбачена можливість реєстрації появи або накопичення подій, несучих загрозу політиці безпеки системи. Адміністратор безпеки повинен негайно сповіщатися про спроби порушення політики безпеки, а система, у разі продовження спроб, повинна присікати їх якнайменше хворобливим способом;

довірена обчислювальна база повинна бути спроектована і структурована так, щоб використовувати повний і концептуально простий захисний механізм з точно певною семантикою;

процедура аналізу повинна бути виконана для тимчасових таємних каналів;

повинна бути специфікована роль адміністратора безпеки. Одержати права адміністратора безпеки можна тільки після виконання явних, протокольованих дій;

повинні існувати процедури и/или механізми, що дозволяють провести відновлення після збою або іншого порушення роботи без ослаблення захисту;

повинна бути продемонстрована стійкість довіреної обчислювальної бази до спроб проникнення. Клас A1 (на додаток до B3):

тестування повинне продемонструвати, що реалізація довіреної обчислювальної бази відповідає формальним специфікаціям верхнього рівня;

крім описових, повинні бути представлені формальні специфікації верхнього рівня. Необхідно використовувати сучасні методи формальної специфікації і верифікації систем;

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

повинно бути описано відповідність між формальними специфікаціями верхнього рівня і

початковими текстами.

Така класифікація, введена в "Оранжевій книзі". Коротко її можна сформулювати так:

рівень З - довільне управління доступом;

рівень B - примусове управління доступом;

рівень А - верифицируемая безпека.

Звичайно, на адресу "Критеріїв ..." можна виказати цілий ряд серйозних зауважень (таких, наприклад, як повне ігнорування проблем, що виникають в розподілених системах). Проте, слід підкреслити, що публікація "Оранжевої книги" без жодного перебільшення стала епохальною подією в області інформаційної безпеки. З’явився загальновизнаний понятійний базис, без якого навіть обговорення проблем ІБ було б скрутним.

Відзначимо, що величезний ідейний потенціал "Оранжевої книги" поки багато в чому залишається незатребуваним. Перш за все це торкається концепції технологічної гарантованності, що охоплює весь життєвий цикл системи - від вироблення специфікацій до фази експлуатації. При сучасній технології програмування результуюча система не містить інформації, присутньої в початкових специфікаціях, втрачається інформація про семантику програм. Важливість даної обставини ми плануємо продемонструвати далі, в лекції про управління доступом.

98

електронний цифровий підпис;

механізми управління доступом. Можуть розташовуватися на будь-якій із сторін, що беруть участь в спілкуванні, або в проміжній крапці;

механізми контролю цілісності даних. В рекомендаціях X.800 розрізняються два аспекти цілісності: цілісність окремого повідомлення або поля інформації і цілісність потоку повідомлень або полів інформації. Для перевірки цілісності потоку повідомлень (тобто для захисту від крадіжки, переупорядковування, дублювання і вставки повідомлень) використовуються порядкові номери, тимчасові штампи, криптографічне скріплення або інші аналогічні прийоми;

механізми аутентифікації. Згідно рекомендаціям X.800, аутентифікація може досягатися за рахунок використовування паролів, особистих карток або інших пристроїв аналогічного призначення, криптографічних методів, пристроїв вимірювання і аналізу біометричних характеристик;

механізми доповнення трафіку;

механізми управління маршрутизацією. Маршрути можуть вибиратися статично або динамічно. Крайова система, зафіксувавши неодноразові атаки на певному маршруті, може відмовитися від його використовування. На вибір маршруту здатна вплинути мітка безпеки, асоційована з передаваними даними;

механізми нотаризации. Служать для завірення таких комунікаційних характеристик, як цілісність, час, осіб відправника і одержувачів. Завірення забезпечується надійною третьою стороною, володіючою достатньою інформацією. Звичайно нотаризация спирається на механізм електронного підпису.

Внаступній таблиці зведені сервіси (функції) і механізми безпеки. Таблиця показує, які механізми (по окремості або в комбінації з іншими) можуть використовуватися для реалізації тієї або іншої функції.

100