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

Відмінність комп'ютерного спілкування від природного. Система Opentest і поняття, пов’язані з нею. Класифікація автоматизованих систем, функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу. Тест на задані теми.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык украинский
Дата добавления 19.06.2011
Размер файла 233,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

80

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ДИПЛОМНА РОБОТА

"МОДЕРНИЗАЦІЯ ТЕСТОВИХ ПРОГРАМ ОЦІНКИ ЗНАНЬ З ДИСЦИПЛІН ТЕХНІЧНОГО ЗАХИСТУ ІНФОРМАЦІЇ"

Перелік термінів і скорочень

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

АС - автоматизована система;

ДР - використання ресурсів;

ДС - стійкість до відмов;

ДЗ - гаряча заміна;

ДВ - відновлення після збоїв;

КС - комп'ютерна система;

КЗЗ - комплекс засобів захисту;

КСЗІ - комплексна система захисту інформації.

КД - довірча конфіденційність;

КА - адміністративна конфіденційність;

КО - повторне використання об'єктів;

КК - аналіз прихованих каналів;

КВ - конфіденційність при обміні.

ЛОМ - локальна обчислювальна мережа;

НСД - несанкціонований доступ;

НР - реєстрація;

НИ - ідентифікація и автентифікація;

НК - достовірний канал;

НО - розподіл обов'язків;

НЦ - цілісність КЗЗ;

НТ - самотестування;

НВ - автентифікація при обміні;

НА - автентифікація відправника;

НП - автентифікація одержувача.

ОС - обчислювальна система;

У/В - увід/вивід;

ЦД - довірча цілісність;

ЦА - адміністративна цілісність;

ЦО - відкат;

ЦВ - цілісність при обміні.

Вступ

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

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

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

В процесі педагогічної діяльності викладач ставить перед собою наступну мету: оптимізувати процес рішення тими, хто навчається, конкретної учбової задачі шляхом ефективного управління їх учбовою діяльністю; в ході цього управління створювати умови для стимулювання їх психічного розвитку [1].

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

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

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

Система комп'ютерного тестування знань OpenTEST призначена для контролю рівня знань студентів або спеціалістів з використанням тестових завдань, питань в локальному і мережному варіантах. Вона є прикладом саме комп'ютерного спілкування і дозволяє вирішувати наступні задачі:

1) створення тестів з питань закритого типу, їх відладка і експорт/імпорт в систему;

2) проведення тестування в локальному мережному класі або через Internet;

3) експертна оцінка окремих питань або тесту в цілому [2].

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

1 Система Opentest і основні поняття, пов'язані з нею

1.1 Програмні технології

В продукті «OpenTEST» використана web-орієнтована мова PHP, а також мови HTML, XML і JavaScript. Для зберігання всієї інформації використовується база даних MySQL. Серверною програмою звичайно є Apache. Всі програмні засоби розробки є безкоштовно поширюваними і відкритими. Застосування некомпільованих, скриптових мов полегшує розробку і внесення змін в початковий код системи самими розробниками або іншими фахівцями. Орієнтація на інтернет-технології дає можливість встановити OpenTEST тільки на сервері, при цьому на комп'ютерах, призначених для користувача, не вимагається встановлювати яке-небудь спеціальне програмне забезпечення. Операційна система на серверному і клієнтських комп'ютерах не грає практично ніякої ролі. OpenTEST може бути запущений під Windows, Linux і іншими поширеними ОС [2].

1.2 Типи питань

Автоматизована система контролю знань OpenTEST оперує з питаннями закритого типу (типу «вибір одного з декількох» і «декількох з декількох»). Взаємодія тестованого з системою OpenTEST відбувається через Web-інтерфейс (діалогове вікно браузера), що накладає певні особливості на форму представлення питань і варіантів відповідей. В Web-інтерфейсі вибіркові варіанти відповідей на питання реалізуються через radio-button («вибір одного з декількох») або check-box («вибір декількох з декількох»). Візуально вони помітні, тому користувач завжди може визначити, який тип питання йому запропонований. При видачі питань відбувається випадкове перемішування порядку проходження варіантів відповідей [2].

1.3 Модульна структура системи

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

1. «Тестування» - проведення сеансів тестування, не має спеціальних прав доступу.

2. «Студія тестів» - створення і редагування тестів, тем і питань, управління правами доступу до тестів, імпорт і експорт XML.

3. «Студія користувачів» - створення і управління групами користувачів, встановлення і редагування прав доступу до тестів, груп і модулів.

4. «Статистика» - проглядання результатів тестування користувачів, видача оцінних характеристик, гістограм і журналів проведення сеансів тестування.

5. «Зона адміністратора» - контроль проходження сеансів тестування.

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

1.4 Права доступу користувачів в системі «OpenTEST»

В системі OpenTEST використовується об'єктна модель прав доступу (тут поняття «об'єкт» стосовно системи OpenTEST означає «модуль системи», «група тестованих», «тест»).

Права доступу встановлюються кожному користувачу стосовно об'єктів системи.

Існує три основні типи прав доступу:

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

2) право створення в модулі, яке передбачає створення нових об'єктів (тестів груп) в даному модулі. Правами на створені об'єкти (тести, групи) володіє що створив їх користувач;

3) право господаря модуля, яке передбачає можливість виконання будь-яких дій з об'єктами, керованих даним модулем.

Вказані типи прав доступу перераховані в порядку зростання старшинства. Це означає, що встановлення права «господаря модуля» автоматично надає більш «молодші права». Або, наприклад, зняття права «доступу до модуля» у користувача автоматично знімає у нього всю решту прав в даному модулі. Користувач не може призначити собі або іншому користувачу права доступу вище власних [2].

1.5 Учасники (суб'єкти) процесу тестування

1) Укладач (автор) тестів

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

2) Оператор введення тестів

Є фахівцем в області XML-формату і модуля «Студія тестів» системи OpenTEST. Оператору доступні наступні способи введення тесту в систему:

- через Web-інтерфейс «Студії введення тестів» безпосередньо в БД;

- через імітатор Web-інтерфейсу з конвертацією тесту в XML-формат;

- з.doc-файла з конвертацією тесту в XML-формат;

- імпортування тесту з XML-файлу.

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

3) Організатор тестування

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

Організатор тестування виконує наступні функції:

- готує (одержує в деканаті, доручає підготувати) списки груп тестованих студентів;

- перевіряє наявність в БД відповідних тестів і виконує необхідні настройки тестів;

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

- одержує (визначає параметри отримання результатів) і обнародуватиме результати тестування.

4) Оператор організації тестування

Оператором проведення тестування є фахівець по всіх режимах системи OpenTEST (член команди OpenTEST Team). Звичайно оператор проведення тестування володіє правами господаря на модулі «Студія тестів», «Студія користувачів», «Статистика» системи OpenTEST.

Оператор організації тестування:

- по вказівці організатора тестування заносить в БД списки груп тестованих;

- встановлює настройки тестів і груп;

- встановлює параметры сеансу тестування;

- проводить ідентифікацію тестованих і їх допуск до сеансу тестування;

- присутній в залі при проведенні тестування і вирішує конфліктні ситуації;

- по вказівці організатора тестування одержує відомість результатів тестування.

5) Інженер по знаннях

Є фахівцем по теорії тестування, по теорії вірогідності і матстатистике, знає структуру БД системи OpenTEST і володіє правами адміністратора системи OpenTEST.

Виконує наступні функції:

- організовує проглядання результатів журналу сеансу тестування для користувача (режим «апеляція»);

- допомагає автору тесту (організатору тестування) оцінити рівень знань студентів по темам;

- допомагає автору тесту (організатору тестування) оцінити якість окремих питань;

- допомагає автору тесту (організатору тестування) оцінити складність тесту і вибрати правильну шкалу оцінювання.

6) Адміністратор системи

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

Адміністратор системи:

- проводить інсталяцію системи OpenTEST;

- встановлює права доступу різним категоріям користувачів;

- здійснює, у разі потреби, прямий доступ до БД системи [2].

1.6 Спосіб розповсюдження

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

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

2.1 Класифікація автоматизованих систем

Мета введення класифікації автоматизованих систем (АС) і стандартних функціональних профілів захищеності - полегшення задачі співставлення вимог до комплексних засобів захисту (КЗЗ) обчислювальної системи АС з характеристиками АС [3].

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

В документі НД ТЗІ 2.5-005-99 «Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблювальної інформації від несанкціонованого доступу» за сукупністю характеристик АС (конфігурація апаратних засобів ОС і їх фізичне розміщення, кількість різноманітних категорій оброблюваної інформації, кількість користувачів і категорій користувачів) виділено три ієрархічні класи АС, вимоги до функціонального складу КЗЗ яких істотно відрізняються.

Клас «1» - одномашинний однокористувачевий комплекс, який обробляє інформацію однієї або кількох категорій конфіденційності [4].

Істотні особливості:

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

технічні засоби (носії інформації і засоби уводу / виводу (У/В)) з точки зору захищеності відносяться до однієї категорії і всі можуть використовуватись для збереження і/або У/В всієї інформації.

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

Клас «2» - локалізований багатомашинний багатокористувачевий комплекс, який обробляє інформацію різних категорій конфіденційності [4].

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

Приклад - локальна обчислювальна мережа (ЛОМ).

Клас «3» - розподілений багатомашинний багатокористувачевий комплекс, який обробляє інформацію різних категорій конфіденційності [4].

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

Приклад - глобальна мережа.

Система OpenTEST - система, що являє собою багатомашинний комплекс, з великою кількістю користувачей, які мають різні права доступу: адміністратори, викладачі, студенти тощо. Крім того вона з'єднана з глобальною мережею, в тому числі і мережею Internet. Внаслідок цього з'являється велика кількість незахищених каналів, багато вузлів з різною політикою безпеки. Тому поза сумнівом систему OpenTEST віднести до 3 класу АС і саме для цього класу розробляти профілі захищеності.

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

автоматизована система, в якій підвищені вимоги до - забезпечення конфіденційності оброблюваної інформації (підкласи «х. К»);

автоматизована система, в якій підвищені вимоги до - забезпечення цілісності оброблюваної інформації (підкласи «х.Ц»);

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

автоматизована система, в якій підвищені вимоги до - забезпечення конфіденційності і цілісності оброблюваної інформації (підкласи» х.КЦ»);

автоматизована система, в якій підвищені вимоги до - забезпечення конфіденційності і доступності оброблюваної інформації (підкласи «х.КД»);

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

автоматизована система, в якій підвищені вимоги до - забезпечення конфіденційності, цілісності і доступності оброблюваної інформації (підкласи «х.КЦД»).

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

Така класифікація корисна для полегшення вибору переліку функцій, які повинен реалізовувати КЗЗ ОС, проектованої або існуючої АС. Цей підхід дозволяє мінімізувати витрати на початкових етапах створення КСЗІ АС. Проте слід визнати, що для створення КЗЗ, який найповніше відповідає характеристикам і вимогам до конкретної АС, необхідно проведення в повному обсязі аналізу загроз і оцінки ризиків [4].

Доцільно систему OpenTEST віднести до останнього підкласу, тобто АС, в якій підвищені вимоги до - забезпечення конфіденційності, цілісності і доступності оброблюваної інформації (підкласи «х.КЦД»).

2.2 Функціональні профілі захищеності

комп'ютерний автоматизований інформація тест

2.2.1 Визначення і призначення

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

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

Для стандартних функціональних профілів захищеності не вимагається ні зв'язаної з ними політики безпеки, ні рівня гарантій, хоч їх наявність і допускається в разі необхідності. Політика безпеки комп'ютерних систем (КС), що реалізує певний стандартний профіль, має бути «успадкована» з відповідних документів, що встановлюють вимоги до порядку обробки певної інформації в АС. Так, один і той же профіль захищеності може використовуватись для опису функціональних вимог з захисту оброблюваної інформації і для ОС, і для систем управління базами даних (СУБД), в той час, як їх політика безпеки, зокрема визначення об'єктів, буде різною.

Єдина вимога, якої слід дотримуватися при утворенні нових профілів, - це додержання описаних в НД ТЗІ 2.5-004-99 «Критерії оцінки захищеності інформації в комп'ютерних системах від несанкціонованого доступу» необхідних умов для кожної із послуг, що включаються до профілю.

Функціональні профілі можуть використовуватись також для зрівняння оцінки функціональності КС за критеріями інших держав з оцінкою за національними критеріями [4].

2.2.2 Семантика профілю

Опис профілю складається з трьох частин: буквено-числового ідентифікатора, знака рівності і переліку рівнів послуг, взятого в фігурні дужки. Ідентифікатор у свою чергу включає: позначення класу АС (1, 2 або 3), буквену частину, що характеризує види загроз, від яких забезпечується захист (К, і/або Ц, і/або Д), номер профілю і необов'язкове буквене позначення версії. Всі частини ідентифікатора відділяються один від одного крапкою.

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

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

Перелік функціональних послуг безпеки та рівнів гарантій, їх структура і семантичне позначення наведені в НД ТЗІ «Критерії оцінки захищеності інформації в комп'ютерних системах від несанкціонованого доступу» [4].

2.2.3 Стандартні профілі

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

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

2.3 Стандартні функціональні профілі захищеності

Стандартні функціональні профілі захищеності в КС, що входять до складу АС класу 3, з підвищеними вимогами до забезпечення конфіденційності, цілісності і доступності оброблюваної інформації [4]:

3.КЦД.1 = {КД-2, КО-1, КВ-1,

ЦД-1, ЦО-1, ЦВ-1,

ДР-1, ДВ-1,

НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2, НВ-1}

3.КЦД.2 = {КД-2, КА-2, КО-1, КВ-2,

ЦД-1, ЦА-2, ЦО-1, ЦВ-2,

ДР-1, ДВ-1,

НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2, НВ-1}

3.КЦД.3 = {КД-2, КА-2, КО-1, КК-1, КВ-3,

ЦД-1, ЦА-3, ЦО-2, ЦВ-2,

ДР-2, ДС-1, ДЗ-1, ДВ-2,

НР-3, НИ-2, НК-1, НО-2, НЦ-3, НТ-2, НВ-2}

3.КЦД.4 = {КД-3, КА-3, КО-1, КК-1, КВ-3,

ЦД-1, ЦА-3, ЦО-2, ЦВ-2,

ДР-3, ДС-2, ДЗ-2, ДВ-2,

НР-4, НИ-2, НК-1, НО-3, НЦ-3, НТ-2, НВ-2, НА-1, НП-1}

3.КЦД.5 = {КД-4, КА-4, КО-1, КК-2, КВ-4,

ЦД-4, ЦА-4, ЦО-2, ЦВ-3,

ДР-3, ДС-3, ДЗ-3, ДВ-3,

НР-5, НИ-2, НК-2, НО-3, НЦ-3, НТ-2, НА-1, НП-1, НВ-2, НА - 1, НП-1}

Профілі захищеності, що приведені вище, складені для систем іншого характеру, тому доцільно для системи OpenTEST скласти власний профіль.

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

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

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

2.4 Критерії захищеності інформації

В процесі оцінки спроможності комп'ютерної системи забезпечувати захист оброблюваної інформації від несанкціонованого доступу розглядаються вимоги двох видів [5]:

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

вимоги до гарантій.

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

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

Конфіденційність. Загрози, що відносяться до несанкціонованого ознайомлення з інформацією, становлять загрози конфіденційності.

Цілісність. Загрози, що відносяться до несанкціонованої модифікації інформації, становлять загрози цілісності.

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

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

Крім функціональних критеріїв, що дозволяють оцінити наявність послуг безпеки в комп'ютерній системі, існують критерії гарантій, що дозволяють оцінити коректність реалізації послуг. Критерії гарантій включають вимоги до архітектури комплексу засобів захисту, середовища розробки, послідовності розробки, випробування комплексу засобів захисту, середовища функціонування і експлуатаційної документації. В цих Критеріях вводиться сім рівнів гарантій (Г-1,…, Г-7), які є ієрархічними. Ієрархія рівнів гарантій відбиває поступово наростаючу міру певності в тому, що реалізовані в комп'ютерній системі послуги дозволяють протистояти певним загрозам, що механізми, які їх реалізують, в свою чергу коректно реалізовані і можуть забезпечити очікуваний споживачем рівень захищеності інформації під час експлуатації комп'ютерної системи.

Структуру критеріїв показано на рисунку 2.2.

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

Порядок оцінки комп'ютерної системи на предмет відповідності цим критеріям визначається відповідними нормативними документами. Результатом оцінки є рейтинг, що являє собою упорядкований ряд (перелічення) буквено-числових комбінацій, що позначають рівні реалізованих послуг, в поєднанні з рівнем гарантій. Комбінації упорядковуються в порядку опису послуг в критеріях. Для того, щоб до рейтингу комп'ютерної системи міг бути включений певний рівень послуги чи гарантій, повинні бути виконані всі вимоги, перелічені в критеріях для даного рівня послуги або гарантій [5].

2.4.1 Критерії конфіденційності

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

Довірча конфіденційність

Ця послуга дозволяє користувачу керувати потоками інформації від захищених об'єктів, що належать його домену, до інших користувачів. Рівні даної послуги ранжируються на підставі повноти захисту і вибірковості керування [5].

КД-1. Мінімальна довірча конфіденційність

КД-2. Базова довірча конфіденційність

КД-3. Повна довірча конфіденційність

КД-4. Абсолютна довірча конфіденційність

Політика довірчої конфіденційності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

Політика довірчої конфіденційності, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС

КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу

процесу і захищеного об'єкта

користувача і захищеного об'єкта

користувача, процесу і захищеного об'єкта

Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу користувача, що ініціює запит, і об'єкта

КЗЗ повинен надавати користувачу можливість для кожного захищеного об'єкта, що належить його домену, визначити

конкретні процеси і/або групи процесів, які мають право одержувати інформацію від об'єкта

конкретних користувачів і/або групи користувачів, які мають право одержувати інформацію від об'єкта

конкретних користувачів (і групи користувачів), які мають, а також тих, які не мають права одержувати інформацію від об'єкта

конкретних користувачів і процеси (і групи користувачів і процесів), які мають, а також тих, які не мають права одержувати інформацію від об'єкта

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

-

конкретних користувачів і/або групи користувачів, які мають право ініціювати процес

конкретних користувачів (і групи користувачів), які мають, а також тих, що не мають права ініціювати процес

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

НЕОБХІДНІ УМОВИ: НИ-1

НЕОБХІДНІ УМОВИ: КО-1, НИ-1

Для системи OpenTEST доцільно вибрати базову довірчу конфіденційність, тобто КД-2.

Адміністративна конфіденційність

Ця послуга дозволяє адміністратору або спеціально авторизованому користувачу керувати потоками інформації від захищених об'єктів до користувачів. Рівні даної послуги ранжируються на підставі повноти захисту і вибірковості управління [5].

КА-1. Мінімальна адміністративна конфіденційність

КА-2. Базова адміністративна конфіденційність

КА-3. Повна адміністративна конфіденційність

КА-4. Абсолютна адміністративна конфіденційність

Політика адміністративної конфіденційності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

Політика адміністративної конфіденційності, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС

КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу

процесу і захищеного об'єкта

користувача і захищеного об'єкта

користувача, процесу і захищеного об'єкта

Запити на зміну прав доступу повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або від користувачів, яким надані відповідні повноваження

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

конкретні процеси і/або групи процесів, які мають право одержувати інформацію від об'єкта

конкретних користувачів і/або групи користувачів, які мають право одержувати інформацію від об'єкта

конкретних користувачів (і групи користувачів), які мають, а також тих, які не мають права одержувати інформацію від об'єкта

конкретних користувачів і процеси (і групи користувачів і процесів), які мають, а також тих, які не мають права одержувати інформацію від об'єкта

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

-

конкретних користувачів і/або групи користувачів, які мають право ініціювати процес

конкретних користувачів (і групи користувачів), які мають, а також тих, які не мають права ініціювати процес

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

НЕОБХІДНІ УМОВИ: НО-1, НИ-1

НЕОБХІДНІ УМОВИ: КО-1, НО-1, НИ-1

Для системи OpenTEST доцільно вибрати повну адміністративну конфіденційність, тобто КА-3.

Повторне використання об'єктів

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

КО-1. Повторне використання об'єктів

Політика повторного використання об'єктів, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС

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

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

НЕОБХІДНІ УМОВИ: НЕМАЄ

Для системи OpenTEST доцільно вибрати повторне використання об'єктів, тобто КО-1.

Аналіз прихованих каналів

Аналіз прихованих каналів виконується з метою виявлення і усунення потоків інформації, які існують, але не контролюються іншими послугами. Рівні даної послуги ранжируються на підставі того, чи виконується тільки виявлення, контроль або перекриття прихованих каналів [5].

КК-1. Виявлення прихованих каналів

КК-2. Контроль прихованих каналів

КК-3. Перекриття прихованих каналів

Повинен бути виконаний аналіз прихованих каналів

Всі приховані канали, які існують в апаратному і програмному забезпеченні, а також в програмах ПЗП, повинні бути документовані

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

Для прихованих каналів, які можуть використовуватися спільно, повинна бути документована сукупна пропускна здатність

Всі (затверджена підмножина) знайдені під час аналізу приховані канали повинні бути усунені

-

КЗЗ повинен забезпечувати реєстрацію використання затвердженої підмножини знайдених прихованих каналів

НЕОБХІДНІ УМОВИ: КО-1, Г-3

НЕОБХІДНІ УМОВИ: КО-1, НР-1, Г-3

НЕОБХІДНІ УМОВИ: КО-1, Г-3

Для системи OpenTEST доцільно вибрати контроль прихованих каналів, тобто КК-2.

Конфіденційність при обміні

Ця послуга дозволяє забезпечити захист об'єктів від несанкціонованого ознайомлення з інформацією, що міститься в них, під час їх експорту/імпорту через незахищене середовище. Рівні даної послуги ранжируються на підставі повноти захисту і вибірковості керування [5].

КВ-1. Мінімальна конфіденційність при обміні

КВ-2. Базова конфіденційність при обміні

КВ-3. Повна конфіденційність при обміні

КВ-4. Абсолютна конфіденційність при обміні

Політика конфіденційності при обміні, що реалізується КЗЗ, повинна визначати множину об'єктів і інтерфейсних процесів, до яких вона відноситься

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

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

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

-

Запити на призначення або зміну рівня захищеності повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або користувачів, яким надані відповідні повноваження

-

Запити на експорт захищеного об'єкта повинні оброблятися передавальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу

-

і приймальника об'єкта

-

Запити на імпорт захищеного об'єкта повинні оброблятися приймальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу

-

і джерела об'єкта

-

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

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

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

НЕОБХІДНІ УМОВИ: НЕМАЄ

НО-1

НО-1, НВ-1

НО-1, НВ-1, НР-1, Г-3

Для системи OpenTEST доцільно вибрати повну конфіденційність при обміні, тобто КВ-3.

2.4.2 Критерії цілісності

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

Довірча цілісність

Ця послуга дозволяє користувачу керувати потоками інформації від інших користувачів до захищених об'єктів, що належать його домену. Рівні даної послуги ранжируються на підставі повноти захисту і вибірковості керування [5].

ЦД-1. Мінімальна довірча цілісність

ЦД-2. Базова довірча цілісність

ЦД-3. Повна довірча цілісність

ЦД-4. Абсолютна довірча цілісність

Політика довірчої цілісності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

Політика довірчої цілісності, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС

КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу

користувача і захищеного об'єкта

процесу і захищеного об'єкта

процесу, користувача і захищеного об'єкта

Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу користувача, що ініціює запит, і об'єкта

КЗЗ повинен надавати користувачу можливість для кожного захищеного об'єкта, що належить його домену, визначити

конкретних користувачів і/або групи користувачів, які мають право модифікувати об'єкт

конкретні процеси і/або групи процесів, які мають право модифікувати об'єкт

конкретні процеси (і групи процесів), які мають, а також тих, що не мають права модифікувати об'єкт

конкретних користувачів і процеси (і групи користувачів і процесів), які мають, а також тих, що не мають права модифікувати об'єкт

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

-

конкретних користувачів і/або групи користувачів, які мають право ініціювати процес

конкретних користувачів (і групи користувачів), які мають, а також тих, які не мають права ініціювати процес

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

НЕОБХІДНІ УМОВИ: НИ-1

НЕОБХІДНІ УМОВИ: КО-1, НИ-1

Для системи OpenTEST доцільно вибрати базову довірчу цілісність, тобто ЦД-2.

Адміністративна цілісність

Ця послуга дозволяє адміністратору або спеціально авторизованому користувачу керувати потоками інформації від користувачів до захищених об'єктів. Рівні даної послуги ранжуються на підставі повноти захисту і вибірковості керування [5].

ЦА-1. Мінімальна адміністративна цілісність

ЦА-2. Базова адміністративна цілісність

ЦА-3. Повна адміністративна цілісність

ЦА-4. Абсолютна адміністративна цілісність

Політика адміністративної цілісності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

Політика адміністративної цілісності, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС

КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу

користувача і захищеного об'єкта

процесу і захищеного об'єкта

процесу, користувача і захищеного об'єкта

Запити на зміну прав доступу повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або від користувачів, яким надані відповідні повноваження

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

конкретних користувачів і/або групи користувачів, які мають право модифікувати об'єкт

конкретні процеси і/або групи процесів, які мають право модифікувати об'єкт

конкретні процеси (і групи процесів), які мають, а також тих, які не мають права модифікувати об'єкт

конкретних користувачів і процеси (і групи користувачів і процесів), які мають, а також тих, які не мають права модифікувати об'єкт

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

-

конкретних користувачів і/або групи користувачів, які мають право ініціювати процес

конкретних користувачів (і групи користувачів), які мають, а також тих, які не мають права ініціювати процес

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

НЕОБХІДНІ УМОВИ: НО-1, НИ-1

НЕОБХІДНІ УМОВИ: КО-1, НО-1, НИ-1

Для системи OpenTEST доцільно вибрати повну адміністративну цілісність, тобто ЦА-3.

Відкат

Ця послуга забезпечує можливість відмінити операцію або послідовність операцій і повернути (відкатити) захищений об'єкт до попереднього стану. Рівні даної послуги ранжируються на підставі множини операцій, для яких забезпечується відкат [5].

ЦО-1. Обмежений відкат

ЦО-2. Повний відкат

Політика відкату, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

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

Певний набір (множину) операцій, виконаних над захищеним об'єктом за певний проміжок часу

всі операції, виконані над захищеним об'єктом за певний проміжок часу

НЕОБХІДНІ УМОВИ: НИ-1

Для системи OpenTEST доцільно вибрати обмежений відкат, тобто ЦО-1.

Цілісність при обміні

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

ЦВ-1: Мінімальна цілісність при обміні

ЦВ-2: Базова цілісність при обміні

ЦВ-3: Повна цілісність при обміні

Політика цілісності при обміні, що реалізується КЗЗ, повинна визначати множину об'єктів КС і інтерфейсних процесів, до яких вона відноситься, рівень захищеності, що забезпечується використовуваними механізмами, і спроможність користувачів і/або процесів керувати рівнем захищеності

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

а також фактів його видалення або дублювання

-

Запити на експорт захищеного об'єкта повинні оброблятися передавальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу

-

і приймальника об'єкта

-

Запити на імпорт захищеного об'єкта повинні оброблятися приймальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу

-

і джерела об'єкта

-

Запити на присвоєння або зміну рівня захищеності повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або користувачів, яким надані відповідні повноваження

-

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

НЕОБХІДНІ УМОВИ: НЕМАЄ

НО-1

НО-1, НВ-1

Для системи OpenTEST доцільно вибрати базову цілісність при обміні, тобто ЦВ-2.

2.4.3 Критерії доступності

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

Використання ресурсів

Ця послуга дозволяє користувачам керувати використанням послуг і ресурсів. Рівні даної послуги ранжируються на підставі повноти захисту і вибірковості керування доступністю послуг КС [5].

ДР-1. Квоти

ДР-2. Недопущення захоплення ресурсів

ДР-3. Пріоритетність використання ресурсів

Політика використання ресурсів, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься

Політика використання ресурсів, що реалізується КЗЗ, повинна відноситися до всіх об'єктів КС

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

окремому користувачу

окремому користувачу і довільним групам користувачів

Запити на зміну встановлених обмежень повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або від користувачів, яким надані відповідні повноваження

-

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

окремого користувача

окремого користувача і довільних груп користувачів

НЕОБХІДНІ УМОВИ: НО-1

Для системи OpenTEST доцільно вибрати недопущення захоплення ресурсів, тобто ДР-2.

Стійкість до відмов

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

ДС-1. Стійкість при обмежених відмовах

ДС-2. Стійкість з погіршенням характеристик обслуговування

ДС-3. Стійкість без погіршення характеристик обслуговування

Розробник повинен провести аналіз відмов компонентів КС

Політика стійкості до відмов, що реалізується КЗЗ, повинна визначати множину компонентів КС, до яких вона відноситься, і типи їх відмов, після яких КС в змозі продовжувати функціонування

Політика стійкості до відмов, що реалізується КЗЗ, повинна відноситися до всіх компонентів КС

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

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

Відмова одного захищеного компонента не повинна призводити до недоступності всіх послуг або до зниження характеристик обслуговування

КЗЗ повинен бути спроможний повідомити адміністратора про відмову будь-якого захищеного компонента

НЕОБХІДНІ УМОВИ: НО-1

Для системи OpenTEST доцільно вибрати стійкість при обмежених відмовах, тобто ДС-1.

Гаряча заміна

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

ДЗ-1. Модернізація

ДЗ-2. Обмежена гаряча заміна

ДЗ-3. Гаряча заміна будь-якого компонента

Політика гарячої заміни, що реалізується КЗЗ, повинна визначати політику проведення модернізації КС

Політика гарячої заміни, що реалізується КЗЗ, повинна визначати множину компонентів КС, які можуть бути замінені без переривання обслуговування

Політика гарячої заміни, що реалізується КЗЗ, повинна забезпечувати можливість заміни будь-якого компонента без переривання обслуговування

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

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

НЕОБХІДНІ УМОВИ: НО-1

НЕОБХІДНІ УМОВИ: НО-1, ДС-1

Для системи OpenTEST доцільно вибрати модернізацію, тобто ДЗ-1.

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

Ця послуга забезпечує повернення КС у відомий захищений стан після відмови або переривання обслуговування. Рівні даної послуги ранжируються на підставі міри автоматизації процесу відновлення [5].

ДВ-1. Ручне відновлення

ДВ-2. Автоматизоване відновлення

ДВ-3. Вибіркове відновлення

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

Після відмови КС або переривання обслуговування КЗЗ повинен перевести КС до стану, із якого повернути її до нормального функціонування може тільки адміністратор або користувачі, яким надані відповідні повноваження

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

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

-

Якщо автоматизовані процедури не можуть бути використані, то КЗЗ повинен перевести КС до стану, з якого повернути її до нормального функціонування може тільки адміністратор або користувачі, яким надані відповідні повноваження

Повинні існувати ручні процедури, за допомогою яких можна безпечним чином

повернути КС до нормального функціонування


Подобные документы

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

    курсовая работа [2,4 M], добавлен 22.11.2014

  • Особливості захисту персональних комп'ютерів від несанкціонованого доступу (НДС). Спеціальне програмне забезпечення захисту інформації. Захист від НСД шляхом запису ключа за логічними межами файла. Процес підготування програми на мові ассемблера.

    курсовая работа [33,3 K], добавлен 08.08.2009

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

    реферат [19,3 K], добавлен 05.11.2016

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

    презентация [300,2 K], добавлен 14.08.2013

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

    курсовая работа [48,9 K], добавлен 28.09.2011

  • Основи безпеки даних в комп'ютерних системах. Розробка програми для забезпечення захисту інформації від несанкціонованого доступу: шифрування та дешифрування даних за допомогою криптографічних алгоритмів RSA та DES. Проблеми і перспективи криптографії.

    дипломная работа [823,1 K], добавлен 11.01.2011

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

    статья [197,4 K], добавлен 22.02.2018

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

    курсовая работа [36,5 K], добавлен 19.11.2014

  • Сутність поняття "контроль". Оцінювання результатів навчально-пізнавальної діяльності учнів. Особливості комп’ютерного контролю знань. Підходи до зіставлення комп’ютерних програм контролю. Створення тесту з математики за допомогою програми MyTest.

    курсовая работа [278,4 K], добавлен 24.04.2012

  • Основи безпеки даних в комп'ютерних системах. Канали проникнення та принципи побудови систем захисту. Ідентифікація і аутентифікація користувачів. Захист даних від несанкціонованого доступу. Технічні можливості зловмисника і засоби знімання інформації.

    курс лекций [555,1 K], добавлен 05.12.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.