Стандартизованi моделi та методи оцiнки ефективностi захисту	271

•перехоплення;

•фальсифiкацiя iнформацi¨;

•iмiтоатаки;

•фiзичне знищення каналу зв'язку.

Для мережного рiвня характернi наступнi загрози:

•аналiз службово¨ iнформацi¨, тобто адресно¨ iнформацi¨ та топологi¨ мережi;

•атаки на систему маршрутизацi¨. Можлива модифiкацiя мар-

шрутизацiйних таблиць через протоколи динамiчно¨ маршрутизацi¨ та мiжмережний протокол керуючих повiдомлень (ICMP);

•фальсифiкацiя IP-адрес;

•атаки на систему керування;

•прослуховування;

•перехоплення та фальсифiкацiя iнформацi¨;

•iмiтоатаки.

На транспортному рiвнi ймовiрнi загрози:

•несанкцiонованi з'¹днання;

•розвiдка додаткiв;

•атаки на систему керування;

•прослуховування;

•перехоплення та фальсифiкацi¨ iнформацi¨;

•iмiтоатаки.

На прикладному рiвнi ймовiрнi загрози:

•несанкцiонований доступ до даних;

•розвiдка iмен i паролiв користувачiв;

•маскування пiд санкцiонованого користувача;

•атаки на систему керування;

•атаки через стандартнi прикладнi протоколи;

•фальсифiкацiя iнформацi¨;

•iмiтоатаки.

5.1.3 Процедури захисту

Архiтектура захисту iнформацi¨ в мережах телекомунiкацi¨ концепцiя захисту iнформацi¨ в мережах телекомунiкацi¨,

272	Ðîçäië 5

що використову¹ мiжнароднi стандарти, яка розроблена i розвива¹ться Мiжнародною органiзацi¹ю зi стандартизацi¨ (ISO) ( див. рекомендацi¨ МСЕ ) у вiдповiдностi до iдеологi¨ моделi вза¹модi¨ вiдкритих систем.

Рекомендацi¨ МСЕ для захисту iнформацi¨ у телекомунiкацiях [ITU-T Recommendations] це процедури, рекомендованi Мiжнародною органiзацi¹ю зi стандартизацi¨ (ISO) для створення сервiсних служб захисту iнформацi¨ у мережах телекомунiкацi¨.

Процедура шифрування даних у телекомунiкацiйних системах призначена для закриття всiх даних абонента або декiлькох полiв повiдомлення. Може мати два рiвнi: шифрування в каналi зв'язку (лiнiйне) i мiжкiнцеве (абонентське) шифрування.

Процедура цифрового пiдпису в телекомунiкацiйних системах служить для пiдтвердження правильностi змiсту повiдомлення. Вона засвiдчу¹ факт його вiдправлення власне тим абонентом, який вказаний у заголовковi як джерело даних. Цифровий пiдпис ¹ функцi¹ю вiд змiсту та¹мно¨ iнформацi¨, вiдомо¨ тiльки абонентуджерелу, i загально¨ iнформацi¨, вiдомо¨ всiм абонентам системи.

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

Процедура забезпечення цiлiсностi даних у телекомунiкацiйних системах передбача¹ введення в кожне повiдомлення деяко¨ додатково¨ iнформацi¨, яка ¹ функцi¹ю вiд змiсту повiдомлення. В рекомендацiях МСЕ розглядаються методи забезпечення цiлiсностi двох типiв: першi забезпечують цiлiснiсть поодинокого блока даних, iншi цiлiснiсть потоку блокiв даних або окремих полiв цих блокiв. При цьому забезпечення цiлiсностi потоку блокiв даних не ма¹ сенсу без забезпечення цiлiсностi окремих блокiв. Цi методи застосовуються у двох режимах при передаваннi даних по вiртуальному з'¹днанню i при використаннi дейтаграмного передавання. В першому випадку виявляються невпорядкованiсть,

Стандартизованi моделi та методи оцiнки ефективностi захисту	273

утрати, повтори, вставки даних за допомогою спецiально¨ нумерацi¨ блокiв або введенням мiток часу. У дейтаграмному режимi мiтки часу можуть забезпечити тiльки обмежений захист цiлiсностi послiдовностi блокiв даних i запобiгти переадресацi¨ окремих блокiв.

Процедура автентифiкацi¨ у телекомунiкацiйних системах призначена для захисту при передаваннi в мережi паролiв, автентифiкаторiв логiчних об'¹ктiв i т. iн. Для цього використовуються криптографiчнi методи i протоколи, заснованi, наприклад, на процедурi трикратного рукостискання . Метою таких протоколiв ¹ захист вiд установлення з'¹днання з логiчним об'¹ктом, утвореним порушником або дiючим пiд його керуванням iз метою iмiтацi¨ роботи справжнього об'¹кта.

Процедура заповнення потоку в телекомунiкацiйних системах призначена для запобiгання аналiзу трафiка. Ефективнiсть застосування цi¹¨ процедури пiдвищу¹ться, якщо одночасно з нею передбачене лiнiйне шифрування всього потоку даних, тобто потоки iнформацi¨ й заповнення стають нерозбiрливими.

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

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

Спiльне використання процедур захисту дозволя¹ органiзувати п'ять базових сервiсiв: автентифiкацiя [authentication], контроль доступу [access control], засекречування (êîíôiäåíöiéíiñòü) [con dentiality], öiëiñíiñòü [integrity], iнформування (при- четнiсть) [nonrepudiation]. Для всiх цих сервiсiв визначенi також варiанти, як наприклад, для комунiкацiй з установленням з'¹днань

274	Ðîçäië 5

i без установлення з'¹днань або забезпечення безпеки на рiвнях комунiкацi¨, пакетiв або окремих полiв. Цей набiр сервiсiв не ¹ ¹дино можливим, проте вiн ¹ загальноприйнятим (див. рис. 5.1) .

5.1.4 Сервiснi служби захисту

Сервiснi служби захисту iнформацi¨ в мережах телекомунiкацi¨ це сукупнiсть заходiв захисту iнформацi¨ у мережах телекомунiкацiй, якi у вiдповiдностi до рекомендацiй МСЕ реалiзуються за допомогою процедур захисту.

Автентифiкацiя

Сервiсна служба автентифiкацi¨ однорiвневих об'¹ктiв

реалiзу¹ сво¨ функцi¨ за допомогою процедур автентифiкацi¨ (на мережному, транспортному та прикладному рiвнях моделi вза¹модi¨ вiдкритих систем) та (або) шифрування даних i цифрового пiдпису (на мережному та транспортному рiвнях МВВС).

Сервiсна служба автентифiкацi¨ джерела даних реалiзу¹ сво¨ функцi¨ за допомогою процедур шифрування даних (на мережному й транспортному рiвнях МВВС) та цифрового пiдпису (на мережному, транспортному та прикладному рiвнях МВВС).

Контроль доступу

Сервiсна служба контролю доступу реалiзу¹ сво¨ функцi¨ за допомогою процедури керування доступом до ресурсiв телекомунiкацiйно¨ системи на мережному, транспортному i прикладному рiвнях МВВС.

Êîíôiäåíöiéíiñòü

Сервiсна служба засекречування з'¹днання реалiзу¹ сво¨ функцi¨ за допомогою процедур шифрування даних (на фiзичному, канальному, мережному, транспортному, представницькому та прикладному рiвнях МВВС) та керування маршрутом (на мережному рiвнi МВВС).

Стандартизованi моделi та методи оцiнки ефективностi захисту	275

Òàáë. 5.1 Засоби захисту, рекомендованi МОС для моделi ВВС

276	Ðîçäië 5

Сервiсна служба засекречування в режимi без з'¹днання реалiзу¹ сво¨ функцi¨ за допомогою процедур шифрування даних (на канальному, мережному, транспортному, представницькому i прикладному рiвнях МВВС) та керування маршрутом (на мережному рiвнi МВВС).

Сервiсна служба засекречування вибiркових полiв реалiзу¹ сво¨ функцi¨ за допомогою процедури шифрування даних на представницькому та прикладному рiвнях моделi вза¹модi¨ вiдкритих систем.

Сервiсна служба засекречування потоку даних реалiзу¹ сво¨ функцi¨ за допомогою процедур шифрування даних (на фiзи- чному i представницькому рiвнях МВВС), заповнення потоку (на мережному i прикладному рiвнi МВВС) та керування маршрутом (на мережному рiвнi МВВС).

Öiëiñíiñòü

Сервiсна служба забезпечення цiлiсностi з'¹днання реалiзу¹ сво¨ функцi¨ за допомогою процедур забезпечення цiлiсностi даних та шифрування даних на транспортному i прикладному рiвнях МВВС.

Сервiсна служба забезпечення цiлiсностi з'¹днання без вiдновлення реалiзу¹ сво¨ функцi¨ за допомогою процедур забезпечення цiлiсностi даних та шифрування даних на мережному, транспортному i прикладному рiвнях МВВС.

Сервiсна служба забезпечення цiлiсностi вибiркових полiв даних реалiзу¹ сво¨ функцi¨ за допомогою процедур забезпечення цiлiсностi даних та шифрування даних на прикладному рiвнi моделi вза¹модi¨ вiдкритих систем.

Сервiсна служба забезпечення цiлiсностi даних без установлення з'¹днання реалiзу¹ сво¨ функцi¨ за допомогою процедур забезпечення цiлiсностi даних, шифрування даних (на мережному, транспортному i прикладному рiвнях МВВС) та цифрового пiдпису (на транспортному рiвнi МВВС).

Сервiсна служба забезпечення цiлiсностi вибiркових полiв без з'¹днання реалiзу¹ сво¨ функцi¨ за допомогою процедур забезпечення цiлiсностi даних, шифрування даних (на при-

Стандартизованi моделi та методи оцiнки ефективностi захисту	277

кладному рiвнi моделi вза¹модi¨ вiдкритих систем) та цифрового пiдпису (на мережному, транспортному та прикладному рiвнях МВВС).

Iнформування

Сервiсна служба iнформування про вiдправлення реалiзу¹ сво¨ функцi¨ за допомогою процедур пiдтвердження характеристик даних, забезпечення цiлiсностi даних та цифрового пiдпису на прикладному рiвнi МВВС.

Сервiсна служба iнформування про доставку реалiзу¹ сво¨ функцi¨ за допомогою процедур пiдтвердження характеристик даних, забезпечення цiлiсностi даних та цифрового пiдпису на прикладному рiвнi моделi вза¹модi¨ вiдкритих систем.

Кожна iз сервiсних служб може самостiйно вирiшувати вiдповiдне завдання iз забезпечення iнформацiйно¨ безпеки за допомогою тих чи iнших механiзмiв захисту. При цьому один i той же механiзм захисту може бути використаний в iнтересах рiзних служб iнформацiйно¨ безпеки.

5.1.5 Реалiзацiя захисту

На фiзичному та канальному рiвнях основний механiзм захистушифрування з'¹днання або трафiка (зашифровуватися може як весь трафiк, так i його частина), що забезпечу¹ конфiденцiйнiсть iнформацi¨, яка переда¹ться. Для захисту iнформацi¨ на фiзичному рiвнi застосовують скремблювання, шифрувальнi модеми, спецiалiзованi адаптери.

Досто¨нство реалiзацi¨ засобiв захисту:

•апаратна реалiзацiя;

•простота застосування;

•повний захист трафiка;

•прозорiсть виконання засобами захисту сво¨х функцiй. Недолiки застосування засобiв захисту:

•негнучкiсть рiшень (фiксований тип каналу, складнiсть адаптацi¨ до мережно¨ топологi¨, фiксована продуктивнiсть);

•низька сумiснiсть;

278	Ðîçäië 5

•висока вартiсть.

Завдання захисту iнформацi¨ на мережному рiвнi:

•захист iнформацi¨ безпосередньо в пакетах, що передаються по мережi;

•захист трафiка мережi, тобто шифрування всi¹¨ iнформацi¨ у каналi;

•контроль доступу до ресурсiв мережi, тобто захист вiд несан-

кцiонованих користувачiв i вiд доступу санкцiонованих користувачiв до iнформацi¨, що ¨м не призначена.

Для вирiшення завдань захисту на мережному можуть використовуватись:

•пакетнi фiльтри;

•адмiнiстративний захист на маршрутизаторах (у тому числi таких, що шифрують);

•протоколи захисту iнформацi¨ мережного рiвня (захист i автентифiкацiя трафiка);

•тунелювання;

•векторизацiя;

•динамiчний розподiл мережних адрес;

•захист топологi¨. Досто¨нство засобiв захисту:

•повнота контролю трафiка;

•унiверсальнiсть;

•прозорiсть;

•ñóìiñíiñòü;

•адаптацiя до топологi¨ мережi.

Недолiк неповнота контрольованих подiй (непiдконтрольнiсть транспортних та прикладних протоколiв).

Для усунення загроз на транспортному рiвнi можуть використовуватись наступнi рiшення:

•захист у складi мiжмережних екранiв (контроль доступу до додаткiв, керування доступом до серверiв);

•proxy-системи;

•протоколи захисту транспортного рiвня (захист i автентифiка-

цiя даних). Досто¨нства захисту:

•розвинена функцiональнiсть;

засобiв безпеки

Стандартизованi моделi та методи оцiнки ефективностi захисту	279

•висока гнучкiсть захисту. Недолiки засобiв захисту:

•неповнота захисту;

•непiдконтрольнiсть подiй у рамках прикладних i мережних

протоколiв.

Засоби захисту на представницькому рiвнi:

•вбудований захист додаткiв;

•мiжмережнi екрани з фiльтрацi¹ю прикладних протоколiв;

•proxy-системи i ò.ií.

Досто¨нства захисту: повнота i висока функцiональнiсть у рамках конкретного додатку та контроль на рiвнi дiй конкретного користувача (процесу).

Недолiки розташування засобiв захисту на прикладному рiвнi:

•вiдсутнiсть унiверсальностi;

•обмеженiсть рамками заданого набору додаткiв;

•непiдконтрольнiсть подiй на нижчих рiвнях керування.

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

Адмiнiстрування засобiв безпеки включа¹ в себе розповсюдження iнформацi¨, необхiдно¨ для роботи сервiсiв i механiзмiв безпеки, а також збирання i аналiз iнформацi¨ про ¨х функцiонування. Прикладами можуть служити розповсюдження криптографiчних ключiв, установка значень параметрiв захисту, ведення iнформацiйного журналу i т.iн.

Концептуальною основою адмiнiстрування ¹ iнформацiйна база управлiння безпекою. Ця база може не iснувати як ¹дине (розподiлене сховище, але кожна з кiнцевих систем повинна мати iнформацiю, необхiдну для реалiзацi¨ вибрано¨ полiтики безпеки.

Вiдповiдно до рекомендацiй Х.800, зусилля адмiнiстратора повиннi розподiлятися за трьома напрямками:

•адмiнiстрування iнформацiйно¨ системи у цiлому;

•адмiнiстрування сервiсiв безпеки;

•адмiнiстрування механiзмiв безпеки.

Серед дiй, що вiдносяться до системи у цiлому, вiдзначають забезпечення актуальностi полiтики безпеки, вза¹модiя з iншими

280	Ðîçäië 5

адмiнiстративними службами, реагування на подi¨, що вiдбуваються, аудит та безпечне вiдновлення.

Адмiнiстрування сервiсiв безпеки включа¹ в себе визначення об'¹ктiв, що пiдлягають захисту, вироблення правил пiдбору механiзмiв безпеки (при наявностi альтернатив), комбiнування механiзмiв для реалiзацi¨ сервiсiв, вза¹модiя з iншими адмiнiстраторами для забезпечення узгодження роботи.

Обов'язки адмiнiстратора безпеки визначаються перелiком задiяних механiзмiв. Типовий список наступний:

•управлiння ключами (генерацiя та розподiл);

•управлiння шифруванням (установка i синхронiзацiя кри-

птографiчних параметрiв). До управлiння шифруванням можна вiднести i адмiнiстрування механiзмiв цифрового пiдпису. Управлiння цiлiснiстю, якщо воно забезпечу¹ться криптографiчними засобами, також вiдноситься до даного напряму;

• адмiнiстрування управлiння доступом ( розподiл iнфор-

мацi¨, необхiдно¨ для управлiння паролiв, спискiв доступу i т.iн.);

• управлiння автентифiкацi¹ю (розподiл iнформацi¨, необхi-

дно¨ для автентифiкацi¨ паролiв, ключiв i т.iн.);

• управлiння доповненням трафiка (вироблення та пiдтрим-

ка правил, що задають характеристики додаткових повiдомлень частоту вiдправки, розмiр i т.iн.);

•управлiння маршрутизацi¹ю (видiлення довiрених шляхiв);

•управлiння нотаризацi¹ю (розповсюдження iнформацi¨ про

нотарiальнi служби, адмiнiстрування цих служб.

5.2Модель, що покладена в основу НД ТЗI 2.5

5.2.1Загальнi положення моделi

5.2.1.1. Ñóá'¹êòè òà îá'¹êòè

Комп'ютерна система представля¹ться множиною компонентiв (див. Роздiл 2). Частина компонентiв призначаються для реалiзацi¨ полiтики безпеки (наприклад, засоби iзоляцi¨ процесiв або керування потоками iнформацi¨). Iншi впливають на безпеку опосе-

Стандартизованi моделi та методи оцiнки ефективностi захисту	281

редковано, наприклад, забезпечують функцiонування компонентiв першого типу. Третi не задiянi пiд час вирiшення завдань забезпечення безпеки. Множина всiх компонентiв перших двох типiв назива¹ться комплексом засобiв захисту.

У НД ТЗI 2.5 усi ресурси комп'ютерно¨ системи, що знаходяться пiд управлiнням комплексу засобiв захисту називаються об'¹- ктами. Як об'¹кти вони характеризуються двома аспектами: логi- чне подання (змiст, семантика, значення) i фiзичне (форма, синтаксис). Об'¹кт характеризу¹ться сво¨м станом, що в свою чергу характеризу¹ться атрибутами i поводженням, яке визнача¹ способи змiни стану. Для рiзних комп'ютерних систем об'¹кти можуть бути рiзнi. Наприклад, для системи управлiння базами даних в якостi об'¹ктiв можна розглядати записи баз даних, а для операцiйно¨ системи процеси, файли, кластери, сектори дискiв, сегменти па- м'ятi i т.iн. Все, що пiдляга¹ захисту вiдповiдно до полiтики безпеки, ма¹ бути визначено як об'¹кт.

При розглядi вза¹модi¨ двох об'¹ктiв комп'ютерно¨ системи, що виступають як приймальники або джерела iнформацi¨, видiляють пасивний об'¹кт, над яким викону¹ться операцiя, i активний об'¹кт, який викону¹ або iнiцiю¹ цю операцiю. Розглядаються такi типи об'¹ктiв КС: об'¹кти-користувачi, об'¹кти-процеси i пасивнi об'¹- кти. Прийнятий у деяких зарубiжних документах термiн суб'¹кт ¹ суперпозицi¹ю об'¹кта-користувача i об'¹кта-процесу (рис. 5.4).

Об'¹кти-користувачi i об'¹кти-процеси ¹ такими тiльки всерединi конкретного домену iзольовано¨ логiчно¨ областi, всерединi яко¨ об'¹кти володiють певними властивостями, повноваженнями i зберiгають певнi вiдносини. В iнших доменах об'¹кти залишаються в пасивному станi. Це дозволя¹ одному об'¹кту-процесу керувати iншим об'¹ктом-процесом àáî íàâiòü об'¹ктом-користувачем, оскiльки останнiй залиша¹ться пасивним з точки зору керуючо- го об'¹кта. Iншими словами, об'¹кти можуть знаходитись в одному з трьох рiзних станiв: об'¹кт-користувач, об'¹кт-процес i пасивний об'¹кт. Перехiд мiж станами означа¹, що об'¹кт просто розгляда¹ться в iншому контекстi.

Пасивний об'¹кт переходить в стан об'¹кта-користувача, коли особа (фiзична особа-користувач) входить в систему. Цей об'¹кткористувач виступа¹ для комплексу засобiв захисту як образ фi-

282	Ðîçäië 5

Ðèñ. 5.4. Вiдповiднiсть понять Критерi¨в НД ТЗI 2.5 та Жовтогарячо¨ книги

зичного користувача. Звичайно, за цим процесом iде активiзацiя об'¹кта-процесу за iнiцiативою користувача. Цей об'¹кт-процес ¹ керуючим для пасивних об'¹ктiв всерединi домену користувача. Об'¹кти-користувачi, об'¹кти-процеси i пасивнi об'¹кти далi позна- чаються просто як користувачi, процеси i об'¹кти, вiдповiдно.

Вза¹модiя двох об'¹ктiв комп'ютерно¨ системи (звернення активного об'¹кта до пасивного з метою одержання певного виду доступу) приводить до появи потоку iнформацi¨ мiж об'¹ктами i/або змiни стану системи. Як потiк iнформацi¨ розгляда¹ться будь-яка порцiя iнформацi¨, що переда¹ться мiж об'¹ктами ком- п'ютерно¨ системи.

5.2.1.2. Основнi принципи керування доступом

Принцип безперервностi захисту

Захист iнформацi¨ повинен забезпечу¹ться протягом всього перiоду ¨¨ iснування. З моменту створення об'¹кта комп'ютерно¨ системи або його iмпорту до системи i аж до його знищення або експорту з системи всi запити на доступ до об'¹кта i об'¹кта на доступ до iнших об'¹ктiв мають контролюватися комплексом засобiв

Стандартизованi моделi та методи оцiнки ефективностi захисту	283

захисту.

Перший аспект, що виплива¹ з цього принципу, це необхiднiсть того, щоб абсолютно всi запити на доступ до об'¹ктiв контролювалася комплексом засобiв захисту i не iснувало можливостi обминути цей контроль (одержати доступ в обхiд комплексу засобiв захисту). Для захисту об'¹ктiв комплекс засобiв захисту повинен в першу чергу забезпечувати свою цiлiснiсть i керованiсть.

Другим аспектом ¹ те, що особливе значення набува¹ визначе- ння дiючих за умовчанням правил, якi визначають початковi умови, за яких почина¹ться iснування об'¹кта всерединi комп'ютерно¨ системи.

Принцип використання атрибутiв доступу

Для реалiзацi¨ полiтики безпеки комплекс засобiв захисту повинен забезпечити iзоляцiю об'¹ктiв всерединi сфери управлiння i гарантувати розмежування запитiв доступу i керування потоками iнформацi¨ мiж об'¹ктами. Для цього з об'¹ктами комп'ютерно¨ системи ма¹ бути пов'язана iнформацiя, що дозволяла б комплексу засобiв захисту iдентифiкувати об'¹кти i перевiряти легальнiсть запитiв доступу. Як така iнформацiя ¹ атрибути доступу.

Кожний об'¹кт комп'ютерно¨ системи повинен мати певний набiр атрибутiв доступу, який включа¹ унiкальний iдентифiкатор та iншу iнформацiю, що визнача¹ його права доступу i/або права доступу до нього. Атрибут доступу термiн, що використову¹ться для опису будь-яко¨ iнформацi¨, яка використову¹ться при керуваннi доступом i зв'язана з користувачами, процесами або пасивними об'¹ктами. Вiдповiднiсть атрибутiв доступу i об'¹кта може бути як явною, так i неявною. Атрибути доступу об'¹кта ¹ частиною його подання в комп'ютернiй системi.

Коли користувачi або процеси намагаються одержати доступ до пасивних об'¹ктiв, механiзми, що реалiзують керування доступом, на пiдставi полiтики безпеки i перевiрки атрибутiв доступу можуть прийняти рiшення про легальнiсть запиту. Використовуючи набiр атрибутiв доступу вiдповiдно до прийнято¨ полiтики безпеки, можна реалiзувати довiрче керування доступом, адмiнi-

284	Ðîçäië 5

стративне, контроль за цiлiснiстю та iншi види керування доступом.

Для вiдображення функцiональностi комп'ютерно¨ системи у простiр, в якому не розглядаються права власностi, використову¹ться концепцiя матрицi доступу. Матриця доступу явля¹ собою таблицю, уздовж кожного вимiру яко¨ вiдкладенi iдентифiкатори об'¹ктiв комп'ютерно¨ системи, а в якостi елементiв матрицi виступають дозволенi або забороненi режими доступу. Матриця доступу може бути двомiрною (наприклад, користувачi/пасивнi об'¹кти або процеси/пасивнi об'¹кти) або тримiрною (користува- чi/процеси/пасивнi об'¹кти). Матриця доступу може бути повною, тобто мiстити вздовж кожно¨ з осей iдентифiкатори всiх iснуючих на даний час об'¹ктiв комп'ютерно¨ системи даного типу, або частковою. Повна тримiрна матриця доступу дозволя¹ точно описати, хто (iдентифiкатор користувача), через що (iдентифiкатор процесу), до чого (iдентифiкатор пасивного об'¹кта), який вид доступу може одержати.

Принципи довiрчого i адмiнiстративного керування доступом

Принципи довiрчого та адмiнiстративного управлiння детально розглянутi у 3.1.6 Пiдходи до керування доступом, визначенi НД ТЗI.

У даному випадку творення додаткових потокiв iнформацi¨ може бути зумовлене: модифiкацi¹ю атрибутiв доступу користувача, процесу або пасивного об'¹кта; створенням нових об'¹ктiв (вклю- чаючи копiювання iснуючих); експортом або iмпортом об'¹ктiв.

Вiдповiдно до НД ТЗI 2.5 у процесi оцiнки спроможностi ком- п'ютерно¨ системи забезпечувати захист оброблювано¨ iнформацi¨ вiд несанкцiонованого доступу розглядаються вимоги двох видiв:

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

•вимоги до гарантiй безпеки.

Стандартизованi моделi та методи оцiнки ефективностi захисту	285

5.2.2Функцiональнi критерi¨ НД ТЗI 2.5

5.2.2.1.Загальнi вiдомостi про функцiональнi критерi¨ НД

ÒÇI 2.5

В критерiях НД ТЗI 2.5 комп'ютерна система розгляда¹ться як набiр функцiональних послуг. Кожна послуга явля¹ собою набiр функцiй, що дозволяють протистояти певнiй множинi загроз. Кожна послуга може включати декiлька рiвнiв. Чим вище рiвень послуги, тим бiльш повно забезпечу¹ться захист вiд певного виду загроз. Рiвнi послуг мають i¹рархiю за повнотою захисту, проте не обов'язково являють собою точну пiдмножину один одного. Рiвнi починаються з першого (1) i зростають до значення n, де n унiкальне для кожного виду послуг.

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

Êîíôiäåíöiéíiñòü. Загрози, що вiдносяться до несанкцiонованого ознайомлення з iнформацi¹ю, становлять загрози конфiденцiйностi. Якщо iснують вимоги щодо обмеження можливостi ознайомлення з iнформацi¹ю, то вiдповiднi послуги треба шукати

â ðîçäiëi Критерi¨ конфiденцiйностi .

Öiëiñíiñòü. Загрози, що вiдносяться до несанкцiоновано¨ модифiкацi¨ iнформацi¨, становлять загрози цiлiсностi. Якщо iснують вимоги щодо обмеження можливостi модифiкацi¨ iнформацi¨, то вiдповiднi послуги треба шукати в роздiлi Критерi¨ цiлiсностi .

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

Спостереженiсть. Iдентифiкацiя i контроль за дiями користувачiв, керованiсть комп'ютерною системою становлять предмет послуг спостереженостi i керованостi. Якщо iснують вимоги щодо контролю за дiями користувачiв або легальнiстю доступу i за спроможнiстю комплексу засобiв захисту виконувати сво¨ функцi¨, то

286	Ðîçäië 5

вiдповiднi послуги треба шукати у роздiлi Критерi¨ спостере-

женостi .

Ó òàáë. 5.2 наведенi iдентифiкатори рiвнiв функцiональних критерi¨в.

Òàáë. 5.2 Iдентифiкатори рiвнiв функцiональних критерi¨в

Iдентифiкатор	Найменування	Ðiâíi
	Критерi¨ конфiденцiйностi
ÊÄ	Äîâið÷à êîíôiäåíöiéíiñòü	ÊÄ-1 ÊÄ-4
ÊÀ	Адмiнiстративна конфiденцiйнiсть	ÊÀ-1 ÊÀ-4
ÊÎ	Повторне використання об'¹ктiв	ÊÎ-1
ÊÊ	Аналiз прихованих каналiв	ÊÊ-1 ÊÊ-3
ÊÂ	Êîíôiäåíöiéíiñòü ïðè îáìiíi	ÊÂ-1 ÊÂ-4
	Критерi¨ цiлiсностi
ÖÄ	Äîâið÷à öiëiñíiñòü	ÖÄ-1 ÖÄ-4
ÖÀ	Адмiнiстративна цiлiснiсть	ÖÀ-1 ÖÀ-4
ÖÎ	Âiäêiò	ÖÎ-1 ÖÎ-2
ÖÂ	Öiëiñíiñòü ïðè îáìiíi	ÖÂ-1 ÖÂ-3
	Критерi¨ доступностi
ÄÐ	Використання ресурсiв	ÄÐ-1 ÄÐ-3
ÄÑ	Ñòiéêiñòü äî âiäìîâ	ÄÑ-1 ÄÑ-3
ÄÇ	Гаряча замiна	ÄÇ-1 ÄÇ-3
ÄÂ	Вiдновлення пiсля збо¨в	ÄÂ-1 ÄÂ-3
	Критерi¨ спостережностi
ÍÐ	Ре¹страцiя	ÍÐ-1 ÍÐ-5
ÍÈ	Iдентифiкацiя i автентифiкацiя	ÍÈ-1 ÍÈ-3
ÍÎ	Розподiл обов'язкiв	ÍÎ-1 ÍÎ-3
ÍÂ	Автентифiкацiя при обмiнi	ÍÂ-1 ÍÂ-3
ÍÏ	Автентифiкацiя отримувача	ÍÏ-1 ÍÏ-2
ÍÊ	Достовiрний канал	ÍÊ-1 ÍÊ-2
ÍÖ	Цiлiснiсть комплексу засобiв захисту	ÍÖ-1 ÍÖ-3
ÍÒ	Самотестування	ÍÒ-1 ÍÒ-3
ÍÀ	Автентифiкацiя вiдправника	ÍÀ-1 ÍÀ-2

5.2.2.2. Ранжирування вимог критерi¨в конфiденцiйностi

Для того, щоб комп'ютерна система могла бути оцiнена на предмет вiдповiдностi критерiям конфiденцiйностi, КЗЗ оцiнювано¨

Стандартизованi моделi та методи оцiнки ефективностi захисту	287

комп'ютерно¨ системи повинен надавати послуги з захисту об'¹ктiв вiд несанкцiонованого ознайомлення з ¨х змiстом (компрометацi¨). Конфiденцiйнiсть забезпечу¹ться такими послугами:

•äîâið÷à êîíôiäåíöiéíiñòü;

•адмiнiстративна конфiденцiйнiсть;

•повторне використання об'¹ктiв;

•аналiз прихованих каналiв;

•êîíôiäåíöiéíiñòü ïðè îáìiíi.

Äîâið÷à êîíôiäåíöiéíiñòü

Послуга довiрчо¨ конфiденцiйностi дозволя¹ користувачу керувати потоками iнформацi¨ вiд захищених об'¹ктiв, що належать його домену, до iнших користувачiв. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi керування:

•мiнiмальна довiрча конфiденцiйнiсть (ÊÄ-1);

•базова довiрча конфiденцiйнiсть (ÊÄ-2);

•повна довiрча конфiденцiйнiсть (ÊÄ-3);

•абсолютна довiрча конфiденцiйнiсть (КД-4). Загальними для усiх рiвнiв вважаються наступнi вимоги:

•запити на змiну прав доступу до об'¹кта повиннi обробляти-

ся КЗЗ на пiдставi атрибутiв доступу користувача, що iнiцiю¹ запит i об'¹кта;

•права доступу до кожного захищеного об'¹кта повиннi встанов-

люватися в момент його створення або iнiцiалiзацi¨. Як частина полiтики довiрчо¨ конфiденцiйностi повиннi бути представленi

правила збереження атрибутiв доступу об'¹ктiв пiд час ¨х експорту та iмпорту.

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

включа¹ наступнi вимоги:

•полiтика довiрчо¨ конфiденцiйностi, що реалiзу¹ться КЗЗ, по-

винна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

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

288	Ðîçäië 5

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

Необхiдна умова: НИ-1.

Рiвень КД-2 Базова довiрча конфiденцiйнiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ конфiденцiйностi, що реалiзу¹ться КЗЗ, по-

винна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв користувача i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

Необхiдна умова: НИ-1.

Рiвень КД-3 Повна довiрча конфiденцiйнiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ конфiденцiйностi, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв користувача i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

процесу, що належить його домену, визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, що не мають права iнiцiювати процес.

Необхiднi умови:КО-1, НИ-1.

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

включа¹ наступнi вимоги:

Стандартизованi моделi та методи оцiнки ефективностi захисту	289

•полiтика довiрчо¨ конфiденцiйностi, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв користувача, процесу i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

процесу, що належить його домену, визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, що не мають права iнiцiювати процес.

Необхiднi умови:КО-1, НИ-1.

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

Послуга адмiнiстративно¨ конфiденцiйностi дозволя¹ адмiнiстратору або спецiально авторизованому користувачу керувати потоками iнформацi¨ вiд захищених об'¹ктiв до користувачiв. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi управлiння:

•мiнiмальна адмiнiстративна конфiденцiйнiсть (ÊÀ-1);

•базова адмiнiстративна конфiденцiйнiсть (ÊÀ-2);

•повна адмiнiстративна конфiденцiйнiсть (ÊÀ-3);

•абсолютна адмiнiстративна конфiденцiйнiсть (КА-4). Загальними для усiх рiвнiв вважаються наступнi вимоги:

•запити на змiну прав доступу повиннi оброблятися КЗЗ тiльки

в тому випадку, якщо вони надходять вiд адмiнiстраторiв або вiд користувачiв, яким наданi вiдповiднi повноваження;

•права доступу до кожного захищеного об'¹кта повиннi встановлюватися в момент його створення або iнiцiалiзацi¨. Як частина

полiтики адмiнiстративно¨ конфiденцiйностi мають бути представленi правила збереження атрибутiв доступу об'¹ктiв пiд час ¨х експорту та iмпорту.

Рiвень КА-1 Мiнiмальна адмiнiстративна конфiденцiйнiсть включа¹ наступнi вимоги:

290	Ðîçäië 5

•полiтика адмiнiстративно¨ конфiденцiйностi, що реалiзу¹ться

КЗЗ, повинна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного захищеного об'¹кта шляхом керування належнiстю користувачiв, процесiв i об'¹ктiв до вiдповiдних доменiв визначити конкре-

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

Необхiднi умови: НО-1, НИ-1.

Рiвень КА-2 Базова адмiнiстративна конфiденцiйнiсть включа¹ наступнi вимоги:

•полiтика адмiнiстративно¨ конфiденцiйностi, що реалiзу¹ться

КЗЗ, повинна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу користувача i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

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

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного процесу через керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв i/або групи

користувачiв, якi мають право iнiцiювати процес. Необхiднi умови: НО-1, НИ-1.

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

включа¹ наступнi вимоги:

•полiтика адмiнiстративно¨ конфiденцiйностi, що реалiзу¹ться

КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

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

Стандартизованi моделi та методи оцiнки ефективностi захисту	291

атрибутiв доступу користувача i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного захищеного об'¹кта шляхом керування належнiстю користувачiв, процесiв i об'¹ктiв до вiдповiдних доменiв визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права одержувати iнформацiю вiд об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного процесу через керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права iнiцiювати процес.

Необхiднi умови: КО-1, НО-1, НИ-1.

Рiвень КА-4 Абсолютна адмiнiстративна конфiденцiйнiсть включа¹ наступнi вимоги:

•полiтика адмiнiстративно¨ конфiденцiйностi, що реалiзу¹ться

КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу користувача, процесу i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного захищеного об'¹кта шляхом керування належнiстю користувачiв, процесiв i об'¹ктiв до вiдповiдних доменiв визначити конкретних користувачiв i процеси (i групи користувачiв i процесiв), якi мають, а також тих, якi не мають права одержувати iнформацiю вiд об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, що ма¹ вiдповiднi повноваження, для кожного процесу через керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права iнiцiювати процес.

Необхiднi умови: КО-1, НО-1, НИ-1.

292	Ðîçäië 5

Повторне використання об'¹ктiв

Послуга повторного використання об'¹ктiв дозволя¹ забезпечи- ти коректнiсть повторного використання роздiлюваних об'¹ктiв, гарантуючи, що в разi, якщо роздiлюваний об'¹кт видiля¹ться новому користувачу або процесу, то вiн не мiстить iнформацi¨, яка залишилась вiд попереднього користувача або процесу.

Рiвень К0-1 Повторне використання об'¹ктiв включа¹ наступнi вимоги:

•полiтика повторного використання об'¹ктiв, що реалiзу¹ться

КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•перш нiж користувач або процес зможе одержати в сво¹ розпо-

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

•перш нiж користувач або процес зможе одержати в сво¹ розпо-

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

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

Аналiз прихованих каналiв викону¹ться з метою виявлення i усунення потокiв iнформацi¨, якi iснують, але не контролюються iншими послугами. Рiвнi дано¨ послуги ранжируються на пiдставi того, чи викону¹ться тiльки виявлення, контроль або перекриття прихованих каналiв:

•виявлення прихованих каналi (ÊÊ-1);

•контроль прихованих каналi (ÊÊ-2);

•перекриття прихованих каналi (ÊÊ-3).

Загально¨ для всiх рiвнiв ¹ послуга: повинен бути виконаний аналiз прихованих каналiв.

Рiвень КК-1 Виявлення прихованих каналiв включа¹ наступнi вимоги:

•всi прихованi канали, якi iснують в апаратному i програмному забезпеченнi, а також в програмах постiйних запам'ятовуючих

Стандартизованi моделi та методи оцiнки ефективностi захисту	293

пристро¨в, повиннi бути документованi;

•ма¹ бути документована максимальна пропускна здатнiсть ко-

жного знайденого прихованого каналу, одержана на пiдставi теоретично¨ оцiнки або вимiрiв;

•для прихованих каналiв, якi можуть використовуватися спiль-

но, повинна бути документована сукупна пропускна здатнiсть. Необхiднi умови: КО-1, Г-3.

Рiвень КК-2 Контроль прихованих каналiв включа¹ наступнi вимоги:

•всi прихованi канали, якi iснують в апаратному i програмному

забезпеченнi, а також в програмах постiйних запам'ятовуючих пристро¨в, повиннi бути документованi;

•ма¹ бути документована максимальна пропускна здатнiсть ко-

жного знайденого прихованого каналу, одержана на пiдставi теоретично¨ оцiнки або вимiрiв;

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

•КЗЗ повинен забезпечувати ре¹страцiю використання затверджено¨ пiдмножини знайдених прихованих каналiв.

Необхiднi умови: КО-1, НР-1, Г-3.

Рiвень КК-3 Перекриття прихованих каналiв включа¹ вимогу: всi (затверджена пiдмножина) знайденi пiд час аналiзу прихованi канали повиннi бути усуненi.

Необхiднi умови: КО-1, Г-3.

Êîíôiäåíöiéíiñòü ïðè îáìiíi

Послуга конфiденцiйностi при обмiнi дозволя¹ забезпечити захист об'¹ктiв вiд несанкцiонованого ознайомлення з iнформацi¹ю, що мiститься в них, пiд час ¨х експорту/iмпорту через незахищене середовище. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi керування:

•мiнiмальна конфiденцiйнiсть при обмiнi (ÊÂ-1);

•базова конфiденцiйнiсть при обмiнi (ÊÂ-2);

•повна конфiденцiйнiсть при обмiнi (ÊÂ-3);

•абсолютна конфiденцiйнiсть при обмiнi (КВ-4). Загальними для усiх рiвнiв вважаються наступнi вимоги:

294	Ðîçäië 5

•полiтика конфiденцiйностi при обмiнi, що реалiзу¹ться КЗЗ, по-

винна визначати рiвень захищеностi, який забезпечу¹ться механiзмами, що використовуються, i спроможнiсть користувачiв i/або процесiв керувати рiвнем захищеностi;

•КЗЗ повинен забезпечувати захист вiд безпосереднього озна-

йомлення з iнформацi¹ю, що мiститься в об'¹ктi, який переда¹ться.

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

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

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

включа¹ наступнi вимоги:

•полiтика конфiденцiйностi при обмiнi, що реалiзу¹ться КЗЗ,

повинна визначати множину об'¹ктiв i iнтерфейсних процесiв, до яких вона вiдноситься;

•запити на призначення або змiну рiвня захищеностi повиннi

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

•запити на експорт захищеного об'¹кта повиннi оброблятися пе-

редавальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу;

•запити на iмпорт захищеного об'¹кта повиннi оброблятися при-

ймальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу.

Необхiдна умова: НО-1.

Рiвень КВ-3 Повна конфiденцiйнiсть при обмiнi вклю- ча¹ наступнi вимоги:

•полiтика конфiденцiйностi при обмiнi, що реалiзу¹ться КЗЗ,

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

•запити на призначення або змiну рiвня захищеностi повиннi

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

•запити на експорт захищеного об'¹кта повиннi оброблятися пе-

Стандартизованi моделi та методи оцiнки ефективностi захисту	295

редавальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i приймальника об'¹кта;

•запити на iмпорт захищеного об'¹кта повиннi оброблятися при-

ймальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i джерела об'¹кта;

•представлення захищеного об'¹кта ма¹ бути функцi¹ю атрибу-

тiв доступу iнтерфейсного процесу, самого об'¹кта, а також його джерела i приймальника.

Необхiднi умови: НО-1, НВ-1.

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

включа¹ наступнi вимоги:

•полiтика конфiденцiйностi при обмiнi, що реалiзу¹ться КЗЗ,

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

•запити на призначення або змiну рiвня захищеностi повиннi

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

•запити на експорт захищеного об'¹кта повиннi оброблятися пе-

редавальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i приймальника об'¹кта;

•запити на iмпорт захищеного об'¹кта повиннi оброблятися при-

ймальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i джерела об'¹кта;

•представлення захищеного об'¹кта ма¹ бути функцi¹ю атрибу-

тiв доступу iнтерфейсного процесу, самого об'¹кта, а також його джерела i приймальника;

•полiтика конфiденцiйностi при обмiнi повинна включати опис

iнформацi¨, яку можливо отримати шляхом сумiсного аналiзу ряду одержаних об'¹ктiв;

•повинен бути виконаний аналiз прихованих каналiв обмiну. Всi

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

Необхiднi умови: НО-1, НВ-1, НР-1, Г-3.

296	Ðîçäië 5

5.2.2.3. Ранжирування вимог критерi¨в цiлiсностi

Для того, щоб комп'ютерна система могла бути оцiнена на предмет вiдповiдностi критерiям цiлiсностi, КЗЗ оцiнювано¨ комп'ю- терно¨ системи повинен надавати послуги з захисту оброблювано¨ iнформацi¨ вiд несанкцiоновано¨ модифiкацi¨. Цiлiснiсть забезпе- чу¹ться такими послугами:

•äîâið÷à öiëiñíiñòü;

•адмiнiстративна цiлiснiсть;

•âiäêiò;

•öiëiñíiñòü ïðè îáìiíi.

Äîâið÷à öiëiñíiñòü

Послуга довiрчо¨ цiлiсностi дозволя¹ користувачу керувати потоками iнформацi¨ вiд iнших користувачiв до захищених об'¹ктiв, що належать його домену. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi керування:

•мiнiмальна довiрча цiлiснiсть (ÖÄ-1);

•базова довiрча цiлiснiсть (ÖÄ-2);

•повна довiрча цiлiснiсть (ÖÄ-3);

•абсолютна довiрча цiлiснiсть (ÖÄ-4).

Загальними для усiх рiвнiв вважаються наступнi вимоги:

•запити на змiну прав доступу до об'¹кта повиннi обробляти-

ся КЗЗ на пiдставi атрибутiв доступу користувача, що iнiцiю¹ запит i об'¹кта;

•права доступу до кожного захищеного об'¹кта повиннi встанов-

люватися в момент його створення або iнiцiалiзацi¨. Як частина полiтики довiрчо¨ цiлiсностi повиннi бути представленi правила збереження атрибутiв доступу об'¹ктiв пiд час ¨х експорту та iмпорту.

Рiвень ЦД-1 Мiнiмальна довiрча цiлiснiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна ви-

значати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

Стандартизованi моделi та методи оцiнки ефективностi захисту	297

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу користувача i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

захищеного об'¹кта, що належить його домену, визначити конкретних користувачiв i/або групи користувачiв, якi мають право модифiкувати об'¹кт.

Необхiдна умова: НИ-1.

Рiвень ЦД-2 Базова довiрча цiлiснiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна ви-

значати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

Необхiдна умова: НИ-1.

Рiвень ЦД-3 Повна довiрча цiлiснiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

процесу, що належить його домену, визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права iнiцiювати процес.

298	Ðîçäië 5

Необхiднi умови: КО-1, НИ-1.

Рiвень ЦД-4 Абсолютна довiрча цiлiснiсть включа¹ наступнi вимоги:

•полiтика довiрчо¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу, користувача i захищеного об'¹кта;

•КЗЗ повинен надавати користувачу можливiсть для кожного

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

•КЗЗ повинен надавати користувачу можливiсть для кожного

процесу, що належить його домену, визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права iнiцiювати процес.

Необхiднi умови: КО-1, НИ-1.

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

Послуга адмiнiстративно¨ цiлiсностi дозволя¹ адмiнiстратору або спецiально авторизованому користувачу керувати потоками iнформацi¨ вiд користувачiв до захищених об'¹ктiв. Рiвнi дано¨ послуги ран жируються на пiдставi повноти захисту i вибiрковостi керування:

•мiнiмальна адмiнiстративна цiлiснiсть (ÖÀ-1);

•базова адмiнiстративна цiлiснiсть (ÖÀ-2);

•повна адмiнiстративна цiлiснiсть (ÖÀ-3);

•абсолютна адмiнiстративна цiлiснiсть (ЦА-4). Загальними для усiх рiвнiв вважаються наступнi вимоги:

•запити на змiну прав доступу повиннi оброблятися КЗЗ тiльки

в тому випадку, якщо вони надходять вiд адмiнiстраторiв або вiд користувачiв, яким наданi вiдповiднi повноваження;

•права доступу до кожного захищеного об'¹кта повиннi встанов-

люватися в момент його створення або iнiцiалiзацi¨. Як частина полiтики адмiнiстративно¨ цiлiсностi мають бути представленi

Стандартизованi моделi та методи оцiнки ефективностi захисту	299

правила збереження атрибутiв доступу об'¹ктiв пiд час ¨х експорту i iмпорту.

Рiвень ЦА-1 Мiнiмальна адмiнiстративна цiлiснiсть

включа¹ наступнi вимоги:

•полiтика адмiнiстративно¨ цiлiсностi, що реалiзу¹ться КЗЗ, по-

винна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу користувача i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

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

модифiкувати об'¹кт. Необхiднi умови: НО-1, НИ-1.

Рiвень ЦА-2 Базова адмiнiстративна цiлiснiсть вклю- ча¹ наступнi вимоги:

•полiтика адмiнiстративно¨ цiлiсностi, що реалiзу¹ться КЗЗ, по-

винна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

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

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, який ма¹ вiдповiднi повноваження, для кожного процесу шляхом керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв i/або групи користувачiв, якi мають право iнiцiювати процес.

Необхiднi умови: НО-1, НИ-1.

Рiвень ЦА-3 Повна адмiнiстративна цiлiснiсть вклю- ча¹ наступнi вимоги:

300	Ðîçäië 5

•полiтика адмiнiстративно¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

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

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, який ма¹ вiдповiднi повноваження, для кожного процесу шляхом керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв (i гру-

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

Необхiднi умови: КО-1, НО-1, НИ-1.

Рiвень ЦА-4 Абсолютна адмiнiстративна цiлiснiсть

включа¹ наступнi вимоги:

•полiтика адмiнiстративно¨ цiлiсностi, що реалiзу¹ться КЗЗ, повинна вiдноситись до всiх об'¹ктiв комп'ютерно¨ системи;

•КЗЗ повинен здiйснювати розмежування доступу на пiдставi атрибутiв доступу процесу, користувача i захищеного об'¹кта;

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

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

•КЗЗ повинен надавати можливiсть адмiнiстратору або кори-

стувачу, який ма¹ вiдповiднi повноваження, для кожного процесу шляхом керування належнiстю користувачiв i процесiв до вiдповiдних доменiв визначити конкретних користувачiв (i групи користувачiв), якi мають, а також тих, якi не мають права iнiцiювати процес.

Необхiднi умови: КО-1, НО-1, НИ-1.

Стандартизованi моделi та методи оцiнки ефективностi захисту	301

Âiäêiò

Послуга вiдкоту забезпечу¹ можливiсть вiдмiнити операцiю або послiдовнiсть операцiй i повернути (вiдкотити) захищений об'¹кт до попереднього стану. Рiвнi дано¨ послуги ранжируються на пiдставi множини операцiй, для яких забезпечу¹ться вiдкiт:

•обмежений вiдкiт (ÖÎ-1);

•повний вiдкiт (ÖÎ-2).

Загальною для усiх рiвнiв вважаються вимога: полiтика вiдкоту, що реалiзу¹ться КЗЗ, повинна визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься.

Ðiâåíü ÖÎ-1 Обмежений вiдкiт включа¹ наступну вимогу: повиннi iснувати автоматизованi засоби, якi дозволяють авторизованому користувачу або процесу вiдкотити або вiдмiнити певний набiр (множину) операцiй, виконаних над захищеним об'¹ктом за певний промiжок часу.

Необхiдна умова: НИ-1.

Ðiâåíü ÖÎ-2 Повний вiдкiт включа¹ наступну вимогу: повиннi iснувати автоматизованi засоби, якi дозволяють авторизованому користувачу або процесу вiдкотити або вiдмiнити всi операцi¨, виконанi над захищеним об'¹ктом за певний промiжок часу.

Необхiдна умова: НИ-1.

Öiëiñíiñòü ïðè îáìiíi

Послуга цiлiсностi при обмiнi дозволя¹ забезпечити захист об'- ¹ктiв вiд несанкцiоновано¨ модифiкацi¨ iнформацi¨, що мiститься в них, пiд час ¨х експорту/iмпорту через незахищене середовище. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi керування:

•мiнiмальна цiлiснiсть при обмiнi (ÖÂ-1);

•базова цiлiснiсть при обмiнi (ÖÂ-2);

•Повна цiлiснiсть при обмiнi (ÖÂ-3).

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

302	Ðîçäië 5

яких вона вiдноситься, рiвень захищеностi, що забезпечу¹ться використовуваними механiзмами, i спроможнiсть користувачiв i/або процесiв керувати рiвнем захищеностi.

Рiвень ЦО-1 Мiнiмальна цiлiснiсть при обмiнi включа¹ наступну вимогу: КЗЗ повинен забезпечувати можливiсть виявлення порушення цiлiсностi iнформацi¨, що мiститься в об'¹ктi, який переда¹ться.

Рiвень ЦО-2 Базова цiлiснiсть при обмiнi включа¹ наступнi вимоги:

•КЗЗ повинен забезпечувати можливiсть виявлення порушення

цiлiсностi iнформацi¨, що мiститься в об'¹ктi, який переда¹ться а також фактiв його видалення або дублювання;

•запити на експорт захищеного об'¹кта повиннi оброблятися пе-

редавальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу;

•запити на iмпорт захищеного об'¹кта повиннi оброблятися при-

ймальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу;

•запити на присво¹ння або змiну рiвня захищеностi повиннi

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

Необхiдна умова НО-1.

Рiвень ЦО-3 Повна цiлiснiсть при обмiнi включа¹ наступнi вимоги:

•КЗЗ повинен забезпечувати можливiсть виявлення порушення

цiлiсностi iнформацi¨, що мiститься в об'¹ктi, який переда¹ться а також фактiв його видалення або дублювання;

•запити на експорт захищеного об'¹кта повиннi оброблятися пе-

редавальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i приймальника об'¹кта;

•запити на iмпорт захищеного об'¹кта повиннi оброблятися при-

ймальним КЗЗ на пiдставi атрибутiв доступу iнтерфейсного процесу i джерела об'¹кта;

•запити на присво¹ння або змiну рiвня захищеностi повиннi

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

Ðiâåíü ÄÐ-1 Квоти

Стандартизованi моделi та методи оцiнки ефективностi захисту	303

повноваження;

•представлення захищеного об'¹кта ма¹ бути функцi¹ю атрибу-

тiв доступу iнтерфейсного процесу, самого об'¹кта, а також його джерела i приймальника.

Необхiднi умови НО-1, НВ-1.

5.2.2.4. Ранжирування вимог критерi¨в доступностi

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

•використання ресурсiв;

•ñòiéêiñòü äî âiäìîâ;

•гаряча замiна;

•вiдновлення пiсля збо¨в.

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

Послуга використання ресурсiв дозволя¹ користувачам керувати використанням послуг i ресурсiв. Рiвнi дано¨ послуги ранжируються на пiдставi повноти захисту i вибiрковостi керування доступнiстю послуг комп'ютерно¨ системи:

•квоти (ÄÐ-1);

•недопущення захоплення ресурсiв (ÄÐ-2);

•прiоритетнiсть використання ресурсiв (ÄÐ-3).

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

Необхiдна загальна умова: НО-1.

включа¹ наступнi вимоги:

304	Ðîçäië 5

•полiтика використання ресурсiв, що реалiзу¹ться КЗЗ, повин-

на визначати множину об'¹ктiв комп'ютерно¨ системи, до яких вона вiдноситься;

•полiтика використання ресурсiв повинна визначати обмежен-

ня, якi можна накладати, на кiлькiсть даних об'¹ктiв (обсяг ресурсiв), що видiляються окремому користувачу.

Рiвень ДР-2 Недопущення захоплення ресурсiв вклю- ча¹ наступнi вимоги:

•полiтика використання ресурсiв, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх об'¹ктiв комп'ютерно¨ системи;

•полiтика використання ресурсiв повинна визначати обмежен-

ня, якi можна накладати, на кiлькiсть даних об'¹ктiв (обсяг ресурсiв), що видiляються окремому користувачу;

•повинна iснувати можливiсть встановлювати обмеження та-

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

лювати такi дi¨, здiйснюванi з боку окремого користувача.

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

включа¹ наступнi вимоги:

•полiтика використання ресурсiв, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх об'¹ктiв комп'ютерно¨ системи;

•полiтика використання ресурсiв повинна визначати обмежен-

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

•повинна iснувати можливiсть встановлювати обмеження та-

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

Ñòiéêiñòü äî âiäìîâ

Послуга стiйкостi до вiдмов гаранту¹ доступнiсть комп'ютерно¨ системи (можливiсть використання iнформацi¨, окремих функцiй

Стандартизованi моделi та методи оцiнки ефективностi захисту	305

або комп'ютерно¨ системи в цiлому) пiсля вiдмови ¨¨ компонента. Рiвнi дано¨ послуги ранжируються на пiдставi спроможностi КЗЗ забезпечити можливiсть функцiонування комп'ютерно¨ системи в залежностi вiд кiлькостi вiдмов i послуг, доступних пiсля вiдмови:

•стiйкiсть при обмежених вiдмовах (ÄÑ-1);

•стiйкiсть iз погiршенням характеристик обслуговування (ДС- 2);

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

3).

Загальними для усiх рiвнiв вважаються вимоги:

•розробник повинен провести аналiз вiдмов компонентiв ком- п'ютерно¨ системи;

•повиннi бути чiтко вказанi рiвнi вiдмов, при перевищеннi яких

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

•повиннi бути чiтко вказанi рiвнi вiдмов, при перевищеннi яких

вiдмови призводять до зниження характеристик обслуговування або недоступностi послуги.

Необхiдна загальна умова: НО-1

Рiвень ДС-1 Стiйкiсть при обмежених вiдмовах вклю- ча¹ наступнi вимоги:

•полiтика стiйкостi до вiдмов, що реалiзу¹ться КЗЗ, повинна ви-

значати множину компонентiв комп'ютерно¨ системи, до яких вона вiдноситься, i типи ¨х вiдмов, пiсля яких комп'ютерна система в змозi продовжувати функцiонування;

•вiдмова одного захищеного компонента не повинна призводити

до недоступностi всiх послуг, а ма¹ в гiршому випадку проявлятися в зниженнi характеристик обслуговування.

Рiвень ДС-2 Стiйкiсть iз погiршенням характеристик обслуговування включа¹ наступнi вимоги:

•полiтика стiйкостi до вiдмов, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх компонентiв комп'ютерно¨ системи;

•вiдмова одного захищеного компонента не повинна призводити

до недоступностi всiх послуг, а ма¹ в гiршому випадку проявлятися в зниженнi характеристик обслуговування.

Рiвень ДС-3 Стiйкiсть без погiршенням характеристик обслуговування включа¹ наступнi вимоги:

306	Ðîçäië 5

•полiтика стiйкостi до вiдмов, що реалiзу¹ться КЗЗ, повинна вiдноситися до всiх компонентiв комп'ютерно¨ системи;

•вiдмова одного захищеного компонента не повинна призводити

до недоступностi всiх послуг або до зниження характеристик обслуговування.

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

Послуга гарячо¨ замiни дозволя¹ гарантувати доступнiсть ком- п'ютерно¨ системи (можливiсть використання iнформацi¨, окремих функцiй або комп'ютерно¨ системи в цiлому) в процесi замiни окремих компонентiв. Рiвнi дано¨ послуги ранжируються на пiдставi повноти реалiзацi¨:

•модернiзацiя (ÄÇ-1);

•обмежена гаряча замiна (ÄÇ-2);

•гаряча замiна будь-якого компонента (ДЗ-3).

Рiвень ДЗ-1 Модернiзацiя включа¹ наступнi вимоги:

•полiтика гарячо¨ замiни, що реалiзу¹ться КЗЗ, повинна визна- чати полiтику проведення модернiзацi¨ комп'ютерно¨ системи;

•адмiнiстратор або користувачi, яким наданi вiдповiднi пов-

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

Необхiдна умова: НО-1.

Рiвень ДЗ-2 Обмежена гаряча замiна включа¹ наступнi вимоги:

•полiтика гарячо¨ замiни, що реалiзу¹ться КЗЗ, повинна визна-

чати множину компонентiв комп'ютерно¨ системи, якi можуть бути замiненi без переривання обслуговування;

•адмiнiстратор або користувачi, яким наданi вiдповiднi повно-

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

Необхiднi умови: НО-1, ДС-1.

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

включа¹ наступнi вимоги:

Стандартизованi моделi та методи оцiнки ефективностi захисту	307

•полiтика гарячо¨ замiни, що реалiзу¹ться КЗЗ, повинна забез-

печувати можливiсть замiни будь-якого компонента без переривання обслуговування;

•адмiнiстратор або користувачi, яким наданi вiдповiднi повно-

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

Необхiднi умови: НО-1, ДС-1.

Вiдновлення пiсля збо¨в

Послуга вiдновлення пiсля збо¨в забезпечу¹ повернення ком- п'ютерно¨ системи у вiдомий захищений стан пiсля вiдмови або переривання обслуговування. Рiвнi дано¨ послуги ранжируються на пiдставi мiри автоматизацi¨ процесу вiдновлення:

•ручне вiдновлення (ÄÂ-1);

•автоматизоване вiдновлення (ÄÂ-2);

•вибiркове вiдновлення (ÄÂ-3).

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

Необхiдна загальна умова: НО-1.

Рiвень ДВ-1 Ручне вiдновлення включа¹ наступнi вимо-

ãè:

•пiсля вiдмови комп'ютерно¨ системи або переривання обслуго-

вування КЗЗ повинен перевести комп'ютерну систему до стану, iз якого повернути ¨¨ до нормального функцiонування може тiльки адмiнiстратор або користувачi, яким наданi вiдповiднi повноваження;

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

безпечним чином повернути комп'ютерну систему до нормального функцiонування.

Рiвень ДВ-2 Автоматизоване вiдновлення включа¹ наступнi вимоги:

308	Ðîçäië 5

•пiсля вiдмови комп'ютерно¨ системи або переривання обслуго-

вування КЗЗ ма¹ бути здатним визначити, чи можуть бути використанi автоматизованi процедури для повернення комп'ю- терно¨ системи до нормального функцiонування безпечним чи- ном. Якщо такi процедури можуть бути використанi, то КЗЗ ма¹ бути здатним виконати ¨х i повернути комп'ютерну систему до нормального функцiонування;

•якщо автоматизованi процедури не можуть бути використанi,

то КЗЗ повинен перевести комп'ютерну систему до стану, з якого повернути ¨¨ до нормального функцiонування може тiльки адмiнiстратор або користувачi, яким наданi вiдповiднi повноваження;

•повиннi iснувати ручнi процедури, за допомогою яких можна безпечним чином повернути комп'ютерну систему до нормаль-

ного функцiонування.

Рiвень ДВ-3 Вибiркове вiдновлення включа¹ наступнi вимоги:

•ïiñëÿ будь-яко¨ вiдмови комп'ютерно¨ системи або переривання

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

•якщо автоматизованi процедури не можуть бути використанi,

то КЗЗ повинен перевести комп'ютерну систему до стану, з якого повернути ¨¨ до нормального функцiонування може тiльки адмiнiстратор або користувачi, яким наданi вiдповiднi повноваження;

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

безпечним чином повернути комп'ютерну систему з режиму з погiршеними характеристиками обслуговування в режим нормального функцiонування.

Стандартизованi моделi та методи оцiнки ефективностi захисту	309

5.2.2.5. Ранжирування вимог критерi¨в спостережностi

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

•ре¹страцiя (аудит);

•iдентифiкацiя i автентифiкацiя;

•достовiрний канал;

•розподiл обов'язкiв;

•öiëiñíiñòü ÊÇÇ;

•самотестування;

•iдентифiкацiя i автентифiкацiя при обмiнi;

•автентифiкацiя вiдправника;

•автентифiкацiя отримувача.

Ре¹страцiя

Послуга ре¹страцiя дозволя¹ контролювати небезпечнi для комп'ютерно¨ системи дi¨. Рiвнi дано¨ послуги ранжируються залежно вiд повноти i вибiрковостi контролю, складностi засобiв аналiзу даних журналiв ре¹страцi¨ i спроможностi вияву потенцiйних порушень:

•çîâíiøíié àíàëiç (ÍÐ-1);

•захищений журнал (ÍÐ-2);

•сигналiзацiя про небезпеку (ÍÐ-3);

•детальна ре¹страцiя (ÍÐ-4);

•аналiз в реальному часi (ÍÐ-5).

Загальними для усiх рiвнiв вважаються наступнi вимоги:

•полiтика ре¹страцi¨, що реалiзу¹ться КЗЗ, повинна визначати перелiк подiй, що ре¹струються;

•журнал ре¹страцi¨ повинен мiстити iнформацiю про дату, час,

мiсце, тип i успiшнiсть чи неуспiшнiсть кожно¨ заре¹стровано¨ подi¨. Журнал ре¹страцi¨ повинен мiстити iнформацiю, достатню для встановлення користувача, процесу i/або об'¹кта, що

310	Ðîçäië 5

мали вiдношення до кожно¨ заре¹стровано¨ подi¨;

Ðiâåíü ÍÐ-1 Çîâíiøíié àíàëiç включа¹ наступнi вимоги:

•КЗЗ повинен бути здатним здiйснювати ре¹страцiю подiй, що мають безпосередн¹ вiдношення до безпеки;

•КЗЗ ма¹ бути здатним передавати журнал ре¹страцi¨ в iншi

системи з використанням певних механiзмiв захисту. Необхiдна умова: НИ-1.

Рiвень НР-2 Захищений журнал включа¹ наступнi вимоги:

•КЗЗ повинен бути здатним здiйснювати ре¹страцiю подiй, що мають безпосередн¹ вiдношення до безпеки;

•КЗЗ повинен забезпечувати захист журналу ре¹страцi¨ вiд не-

санкцiонованого доступу, модифiкацi¨ або руйнування. Адмiнiстратори i користувачi, яким наданi вiдповiднi повноваження, повиннi мати в сво¹му розпорядженнi засоби перегляду i аналiзу журналу ре¹страцi¨.

Необхiднi умови: НИ-1, НО-1.

Рiвень НР-3 Сигналiзацiя про небезпеку включа¹ наступнi вимоги:

•КЗЗ повинен бути здатним здiйснювати ре¹страцiю подiй, що мають безпосередн¹ вiдношення до безпеки;

•КЗЗ повинен забезпечувати захист журналу ре¹страцi¨ вiд не-

санкцiонованого доступу, модифiкацi¨ або руйнування. Адмiнiстратори i користувачi, яким наданi вiдповiднi повноваження, повиннi мати в сво¹му розпорядженнi засоби перегляду i аналiзу журналу ре¹страцi¨;

•КЗЗ ма¹ бути здатним контролювати одиничнi або повторюванi

ре¹страцiйнi подi¨, якi можуть свiдчити про прямi (iстотнi) порушення полiтики безпеки КС. КЗЗ ма¹ бути здатним негайно iнформувати адмiнiстратора про перевищення порогiв безпеки i, якщо ре¹страцiйнi небезпечнi подi¨ повторюються, здiйснити неруйнiвнi дi¨ щодо припинення повторення цих подiй.

Необхiднi умови: НИ-1, НО-1.

Рiвень НР-4 Детальна ре¹страцiя включа¹ наступнi вимоги:

•КЗЗ повинен бути здатним здiйснювати ре¹страцiю подiй, що мають безпосередн¹ або непряме вiдношення до безпеки;

Стандартизованi моделi та методи оцiнки ефективностi захисту	311

•КЗЗ повинен забезпечувати захист журналу ре¹страцi¨ вiд не-

санкцiонованого доступу, модифiкацi¨ або руйнування. Адмiнiстратори i користувачi, яким наданi вiдповiднi повноваження, повиннi мати в сво¹му розпорядженнi засоби перегляду i аналiзу журналу ре¹страцi¨;

•КЗЗ ма¹ бути здатним контролювати одиничнi або повторюванi

ре¹страцiйнi подi¨, якi можуть свiдчити про прямi (iстотнi) порушення полiтики безпеки КС. КЗЗ ма¹ бути здатним негайно iнформувати адмiнiстратора про перевищення порогiв безпеки i, якщо ре¹страцiйнi небезпечнi подi¨ повторюються, здiйснити неруйнiвнi дi¨ щодо припинення повторення цих подiй.

Необхiднi умови: НИ-1, НО-1.

Рiвень НР-5 Аналiз в реальному часi включа¹ наступнi вимоги:

•КЗЗ повинен бути здатним здiйснювати ре¹страцiю подiй, що мають безпосередн¹ або непряме вiдношення до безпеки;

•КЗЗ повинен забезпечувати захист журналу ре¹страцi¨ вiд не-

санкцiонованого доступу, модифiкацi¨ або руйнування. Адмiнiстратори i користувачi, яким наданi вiдповiднi повноваження, повиннi мати в сво¹му розпорядженнi засоби перегляду i аналiзу журналу ре¹страцi¨;

•КЗЗ ма¹ бути здатним контролювати одиничнi або повторюванi

ре¹страцiйнi подi¨, якi можуть свiдчити про прямi (iстотнi) порушення полiтики безпеки КС. КЗЗ ма¹ бути здатним негайно iнформувати адмiнiстратора про перевищення порогiв безпеки i, якщо ре¹страцiйнi небезпечнi подi¨ повторюються, здiйснити неруйнiвнi дi¨ щодо припинення повторення цих подiй

•КЗЗ ма¹ бути здатним виявляти i аналiзувати несанкцiонованi

дi¨ в реальному часi. Необхiднi умови: НИ-1, НО-1.

Iдентифiкацiя i автентифiкацiя

Послуга iдентифiкацi¨ i автентифiкацi¨ дозволя¹ КЗЗ визначи- ти i перевiрити особистiсть користувача, що намага¹ться одержати доступ до комп'ютерно¨ системи. Рiвнi дано¨ послуги ранжируються залежно вiд числа задiяних механiзмiв автентифiкацi¨:

312	Ðîçäië 5

•зовнiшня iдентифiкацiя i автентифiкацiя (ÍÈ-1);

•одиночна iдентифiкацiя i автентифiкацiя (ÍÈ-2);

•множинна iдентифiкацiя i автентифiкацiя (ÍÈ-3).

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

Рiвень НИ-1 Зовнiшня iдентифiкацiя i автентифiкацi- я включа¹ наступну вимогу: перш нiж дозволити будь-якому користувачу виконувати áóäü-ÿêi iншi, контрольованi КЗЗ дi¨, КЗЗ повинен з використанням захищеного механiзму одержати вiд деякого зовнiшнього джерела автентифiкований iдентифiкатор цього користувача.

Рiвень НИ-2 Одиночна iдентифiкацiя i автентифiкацi- я включа¹ наступнi вимоги:

•перш нiж дозволити будь-якому користувачу виконувати будь-

якi iншi, контрольованi КЗЗ дi¨, КЗЗ повинен автентифiкувати цього користувача з використанням захищеного механiзму;

•КЗЗ повинен забезпечувати захист даних автентифiкацi¨ вiд

несанкцiонованого доступу, модифiкацi¨ або руйнування. Необхiдна умова: НК-1.

Рiвень НИ-3 Множинна iдентифiкацiя i автентифiкацiя включа¹ наступнi вимоги:

•перш нiж дозволити будь-якому користувачу виконувати будь-

якi iншi, контрольованi КЗЗ дi¨, КЗЗ повинен автентифiкувати цього користувача з використанням захищених механiзмiв двох або бiльше типiв;

•КЗЗ повинен забезпечувати захист даних автентифiкацi¨ вiд

несанкцiонованого доступу, модифiкацi¨ або руйнування. Необхiдна умова: НК-1.

Достовiрний канал

Послуга достовiрного каналу дозволя¹ гарантувати користува- чу можливiсть безпосередньо¨ вза¹модi¨ з КЗЗ. Рiвнi дано¨ послуги ранжируються залежно вiд гнучкостi надання можливостi КЗЗ

Стандартизованi моделi та методи оцiнки ефективностi захисту	313

або користувачу iнiцiювати захищений обмiн:

•однонаправлений достовiрний канал (ÍÊ-1);

•двонаправлений достовiрний канал (ÍÊ-2).

Загальною для усiх рiвнiв вважа¹ться вимога: полiтика достовiрного каналу, що реалiзу¹ться КЗЗ, повинна визначати механiзми встановлення достовiрного зв'язку мiж користувачем i КЗЗ.

Рiвень НК-1 Однонаправлений достовiрний канал

включа¹ наступну вимогу: достовiрний канал повинен використовуватися для початково¨ iдентифiкацi¨ i автентифiкацi¨. Зв'язок з використанням даного каналу повинен iнiцiюватися виключно користувачем.

Рiвень НК-2 Двонаправлений достовiрний канал

включа¹ наступнi вимоги:

•достовiрний канал повинен використовуватися для початково¨

iдентифiкацi¨ i автентифiкацi¨ та у випадках, коли необхiдний прямий зв'язок користувач/КЗЗ або КЗЗ/користувач. Зв'язок з використанням даного каналу повинен iнiцiюватися користувачем або КЗЗ;

•обмiн з використанням достовiрного каналу, що iнiцiю¹ КЗЗ,

повинен бути однозначно iдентифiкований як такий i ма¹ вiдбутися тiльки пiсля позитивного пiдтвердження готовностi до обмiну з боку користувача.

Розподiл обов'язкiв

Послуга розподiл обов'язкiв дозволя¹ зменшити потенцiйнi збитки вiд навмисних або помилкових дiй користувача i обмежити авторитарнiсть керування. Рiвнi дано¨ послуги ранжируються на пiдставi вибiрковостi керування можливостями користувачiв i адмiнiстраторiв:

•видiлення адмiнiстратора (ÍÎ-1);

•розподiл обов'язкiв адмiнiстратора (ÍÎ-2);

•розподiл обов'язкiв на пiдставi привiле¨в (НО-3). Загальною для усiх рiвнiв вважаються наступнi вимоги:

•полiтика розподiлу обов'язкiв, що реалiзу¹ться КЗЗ, повинна

визначати ролi адмiнiстратора i звичайного користувача i притаманнi ¨м функцi¨;

314	Ðîçäië 5

•Користувач повинен мати можливiсть виступати в певнiй ролi

тiльки пiсля того, як вiн викона¹ певнi дi¨, що пiдтверджують прийняття ¨м цi¹¨ ролi.

Необхiдна загальна умова: НИ-1.

Рiвень НО-1 Видiлення адмiнiстратора включа¹ загальнi для усi рiвнiв вимоги i умову.

Рiвень НО-2 Розподiл обов'язкiв адмiнiстратора вклю- ча¹ наступну вимогу: полiтика розподiлу обов'язкiв повинна визначати мiнiмум двi адмiнiстративнi ролi: адмiнiстратора безпеки та iншого адмiнiстратора. Функцi¨, притаманнi кожнiй iз ролей, повиннi бути мiнiмiзованi так, щоб включати тiльки тi функцi¨, якi необхiднi для виконання дано¨ ролi.

Рiвень НО-3 Розподiл обов'язкiв адмiнiстратора на пiдставi привiле¨в включа¹ наступнi вимоги:

•полiтика розподiлу обов'язкiв повинна визначати мiнiмум двi

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

•полiтика розподiлу обов'язкiв повинна визначати множину ролей користувачiв.

Цiлiснiсть комплексу засобiв захисту

Ця послуга визнача¹ мiру здатностi КЗЗ захищати себе i гарантувати свою спроможнiсть керувати захищеними об'¹ктами. Вклю- ча¹ наступнi рiвнi:

•КЗЗ з контролем цiлiсностi (ÍÖ-1);

•КЗЗ з гарантованою цiлiснiстю (ÍÖ-2);

•КЗЗ з функцiями диспетчера доступу (ÍÖ-3).

Рiвень НЦ-1 КЗЗ з контролем цiлiсностi включа¹ наступнi вимоги:

•полiтика цiлiсностi КЗЗ повинна визначати склад КЗЗ i меха-

нiзми контролю цiлiсностi компонентiв, що входять до складу КЗЗ;

•в разi виявлення порушення цiлiсностi будь-якого iз сво¨х компонентiв КЗЗ повинен повiдомити адмiнiстратора i або авто-

Стандартизованi моделi та методи оцiнки ефективностi захисту	315

матично вiдновити вiдповiднiсть компонента еталону або перевести КС до стану, з якого повернути ¨¨ до нормального функцiонування може тiльки адмiнiстратор або користувачi, яким наданi вiдповiднi повноваження;

•повиннi бути описанi обмеження, дотримання яких дозволя¹

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

Необхiднi умови: НР-1, НО-1.

Рiвень НЦ-2 КЗЗ з гарантованою цiлiснiстю включа¹ наступнi вимоги:

•полiтика цiлiсностi КЗЗ повинна визначати домен КЗЗ та iншi

домени, а також механiзми захисту, що використовуються для реалiзацi¨ розподiлення доменiв;

•КЗЗ повинен пiдтримувати домен для свого власного викона-

ння з метою захисту вiд зовнiшнiх впливiв i несанкцiоновано¨ модифiкацi¨ i/або втрати керування;

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

фейс КЗЗ i всi запити на доступ до захищених об'¹ктiв контролюються КЗЗ.

Рiвень НЦ-3 КЗЗ з функцiями диспетчера доступу

включа¹ наступнi вимоги:

•полiтика цiлiсностi КЗЗ повинна визначати домен КЗЗ та iншi

домени, а також механiзми захисту, що використовуються для реалiзацi¨ розподiлення доменiв;

•КЗЗ повинен пiдтримувати домен для свого власного викона-

ння з метою захисту вiд зовнiшнiх впливiв i несанкцiоновано¨ модифiкацi¨ i/або втрати керування;

•КЗЗ повинен гарантувати, що послуги безпеки доступнi тiль-

ки через iнтерфейс КЗЗ i всi запити на доступ до захищених об'¹ктiв контролюються КЗЗ.

Самотестування

Самотестування дозволя¹ КЗЗ перевiрити i на пiдставi цього гарантувати правильнiсть функцiонування i цiлiснiсть певно¨ мно-

316	Ðîçäië 5

жини функцiй КС. Рiвнi дано¨ послуги ранжируються на пiдставi можливостi виконання тестiв у процесi запуску або штатно¨ роботи:

•самотестування за запитом (ÍÒ-1);

•самотестування при стартi (ÍÒ-2);

•самотестування в реальному часi (ÍÒ-3).

Загальною для усiх рiвнiв вважаються наступна вимога: полiтика самотестувания, що реалiзу¹ться КЗЗ, повинна описувати властивостi комп'ютерно¨ системи i реалiзованi процедури, якi можуть бути використанi для оцiнки правильностi функцiонування КЗЗ.

Необхiдна загальна умова: НО-1.

Рiвень НТ-1 Самотестування за запитом включа¹ наступну вимогу: КЗЗ ма¹ бути здатним виконувати набiр тестiв з метою оцiнки правильностi функцiонування сво¨х критичних функцiй. Тести повиннi виконуватися за запитом користувача, що ма¹ вiдповiднi повноваження.

Рiвень НТ-2 Самотестування при стартi включа¹ наступну вимогу: КЗЗ ма¹ бути здатним виконувати набiр тестiв з метою оцiнки правильностi функцiонування сво¨х критичних функцiй. Тести повиннi виконуватися за запитом користувача, що ма¹ вiдповiднi повноваження, при iнiцiалiзацi¨ КЗЗ.

Рiвень НТ-3 Самотестування в реальному часi вклю- ча¹ наступну вимогу: КЗЗ ма¹ бути здатним виконувати набiр тестiв з метою оцiнки правильностi функцiонування сво¨х критичних функцiй. Тести повиннi виконуватися за запитом користувача, що ма¹ вiдповiднi повноваження, при iнiцiалiзацi¨ КЗЗ i в процесi штатного функцiонування.

Iдентифiкацiя i автентифiкацiя при обмiнi

Ця послуга дозволя¹ одному КЗЗ iдентифiкувати iнший КЗЗ (встановити i перевiрити його iдентичнiсть) i забезпечити iншому КЗЗ можливiсть iдентифiкувати перший, перш нiж почати вза¹модiю. Рiвнi дано¨ послуги ранжируються на пiдставi повноти реалiзацi¨:

• автентифiкацiя вузла (НВ-1);

Стандартизованi моделi та методи оцiнки ефективностi захисту	317

•автентифiкацiя джерела даних (ÍÂ-2);

•автентифiкацiя пiдтвердження (ÍÂ-3).

Загальними для усiх рiвнiв вважаються наступнi вимоги:

•полiтика iдентифiкацi¨ i автентифiкацiя при обмiнi, що реалiзу-

¹ться КЗЗ, повинна визначати множину атрибутiв КЗЗ i процедури, якi необхiднi для вза¹мно¨ iдентифiкацi¨ при iнiцiалiзацi¨ обмiну даними з iншим КЗЗ;

•КЗЗ, перш нiж почати обмiн даними з iншим КЗЗ, повинен

iдентифiкувати i автентифiкувати цей КЗЗ с використанням захищеного механiзму;

•пiдтвердження iдентичностi ма¹ виконуватися на пiдставi затвердженого протоколу автентифiкацi¨.

Рiвень НВ-1 Автентифiкацiя вузла включа¹ загальнi вимоги.

Рiвень НВ-2 Автентифiкацiя джерела даних включа¹ наступну вимогу: КЗЗ повинен використовувати захищенi механiзми для встановлення джерела кожного об'¹кта, що експорту¹ться та iмпорту¹ться.

Рiвень НВ-3 Автентифiкацiя з пiдтвердженням вклю- ча¹ наступнi вимоги:

•КЗЗ повинен використовувати захищенi механiзми для вста-

новлення джерела кожного об'¹кта, що експорту¹ться та iмпорту¹ться;

•використовуваний протокол автентифiкацi¨ повинен забезпечу-

вати можливiсть однозначного пiдтвердження джерела об'¹кта незалежною третьою стороною.

Автентифiкацiя вiдправника

Послуга автентифiкацiя вiдправника дозволя¹ забезпечити захист вiд вiдмови вiд авторства i однозначно встановити належнiсть певного об'¹кта певному користувачу, тобто той факт, що об'¹кт був створений або вiдправлений даним користувачем. Рiвнi дано¨ послуги ранжируються на пiдставi можливостi пiдтвердження результатiв перевiрки незалежною третьою стороною:

•базова автентифiкацiя вiдправника (ÍÀ-1);

•автентифiкацiя вiдправника з пiдтвердженням (ÍÀ-2).

318	Ðîçäië 5

Загальними для усiх рiвнiв вважаються наступнi вимоги:

•полiтика автентифiкацi¨ вiдправника, що реалiзу¹ться КЗЗ, по-

винна визначати множину властивостей i атрибутiв об'¹кта, що переда¹ться, користувача-вiдправника i iнтерфейсного процесу, а також процедури, якi дозволяли б однозначно встановити, що даний об'¹кт був вiдправлений (створений) певним користува- чем;

•встановлення належностi ма¹ виконуватися на пiдставi затвердженого протоколу автентифiкацi¨.

Необхiдна загальна умова: НИ-1.

Рiвень НА-1 Базова автентифiкацiя вiдправника

включа¹ загальнi вимоги i необхiдну загальну умову.

Рiвень НА-2 Автентифiкацiя вiдправника з пiдтвердженням включа¹ наступнi вимоги:

•додатково повиннi бути визначенi тi властивостi, атрибути i

процедури, якi можуть використовуватися для однозначного пiдтвердження належностi об'¹кта незалежною третьою стороною;

•використовуваний протокол автентифiкацi¨ повинен забезпечу-

вати можливiсть однозначного пiдтвердження належностi об'- ¹кта незалежною третьою стороною.

Автентифiкацiя отримувача

Послуга автентифiкацiя отримувача дозволя¹ забезпечити захист вiд вiдмови вiд одержання i дозволя¹ однозначно встановити факт одержання певного об'¹кта певним користувачем. Рiвнi дано¨ послуги ранжируються на пiдставi можливостi пiдтвердження результатiв перевiрки незалежною третьою стороною:

•базова автентифiкацiя отримувача (ÍÏ-1);

•автентифiкацiя отримувача з пiдтвердженням (НП-2). Загальними для усiх рiвнiв вважаються наступнi вимоги:

•полiтика автентифiкацi¨ одержувача, що реалiзу¹ться КЗЗ, по-

винна визначати множину властивостей i атрибутiв об'¹кта, що переда¹ться, користувача-одержувача i iнтерфейсного процесу, а також процедури, якi дозволяли б однозначно встановити, що даний об'¹кт був одержаний певним користувачем;

Стандартизованi моделi та методи оцiнки ефективностi захисту	319

•встановлення одержувача ма¹ виконуватися на пiдставi затвер-

дженого протоколу автентифiкацi¨. Необхiдна загальна умова: НИ-1.

Рiвень НП-1 Базова автентифiкацiя отримувача âêëþ-

ча¹ загальнi вимоги i необхiдну загальну умову.

Рiвень НП-2 Автентифiкацiя отримувача з пiдтвердженням включа¹ наступнi вимоги:

•додатково повиннi бути визначенi тi властивостi, атрибути i

процедури, якi можуть використовуватися незалежною третьою стороною для однозначного пiдтвердження факту одержання об'¹кта;

•використовуваний протокол автентифiкацi¨ повинен забезпе-

чувати можливiсть однозначного пiдтвердження незалежною третьою стороною факту одержання об'¹кта.

5.2.3Критерi¨ гарантiй безпеки НД ТЗI 2.5

5.2.3.1.Загальнi вiдомостi про критерi¨ гарантiй безпеки НД

ÒÇI 2.5

Критерi¨ гарантiй дозволяють оцiнити коректнiсть реалiзацi¨ послуг. Вони включають вимоги до архiтектури комплексу засобiв захисту, середовища розробки, послiдовностi розробки, випробування комплексу засобiв захисту, середовища функцiонування i експлуатацiйно¨ документацi¨. Таксономiя критерi¨в гарантiй наведена на рис. 5.5.

Вимоги до архiтектури забезпечують гарантi¨ того, що КЗЗ у змозi повнiстю реалiзувати полiтику безпеки.

Вимоги до середовища розробки забезпечують гарантi¨ того, що процеси розробки i супроводження оцiнювано¨ комп'ютерно¨ системи ¹ повнiстю керованими з боку розробника.

Вимоги до процесу проектування (послiдовностi розробки) забезпечують гарантi¨ того, що на кожнiй стадi¨ розробки (проектування) iсну¹ точний опис комп'ютерно¨ системи i реалiзацiя ком- п'ютерно¨ системи точно вiдповiда¹ вихiдним вимогам (полiтицi безпеки).

320	Ðîçäië 5

Ðèñ. 5.5. Таксономiя критерi¨в гарантiй реалiзацi¨ полiтики безпеки НД ТЗI 2.5

Вимоги до середовища функцiонування забезпечують гарантi¨ того, що комп'ютерна система поставля¹ться замовнику без несанкцiонованих модифiкацiй, а також iнсталю¹ться i iнiцiю¹ться замовником так, як це передбача¹ться розробником.

В критерiях НД ТЗI 2.5 вводиться сiм рiвнiв гарантiй (Г-1,...,Г- 7), якi ¹ i¹рархiчними. I¹рархiя рiвнiв гарантiй вiдбива¹ поступово наростаючу мiру впевненостi в тому, що реалiзованi в комп'ютернiй системi послуги дозволяють протистояти певним загрозам, що механiзми, якi ¨х реалiзують, в свою чергу коректно реалiзованi i можуть забезпечити очiкуваний споживачем рiвень захищеностi iнформацi¨ пiд час експлуатацi¨ комп'ютерно¨ системи.

Гарантi¨ повиннi забезпечуватися як в процесi розробки, так i в процесi оцiнки. В процесi розробки гарантi¨ забезпечуються дiями розробника щодо забезпечення правильностi (коректностi) розробки. В процесi оцiнки гарантi¨ забезпечуються шляхом перевiрки

Стандартизованi моделi та методи оцiнки ефективностi захисту	321

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

5.2.3.2. Рiвнi гарантiй безпеки НД ТЗI 2.5

Вимоги гарантiй для рiвня Г-1

Архiтектура.

КЗЗ повинен реалiзовувати полiтику безпеки. Всi його компоненти повиннi бути чiтко визначенi.

Середовище розробки.

Процес розробки.

Розробник повинен визначити всi стадi¨ житт¹вого циклу ком- п'ютерно¨ системи, розробити, запровадити i пiдтримувати в робо- чому станi документально оформленi методики сво¹¨ дiяльностi на кожнiй стадi¨. Мають бути документованi всi етапи кожно¨ стадi¨ житт¹вого циклу i ¨х граничнi вимоги.

Керування конфiгурацi¹ю.

Розробник повинен розробити, запровадити i пiдтримувати в робочому станi документованi методики щодо керування конфiгурацi¹ю комп'ютерно¨ системи на всiх стадiях ¨¨ житт¹вого циклу. Система керування конфiгурацi¹ю повинна забезпечувати керування внесенням змiн в апаратне забезпечення, програми постiйних запам'ятовуючих пристро¨в, вихiднi тексти, об'¹ктнi коди, тестове покриття i документацiю. Система керування конфiгурацi¹ю повинна гарантувати постiйну вiдповiднiсть мiж всi¹ю документацi¹ю i реалiзацi¹ю поточно¨ версi¨ КЗЗ.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

На стадi¨ розробки технiчного завдання Розробник повинен розробити функцiональнi специфiкацi¨ комп'ютерно¨ системи. Представленi функцiональнi специфiкацi¨ повиннi включати неформалiзований опис полiтики безпеки, що реалiзу¹ться КЗЗ. Полiтика безпеки повинна мiстити перелiк i опис послуг безпеки, що надаються КЗЗ.

Проект архiтектури.

322	Ðîçäië 5

На стадi¨ розробки ескiзного проекту Розробник повинен розробити проект архiтектури КЗЗ. Представлений проект повинен мiстити перелiк i опис компонентiв КЗЗ i функцiй, що реалiзуються ними. Повиннi бути описанi будь-якi використовуванi зовнiшнi послуги безпеки. Зовнiшнi iнтерфейси КЗЗ повиннi бути описанi в термiнах виняткiв, повiдомлень про помилки i кодiв повернення.

Стиль специфiкацi¨: неформалiзована.

Детальний проект.

На стадiях розробки технiчного проекту або робочого проекту Розробник повинен розробити детальний проект КЗЗ. Представлений детальний проект повинен мiстити перелiк всiх компонентiв КЗЗ i точний опис функцiонування кожного механiзму. Повиннi бути описанi призначення i параметри iнтерфейсiв компонентiв КЗЗ.

Стиль специфiкацi¨: неформалiзована.

Середовище функцiонування.

Розробник повинен представити засоби iнсталяцi¨, генерацi¨ i запуску комп'ютерно¨ системи, якi гарантують, що експлуатацiя комп'ютерно¨ системи почина¹ться з безпечного стану. Розробник повинен представити перелiк усiх можливих параметрiв конфiгурацi¨, якi можуть використовуватися в процесi iнсталяцi¨, генерацi¨ i запуску.

Документацiя.

Вимоги до документацi¨ ¹ загальними для всiх рiвнiв гарантiй. У виглядi окремих документiв або роздiлiв (пiдроздiлiв) iнших документiв розробник повинен подати опис послуг безпеки, що реалiзуються КЗЗ, настанови адмiнiстратору щодо послуг безпеки, настанови користувача щодо послуг безпеки.

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

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

Стандартизованi моделi та методи оцiнки ефективностi захисту	323

ти використанi для перiодично¨ оцiнки правильностi функцiонування КЗЗ, а також iнструкцi¨ щодо використання адмiнiстратором послуг безпеки для пiдтримки полiтики безпеки, прийнято¨ в органiзацi¨, що експлуату¹ комп'ютерно¨ системи.

Настанови користувачу щодо послуг безпеки мають мiстити iнструкцi¨ щодо використання функцiй безпеки звичайним користувачем (не адмiнiстратором).

Назва документiв (роздiлiв) не регламенту¹ться. Опис послуг безпеки може вiдрiзнятися для користувача i адмiнiстратора. Настанови адмiнiстратору i настанови користувачу можуть бути об'- ¹днанi в настанови з установлення i експлуатацi¨.

Випробування комплексу засобiв захисту.

Розробник повинен подати для перевiрки програму i методику випробувань, процедури випробувань усiх механiзмiв, що реалiзують послуги безпеки. Мають бути представленi аргументи для пiдтвердження достатностi тестового покриття.

Розробник повинен подати докази тестування у виглядi детального перелiку результатiв тестiв i вiдповiдних процедур тестування, з тим, щоб отриманi результати могли бути перевiренi шляхом повторення тестування.

Вимоги гарантiй для рiвня Г-2

Архiтектура.

Áåç çìií.

Середовище розробки.

Процес розробки.

Áåç çìií.

Керування конфiгурацi¹ю.

Áåç çìií.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Показ вiдповiдностi полiтицi безпеки.

Функцiональнi специфiкацi¨ повиннi включати модель полiтики безпеки.

324	Ðîçäië 5

Стиль специфiкацi¨: неформалiзована.

Проект архiтектури.

Додатково.

Показ вiдповiдностi моделi полiтики безпеки.

Детальний проект.

Додатково.

Показ вiдповiдностi проекту архiтектури.

Стиль специфiкацi¨: неформалiзована на весь КЗЗ.

Середовище функцiонування.

Áåç çìií.

Документацiя.

Áåç çìií.

Випробування комплексу засобiв захисту.

Додатково.

Розробник повинен усунути або нейтралiзувати всi знайденiслабкi мiсця i виконати повторне тестування КЗЗ для пiдтвердження того, що виявленi недолiки були усуненi i не з'явилися новiслабкi мiсця .

Вимоги гарантiй для рiвня Г-3

Архiтектура.

Додатково.

КЗЗ повинен складатися з добре визначених i максимально незалежних компонентiв. Кожний з компонентiв повинен бути спроектований вiдповiдно до принципу мiнiмуму повноважень.

Середовище розробки.

Процес розробки.

Додатково.

Розробник повинен описати стандарти кодування, яким необхiдно додержуватися в процесi реалiзацi¨, i повинен гарантувати, що всi вихiднi коди компiлюються вiдповiдно до цих стандартiв. Будь-яка з використовуваних пiд час реалiзацi¨ мов програмування ма¹ бути добре визначена. Всi залежнi вiд реалiзацi¨ параметри мов програмування або компiляторiв повиннi бути документованi.

Керування конфiгурацi¹ю.

Áåç çìií.

Стандартизованi моделi та методи оцiнки ефективностi захисту	325

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Додатково.

Стиль специфiкацi¨: частково формалiзована.

Проект архiтектури.

Додатково.

Стиль специфiкацi¨: частково формалiзована.

Детальний проект.

Áåç çìií.

Ðåàëiçàöiÿ.

Показ вiдповiдностi детальному проекту.

Розробник повинен подати вихiдний код частини КЗЗ.

Середовище функцiонування.

Додатково.

Повинна iснувати система технiчних, органiзацiйних i фiзичних заходiв безпеки, яка гаранту¹, що програмне i програмно-апаратне забезпечення КЗЗ, яке поставля¹ться Замовнику, точно вiдповiда¹ еталоннiй копi¨.

Документацiя.

Áåç çìií.

Випробування комплексу засобiв захисту.

Áåç çìií.

Вимоги гарантiй для рiвня Г-4

Архiтектура.

Додатково.

Критичнi для безпеки компоненти КЗЗ повиннi бути захищенi вiд не критичних для безпеки за рахунок використання механiзмiв захисту, якi надаються програмно-апаратними засобами бiльш низького рiвня.

Середовище розробки.

Процес розробки.

Додатково.

326	Ðîçäië 5

Розробник повинен розробити, запровадити i пiдтримувати в робочому станi документально оформленi методики забезпечення фiзично¨, технiчно¨, органiзацiйно¨ i кадрово¨ безпеки.

Керування конфiгурацi¹ю.

Система керування конфiгурацi¹ю повинна базуватися на автоматизованих засобах.

Система керування конфiгурацi¹ю також повинна використовуватися для генерацi¨ КЗЗ з вихiдного коду i облiку всiх змiн з появою нових версiй.

Система керування конфiгурацi¹ю повинна бути здатна видавати звiти про стан елементiв конфiгурацi¨.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Додатково.

Демонстрацiя вiдповiдностi полiтицi безпеки. Стиль специфiкацi¨: формалiзована.

Проект архiтектури.

Áåç çìií.

Детальний проект.

Додатково.

Стиль специфiкацiй: частково формалiзована.

Ðåàëiçàöiÿ.

Áåç çìií.

Середовище функцiонування.

Áåç çìií.

Документацiя.

Áåç çìií.

Випробування комплексу засобiв захисту.

Додатково.

Розробник повинен виконати тести з подолання механiзмiв захисту i довести, що КЗЗ вiдносно або абсолютно стiйкий до такого роду атак з боку розробника.

Стандартизованi моделi та методи оцiнки ефективностi захисту	327

Вимоги гарантiй для рiвня Г-5

Архiтектура.

Додатково.

З боку розробника мають бути вжитi зусилля, спрямованi на виключення з КЗЗ компонентiв, що не ¹ критичними для безпеки. Мають бути наведенi пiдстави для включення до КЗЗ будь-якого елемента, який не ма¹ вiдношення до захисту.

Розробка програмного забезпечення переважно ма¹ бути спрямована на мiнiмiзацiю складностi КЗЗ. КЗЗ ма¹ бути спроектований i структурований так, щоб використовувати повний i концептуально простий механiзм захисту з точно визначеною семантикою. Цей механiзм повинен вiдiгравати центральну роль в реалiзацi¨ внутрiшньо¨ структури КЗЗ. Пiд час розробки КЗЗ значною мiрою повиннi бути задiянi такi пiдходи як модульнiсть побудови i приховання (локалiзацiя) даних.

Середовище розробки.

Процес розробки.

Áåç çìií.

Керування конфiгурацi¹ю.

Áåç çìií.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Áåç çìií.

Проект архiтектури.

Додатково.

Демонстрацiя вiдповiдностi моделi полiтики безпеки.

Детальний проект.

Áåç çìií.

Ðåàëiçàöiÿ.

Додатково.

Розробник повинен подати вихiдний код всього КЗЗ.

Середовище функцiонування.

Áåç çìií.

Документацiя.

328	Ðîçäië 5

Áåç çìií.

Випробування комплексу засобiв захисту.

Áåç çìií.

Вимоги гарантiй для рiвня Г-6

Архiтектура.

Áåç çìií.

Середовище розробки.

Процес розробки.

Áåç çìií.

Керування конфiгурацi¹ю.

Додатково.

Повинна використовуватися система заходiв технiчно¨, фiзи- чно¨, органiзацiйно¨ i кадрово¨ безпеки, спрямованих на захист усiх засобiв i матерiалiв, використовуваних для генерацi¨ КЗЗ, вiд несанкцiоновано¨ модифiкацi¨ або руйнування.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Áåç çìií.

Проект архiтектури.

Додатково.

Доказ вiдповiдностi моделi полiтики безпеки. Стиль специфiкацi¨: формалiзована.

Детальний проект.

Додатково.

Демонстрацiя вiдповiдностi проекту архiтектури.

Ðåàëiçàöiÿ.

Áåç çìií.

Середовище функцiонування.

Додатково.

Для пiдтримки вiдповiдностi мiж КЗЗ, що поставля¹ться замовнику, i еталонною копi¹ю повинна iснувати система керування розповсюдженням захищено¨ комп'ютерно¨ системи.

Документацiя.

Стандартизованi моделi та методи оцiнки ефективностi захисту	329

Áåç çìií.

Випробування комплексу засобiв захисту.

Áåç çìií.

Вимоги гарантiй для рiвня Г-7

Архiтектура.

Áåç çìií.

Середовище розробки.

Процес розробки.

Áåç çìií.

Керування конфiгурацi¹ю.

Áåç çìií.

Послiдовнiсть розробки.

Функцiональнi специфiкацi¨ (полiтика безпеки).

Áåç çìií.

Функцiональнi специфiкацi¨ (модель полiтики безпеки).

Áåç çìií.

Проект архiтектури.

Áåç çìií.

Детальний проект.

Додатково.

Доказ вiдповiдностi проекту архiтектури. Стиль специфiкацi¨: формалiзована.

Ðåàëiçàöiÿ.

Додатково.

Демонстрацiя вiдповiдностi детальному проекту.

Розробник повинен подати вихiдний код всiх бiблiотек часу виконання.

Середовище функцiонування.

Áåç çìií.

Документацiя.

Áåç çìií.

Випробування комплексу засобiв захисту.

Áåç çìií.

330	Ðîçäië 5

5.2.4Функцiональнi профiлi захищеностi iнформацi¨ НД ТЗI 2.5

Необхiднiсть створення методики, за якою можна було би створити класи безпеки комп'ютерних систем, як в Жовтогарячiй книзi призвела до втiлення концепцi¨ функцiональних профiлiв безпеки в бiльш пiзнiх стандартах безпеки.

Ó ÍÄ ÒÇI 2.5 [22] встановлються принципи класифiкацi¨ автоматизованих систем i утворення стандартних функцiональних профiлiв захищеностi оброблювано¨ iнформацi¨ вiд несанкцiонованого доступу.

5.2.4.1. Класифiкацiя автоматизованих систем у НД ТЗI 2.5

Мета введення класифiкацi¨ АС i стандартних функцiональних профiлiв захищеностi полегшення задачi спiвставлення вимог до КЗЗ обчислювально¨ системи АС з характеристиками АС.

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

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

Клас 1 одномашинний однокористувачевий комплекс, який обробля¹ iнформацiю однi¹¨ або кiлькох категорiй конфiденцiйностi.

Iстотнi особливостi:

•в кожний момент часу з комплексом може працювати тiльки

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

Стандартизованi моделi та методи оцiнки ефективностi захисту	331

мати однаковi повноваження (права) щодо доступу до iнформацi¨, яка обробля¹ться;

•технiчнi засоби (носi¨ iнформацi¨ i засоби вводу/виводу) з точки зору захищеностi вiдносяться до однi¹¨ категорi¨ i всi можуть

використовуватись для збереження i/або вводу/виводу всi¹¨ iнформацi¨.

Приклад автономна персональна ЕОМ, доступ до яко¨ контролю¹ться з використанням органiзацiйних заходiв.

Клас 2 локалiзований багатомашинний багатокористуваче- вий комплекс, який обробля¹ iнформацiю рiзних категорiй конфiденцiйностi.

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

Приклад ЛОМ.

Клас 3 розподiлений багатомашинний багатокористувачевий комплекс, який обробля¹ iнформацiю рiзних категорiй конфiденцiйностi.

Iстотна вiдмiна вiд попереднього класу необхiднiсть передачi iнформацi¨ через незахищене середовище або, в загальному випадку, наявнiсть вузлiв, що реалiзують рiзну полiтику безпеки

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

В межах кожного класу АС класифiкуються на пiдставi вимог до забезпечення певних властивостей iнформацi¨. З точки зору безпеки iнформацiя характеризу¹ться трьома властивостями: конфiденцiйнiстю, цiлiснiстю i доступнiстю. В зв'язку з цим, в кожному класi АС видiляються такi пiдкласи:

•автоматизована система, в якiй пiдвищенi вимоги до забез-

печення конфiденцiйностi оброблювано¨ iнформацi¨ (пiдкласи х.К);

•автоматизована система, в якiй пiдвищенi вимоги до забезпечення цiлiсностi оброблювано¨ iнформацi¨ (пiдкласи х.Ц);

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

•автоматизована система, в якiй пiдвищенi вимоги до забезпечення конфiденцiйностi i цiлiсностi оброблювано¨ iнформацi¨

332	Ðîçäië 5

(пiдкласи х.КЦ);

•автоматизована система, в якiй пiдвищенi вимоги до забезпе-

чення конфiденцiйностi i доступностi оброблювано¨ iнформацi¨ (пiдкласи х.КД);

•автоматизована система, в якiй пiдвищенi вимоги до забез-

печення цiлiсностi i доступностi оброблювано¨ iнформацi¨ (пiдкласи х.ЦД).

•автоматизована система, в якiй пiдвищенi вимоги до забезпе- чення конфiденцiйностi, цiлiсностi i доступностi оброблювано¨

iнформацi¨ (пiдкласи х.КЦД).

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

Така класифiкацiя корисна для полегшення вибору перелiку функцiй, якi повинен реалiзовувати КЗЗ ОС, проектовано¨ або iснуючо¨ АС. Цей пiдхiд дозволя¹ мiнiмiзувати витрати на поча- ткових етапах створення КСЗI АС. Проте слiд визнати, що для створення КЗЗ, який найповнiше вiдповiда¹ характеристикам i вимогам до конкретно¨ АС, необхiдно проведення в повному обсязi аналiзу загроз i оцiнки ризикiв.

5.2.4.2. Функцiональнi профiлi захищеностi

Визначення i призначення

Стандартний функцiональний профiль захищеностi явля¹ собою перелiк мiнiмально необхiдних рiвнiв послуг, якi повинен реалiзовувати КЗЗ обчислювально¨ системи АС, щоб задовольняти певнi вимоги щодо захищеностi iнформацi¨, яка обробля¹ться в данiй АС. Стандартнi функцiональнi профiлi будуються на пiдставi iснуючих вимог щодо захисту певно¨ iнформацi¨ вiд певних загроз i

Стандартизованi моделi та методи оцiнки ефективностi захисту	333

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

Для стандартних функцiональних профiлiв захищеностi не вимага¹ться нi зв'язано¨ з ними полiтики безпеки, нi рiвня гарантiй, хоч ¨х наявнiсть i допуска¹ться в разi необхiдностi. Полiтика безпеки КС, що реалiзу¹ певний стандартний профiль, ма¹ бути "успадкована"з вiдповiдних документiв, що встановлюють вимоги до порядку обробки певно¨ iнформацi¨ в АС. Так, один i той же профiль захищеностi може використовуватись для опису функцiональних вимог з захисту оброблювано¨ iнформацi¨ i для ОС, i для СУБД, в той час, як ¨х полiтика безпеки, зокрема визначення об'¹ктiв, буде рiзною.

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

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

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

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

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

Версiя може служити, зокрема, для вказiвки на пiдсилення певно¨ послуги всерединi профiлю. Наприклад, нарощування можли-

334	Ðîçäië 5

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

Перелiк функцiональних послуг безпеки та рiвнiв гарантiй, ¨х структура i семантичне позначення наведенi в НД ТЗI Критерi¨ оцiнки захищеностi iнформацi¨ в комп'ютерних системах вiд несанкцiонованого доступу [21].

Стандартнi профiлi

Ó [22, розд. 7] наведенi стандартнi профiлi захищеностi для рiзних класiв АС, що описують вимоги до КЗЗ обчислювальних систем, якi входять до складу цих АС. Оскiльки класифiкацiя АС достатньо умовна, той факт, що деякий профiль не потрапив до наведеного нижче перелiку, не означа¹, що вiн некоректний або гiрший за перелiченi. Наведенi профiлi вiдповiдають тим видам КС, потреба в яких найактуальнiша.

Даний роздiл явля¹ собою довiдник щодо функцiональних профiлiв захищеностi для рiзних класiв АС. Багато профiлiв наведенi лише для повноти класифiкацi¨, а не для практичного використання. Особливо це стосу¹ться профiлiв, що мiстять послуги, якi забезпечують захист тiльки вiд одного типу загроз.

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

Стандартизованi моделi та методи оцiнки ефективностi захисту	335

5.3Модель, що покладена в основу мiжнародного стандарту ISO/IEC 15408

5.3.1Основнi положення загальних критерi¨в безпеки iнформацiйних технологiй

5.3.1.1. Мета розробки, основнi положення та складЗагальних критерi¨в

Загальнi критерi¨ безпеки iнформацiйних технологiй

[Common Criteria for Information Technology Security Evaluation (CCITSE)] стандарт iнформацiйно¨ безпеки [35], що узагальню¹ змiст i досвiд використання Жовтогарячо¨ книги .

В ньому розвиненi вропейськi критерi¨ , втiлена в реальнi структури концепцiя типових профiлiв захисту Федеральних критерi¨в ÑØÀ i âiäïîâiäíî äî Канадських критерi¨в представлена однакова основа для формулювання розробниками, користувачами та оцiнювачами iнформацiйних технологiй (експертами з квалiфiкацi¨) вимог, метрик i гарантiй безпеки.

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

До складу Загальних критерi¨в входять три основнi частини (рис. 5.6):

частина 1 Уявлення та загальна модель [Part 1: Introduction and general model];

частина 2 Вимоги до функцiй безпеки [Part 1: Security functional requirements];

частина 3 Вимоги гарантiй безпеки [Part 1: Security assurance requirements].

За межi стандарту винесена частина 4 Напередвизначенi профiлi захисту , iз-за необхiдностi постiйного поповнення ката-

336	Ðîçäië 5

Ðèñ. 5.6. Структура Загальних критерi¨в безпеки iнформацiйних технологiй

логу профiлiв захисту.

Основними компонентами безпеки Загальних критерi¨в ¹:

•потенцiйнi загрози безпецi та завдання захисту;

•полiтика безпеки;

•продукт iнформацiйних технологiй;

•профiль захисту;

•проект захисту;

•функцiональнi вимоги безпеки;

•вимоги гарантiй безпеки;

квалiфiкування рiвня безпеки

Стандартизованi моделi та методи оцiнки ефективностi захисту	337

• рiвнi гарантiй.

Стандарт Загальних критерi¨в опису¹ тiльки загальну схему проведення квалiфiкацiйного аналiзу та сертифiкацi¨, але не регламенту¹ процедуру ¨х здiйснення. Питаннями методологi¨ квалiфiкацiйного аналiзу та сертифiкацi¨ присвячений окремий документ авторiв Загальних критерi¨в Загальна методологiя оцiнки безпеки iнформацiйних технологiй [Common Methodology for Information Technology Security Evaluation (CMITSE)], який ¹ додатком до стандарту.

Êâàëiôiêàöiéíèé àíàëiç [evaluation] це аналiз обчислювально¨ системи з метою визначення рiвня ¨¨ захищеностi та вiдповiдностi вимогам безпеки на основi критерi¨в стандарту iнформацiйно¨ безпеки. Iнша назва

(ðèñ. 5.7).

Ðèñ. 5.7. Êâàëiôiêàöiéíèé àíàëiç

Згiдно Загальних критерi¨в квалiфiкацiйний аналiз може здiйснюватися як паралельно з розробленням IТ-продукту, так i пiсля ¨¨ завершення.

Для проведення квалiфiкацiйного аналiзу розробник продукту

338	Ðîçäië 5

повинен надати наступнi матерiали:

•профiль захисту;

•проект захисту;

•рiзноманiтнi об рунтування i пiдтвердження властивостей та можливостей IТ-продукту, одержанi розробником;

•ñàì IТ-продукт;

•додатковi вiдомостi, одержанi шляхом проведення рiзноманi-

тних незалежних експертиз.

Процес квалiфiкацiйного аналiзу включа¹ три стадi¨:

•аналiз профiлю захисту на предмет його повноти, несупере-

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

•аналiз проекту захисту на предмет його вiдповiдностi вимогам

профiлю захисту, а також повноти, несуперечностi, реалiзованостi i можливостi використання у виглядi еталона при аналiзi IТ-продукту;

•àíàëiç IТ-продукту на предмет вiдповiдностi проекту захисту.

Результатом квалiфiкацiйного аналiзу ¹ висновок про те, що пiдданий аналiзу IТ-продукт вiдповiда¹ представленому проекту захисту.

5.3.1.2. Потенцiйнi загрози безпецi та типовi завдання захисту

Загрози безпецi обчислювально¨ системи впливи на об- числювальну систему, якi прямо або побiчно можуть нанести шкоду ¨¨ безпецi. Розробники вимог безпеки та засобiв захисту видiляють три види загроз:

•загрози порушення конфiденцiйностi iнформацi¨;

•загрози порушення цiлiсностi iнформацi¨;

•загрози порушення працездатностi системи (вiдмови в обслуговуваннi).

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

Загрози порушення цiлiсностi загрози безпецi обчислювально¨ системи, що полягають у спотвореннi або змiнi неавторизо-

Завдання захисту

наступним чином:

Стандартизованi моделi та методи оцiнки ефективностi захисту	339

ваним користувачем iнформацi¨, що зберiга¹ться або переда¹ться. Цiлiснiсть iнформацi¨ може бути порушена як зловмисником, так i в результатi об'¹ктивних впливiв iз сторони середовища експлуатацi¨ системи. Найбiльш актуальна ця загроза для систем передавання iнформацi¨ комп'ютерних мереж i систем телекомунiкацi¨.

Загрози порушення працездатностi загрози безпецi об- числювально¨ системи, спрямованi на створення ситуацiй, коли в результатi навмисних дiй понижу¹ться працездатнiсть обчислювально¨ системи, або ¨¨ ресурси стають недоступними.

в Загальних критерiях декларуються

•захист вiд загроз порушення конфiденцiйностi (несанкцiонова-

ного одержання) iнформацi¨ з усiх каналiв ¨¨ витоку, особливо за рахунок каналiв ПЕМВН i прихованих (та¹мних) каналiв зв'язку;

•захист вiд загроз порушення цiлiсностi (несанкцiонованого змiнювання iнформацi¨);

•захист вiд загроз порушення доступностi iнформацi¨ (несан-

кцiонованого або випадкового обмеження iнформацi¨ та ресурсiв само¨ системи);

•захист вiд загроз аудитовi системи (наприклад, загрози несан-

кцiонованих вторгнень у систему, манiпуляцiй з протоколами обмiну та аудиту, iз загальносистемним програмним забезпече- нням).

5.3.1.3. Полiтика безпеки

Полiтика безпеки [security policy] сукупнiсть законiв, норм i правил, що регламентують порядок оброблення, захисту i розповсюдження iнформацi¨ комп'ютерно¨ системи.

В системах зв'язку полiтика безпеки ¹ частиною загально¨ полiтики безпеки оператора зв'язку i може включати, зокрема, положення державно¨ полiтики у галузi захисту iнформацi¨.

Для кожно¨ системи (пiдсистеми) зв'язку полiтика безпеки може бути iндивiдуальною i може залежати вiд технологi¨ передавання, оброблення та зберiгання iнформацi¨, що реалiзу¹ться, особливостей системи зв'язку, середовища експлуатацi¨ i вiд багатьох iн-

340	Ðîçäië 5

ших факторiв. Полiтика повинна визначати ресурси системи зв'язку, якi потребують захисту, зокрема, встановлювати категорi¨ iнформацi¨, яка переда¹ться, оброблю¹ться та зберiга¹ться в системi. Мають бути сформульованi основнi загрози для системи зв'язку, персоналу, iнформацi¨ рiзних категорiй i вимоги до захисту вiд цих загроз.

Складовими частинами загально¨ полiтики безпеки в системi зв'язку мають бути полiтики забезпечення конфiденцiйностi, цiлiсностi i доступностi iнформацi¨, що переда¹ться, оброблю¹ться i зберiга¹ться. Вiдповiдальнiсть персоналу за виконання положень полiтики безпеки ма¹ бути персонiфiкована.

Частина полiтики безпеки, яка регламенту¹ правила доступу користувачiв i процесiв системи зв'язку, склада¹ правила розмежування доступу.

5.3.1.4. Продукт iнформацiйних технологiй

Продукт iнформацiйних технологiй (IТ-продукт) сукупнiсть апаратних i (або) програмних засобiв, яка поставля¹ться кiнцевому споживачевi як готовий до використання засiб оброблення iнформацi¨. Сукупнiсть IТ-продуктiв об'¹дну¹ться в функцiонально закiнчений комплекс (продукт) для вирiшення конкретно¨ прикладно¨ завдання в системi оброблення iнформацi¨.

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

Навпаки, система оброблення iнформацi¨ розроблю¹ться вузько спецiалiзованою для вирiшення конкретних прикладних задач i пiд конкретнi вимоги споживачiв, що дозволя¹ у повнiй мiрi враховувати специфiку впливу зi сторони конкретного середовища експлуатацi¨. Саме тому IТ-продукт, а не система оброблення iнформацi¨, деклару¹ться в стандартi як унiверсальний компонент безпеки.

Стандартизованi моделi та методи оцiнки ефективностi захисту	341

5.3.1.5. Профiль захисту

Профiль захисту [Protection Pro le (PP)] спецiальний нормативний документ, що регламенту¹ сукупнiсть завдань захисту, функцiональних вимог безпеки, вимог гарантiй безпеки та ¨хн¹ обрунтування. Профiль захисту визнача¹ вимоги безпеки до певно¨ категорi¨ IТ-продуктiв, не уточнюючи методи i засоби ¨х реалiзацi¨. За допомогою профiлю захисту споживачi формують сво¨ вимоги до розробникiв IТ-продуктiв.

Профiль захисту мiстить вступ, опис IТ-продукту, середовище експлуатацi¨, завдання захисту, вимоги безпеки, додатковi вiдомостi, об рунтування (рис. 5.8).

Профiль захисту: вступ [PP introduction] роздiл профiлю захисту, який мiстить всю iнформацiю для пошуку профiлю захисту в бiблiотецi профiлiв. Вступ склада¹ться з iдентифiкатора профiлю захисту та огляду змiсту. Iдентифiкатор профiлю захисту явля¹ собою унiкальне iм'я для його пошуку серед подiбних йому профiлiв i позначення посилань на нього.

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

Профiль захисту: опис IТ-продукту [TOE description] роздiл профiлю захисту, який мiстить коротку характеристику IТпродукту, призначення, принцип роботи, методи використання i т. iн. Ця iнформацiя не пiдляга¹ квалiфiкацiйному аналiзовi та сертифiкацi¨, але пода¹ться розробникам i експертам для пояснення вимог безпеки i визначення ¨хньо¨ вiдповiдностi до завдань, що вирiшуються за допомогою IТ-продукту.

Профiль захисту: середовище експлуатацi¨ [TOE security environment] роздiл профiлю захисту, що мiстить опис усiх аспектiв функцiонування IТ-продукту, зв'язаних з безпекою. В середовищi експлуатацi¨ описуються умови експлуатацi¨, загрози безпецi, полiтика безпеки.

Опис умов експлуатацi¨ IТ-продукту повинен мiстити вичерпну характеристику середовища його експлуатацi¨ з точки зору безпеки, в тому числi обмеження на умови його застосування.

Опис загроз безпецi, що дiють у середовищi експлуатацi¨, яким

342	Ðîçäië 5

Ðèñ. 5.8. Структура профiлю захисту

повинен протистояти захист IТ-продукту. Для кожно¨ загрози повинно бути вказане ¨¨ джерело, метод i об'¹кт впливу.

Опис полiтики безпеки повинен визначати i, при необхiдностi, пояснювати правила полiтики безпеки, яка повинна бути реалiзована в IТ-продуктi.

Профiль захисту: завдання захисту [security objectives] ðîç-

Профiль захисту: об рунтування

Стандартизованi моделi та методи оцiнки ефективностi захисту	343

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

Завдання захисту IТ-продукту повиннi визначати та регламентувати потреби в протидi¨ потенцiйним загрозам безпецi i (або) у реалiзацi¨ полiтики безпеки.

Iншi завдання захисту повиннi регламентувати потреби в протидi¨ потенцiйним загрозам безпецi i (або) у реалiзацi¨ полiтики безпеки iнших компонент комп'ютерно¨ системи, що не вiдносяться до сфери iнформацiйних технологiй.

Профiль захисту: вимоги безпеки [IT security requirements] - роздiл профiлю захисту, що мiстить вимоги, яким повинен задовольняти IТ-продукт для вирiшення завдань захисту (типових, спецiальних i т. iн.). В роздiлi виставляються функцiональнi вимоги безпеки, вимоги гарантiй безпеки, вимоги до середовища експлуатацi¨.

Функцiональнi вимоги повиннi мiстити тiльки типовi вимоги, передбаченi тiльки вiдповiдними роздiлами Загальних критерi- ¨в . Необхiдно забезпечити такий рiвень деталiзацi¨ вимог, який дозволя¹ продемонструвати ¨х вiдповiднiсть до завдань захисту. Функцiональнi вимоги можуть дозволяти або забороняти використання конкретних методiв i засобiв захисту.

Вимоги гарантiй мiстять посилання на типовi вимоги рiвнiв гарантiй Загальних критерi¨в , проте допускають i визначення додаткових вимог гарантiй.

Вимоги до середовища експлуатацi¨ ¹ необов'язковими i можуть мiстити функцiональнi вимоги та вимоги гарантiй, яким повиннi задовольняти компоненти iнформацiйних технологiй, що складають середовище експлуатацi¨ IТ-продукту. На вiдмiну вiд попереднiх роздiлiв, використання типових вимог Загальних критерi¨в ¹ бажаними, але не обов'язковими.

Профiль захисту: додатковi вiдомостi [PP application notes] - необов'язковий роздiл профiлю захисту, що мiстить áóäü-ÿêó додаткову iнформацiю, корисну для проектування, розробки, квалiфiкацiйного аналiзу та сертифiкацi¨ IТ-продукту.

[rationale] ðîçäië ïðîôiëþ

344	Ðîçäië 5

захисту, який повинен демонструвати, що профiль захисту мiстить повну й зв'язну множину вимог i що IТ-продукт, який задовольня¹ ¨м, буде протистояти загрозам безпецi середовища експлуатацi¨. Роздiл склада¹ться з об рунтування завдань захисту та об рунтування вимог безпеки.

Об рунтування завдань захисту повинно демонструвати, що завдання, якi пропонуються у профiлi, вiдповiдають параметрам середовища експлуатацi¨, а ¨х вирiшення дозволить ефективно протистояти загрозам безпецi i реалiзувати полiтику безпеки.

Об рунтування вимог безпеки показу¹, що вимоги безпеки дозволяють ефективно вирiшувати завдання захисту, оскiльки:

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

•вимоги безпеки ¹ пов'язаними, тобто не суперечать, а вза¹мно

пiдсилюються; вибiр вимог ¹ виправданим (особливо це вiдноситься до додаткових вимог);

•вибраний набiр функцiональних вимог i рiвень гарантiй вiдпо-

вiдають завданням захисту.

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

5.3.1.6. Проект захисту

Проект захисту [Security Target (ST)] нормативний документ, який включа¹ вимоги та завдання захисту IТ-продукту, а також опису¹ рiвень функцiональних можливостей, реалiзованих у ньому засобiв захисту, ¨х об рунтування i пiдтвердження ступеню ¨хнiх гарантiй. Проект захисту, з однi¹¨ сторони ¹ вiдправною точкою для розробника системи, а з iншо¨ явля¹ собою еталон системи в ходi квалiфiкацiйного аналiзу.

Проект захисту мiстить вступ, опис IТ-продукту, середовище експлуатацi¨, завдання захисту, вимоги безпеки, загальнi специфiкацi¨ IТ-продукту, заявку на вiдповiднiсть профiлю захисту, обрунтування (рис. 5.9). Багато роздiлiв проекту захисту спiвпада-

Стандартизованi моделi та методи оцiнки ефективностi захисту	345

Ðèñ. 5.9. Структура проекту захисту

346	Ðîçäië 5

ють iз однойменними роздiлами профiлю захисту.

Проект захисту: вступ [ST introduction] роздiл проекту захисту, який мiстить iнформацiю, необхiдну для iдентифiкацi¨ проекту захисту, визначення призначення, а також огляд його змiсту та заявку на вiдповiднiсть вимогам Загальних критерi¨в .

Iдентифiкатор проекту захисту унiкальне iм'я проекту захисту для його пошуку та iдентифiкацi¨, а також вiдповiдного IТпродукту.

Огляд змiсту проекту захисту достатньо докладна анотацiя проекту захисту, що дозволя¹ споживачам визначати придатнiсть IТ-продукту для вирiшення завдань.

Заявка на вiдповiднiсть Загальним критерiям опис усiх властивостей IТ-продукту, що пiдлягають квалiфiкацiйному аналiзу на основi Загальних критерi¨в .

Проект захисту: опис IТ-продукту [TOE description] роздiл проекту захисту, який мiстить коротку характеристику IТпродукту, призначення, принцип роботи, методи використання i т. iн. Ця iнформацiя не пiдляга¹ квалiфiкацiйному аналiзовi та сертифiкацi¨, але пода¹ться розробникам i експертам для пояснення вимог безпеки i визначення ¨хньо¨ вiдповiдностi завданням, що вирiшуються за допомогою IТ-продукту.

Проект захисту: середовище експлуатацi¨ [TOE security environment] - роздiл проекту захисту, що мiстить опис усiх аспектiв функцiонування IТ-продукту, зв'язаних з безпекою. В середовищi експлуатацi¨ описуються умови експлуатацi¨, загрози безпецi, полiтика безпеки.

Опис умов експлуатацi¨ IТ-продукту повинен мiстити вичерпну характеристику середовища його експлуатацi¨ з точки зору безпеки, в тому числi обмеження на умови його застосування.

Опис загроз безпецi, що дiють у середовищi експлуатацi¨, яким повинен протистояти захист IТ-продукту. Для кожно¨ загрози повинно бути вказане ¨¨ джерело, метод i об'¹кт впливу.

Опис полiтики безпеки повинен визначати i, при необхiдностi, пояснювати правила полiтики безпеки, яка повинна бути реалiзована в IТ-продуктi.

Проект захисту: завдання захисту [security objectives] роздiл проекту захисту, що вiдобража¹ потреби користувачiв у про-

Стандартизованi моделi та методи оцiнки ефективностi захисту	347

тидi¨ потенцiйним загрозам безпецi i (або) реалiзацi¨ полiтики безпеки. До складу задач захисту входять завдання захисту IТпродукту та iншi завдання захисту.

Завдання захисту IТ-продукту повиннi визначати i регламентувати потреби в протидi¨ потенцiйним загрозам безпецi i (або) у реалiзацi¨ полiтики безпеки.

Iншi завдання захисту повиннi регламентувати потреби в протидi¨ потенцiйним загрозам безпецi i (або) у реалiзацi¨ полiтики безпеки iнших компонент комп'ютерно¨ системи, що не вiдносяться до сфери iнформацiйних технологiй.

Проект захисту: вимоги безпеки [IT security requirements]роздiл проекту захисту, що мiстить вимоги безпеки до IТпродукту, якими керувався виробник у ходi його розроблення. Цей роздiл дещо вiдрiзня¹ться вiд аналогiчного роздiлу профiлю захисту.

Роздiл функцiональних вимог безпеки до IТ-продукту на вiдмiну вiд вiдповiдного роздiлу профiлю захисту допуска¹ використання крiм типових вимог Загальних критерi¨в i iнших, специфiчних для даного продукту та середовища його експлуатацi¨. При описi таких спецiальних вимог необхiдно зберiгати стиль Загальних критерi¨в i забезпечувати властиву ¨м ступiнь деталiзацi¨.

Роздiл вимог гарантiй безпеки може включати рiвнi гарантiй, не передбаченi в Загальних критерiях . В даному випадку опис рiвня гарантiй повинен бути чiтким, несуперечливим i мати ступiнь деталiзацi¨, що допуска¹ його використання в ходi квалiфiкацiйного аналiзу. При цьому бажано використати стиль i деталiзацi¨ опису рiвнiв гарантiй, прийнятi в Загальних критерiях .

Проект захисту: загальнi специфiкацi¨ IТ-продукту [TOE summary speci cation] роздiл проекту захисту, який опису¹ механiзми реалiзацi¨ завдань захисту за допомогою визначення багаторiвневих специфiкацiй засобiв захисту у вiдповiдностi до функцiональних вимог безпеки та вимог гарантiй безпеки, що пред'являються. Складаються зi специфiкацiй функцiй захисту та специфiкацiй рiвня гарантiй.

Проект захисту: заявка на вiдповiднiсть профiлю захисту

[PP claims] необов'язковий роздiл проекту захисту, який мiстить матерiали, необхiднi для пiдтвердження заявки. Для кожного про-

348	Ðîçäië 5

фiлю захисту, на реалiзацiю якого претенду¹ проект захисту, цей роздiл повинен мiстити посилання на профiль захисту, вiдповiднiсть профiлю захисту, удосконалення профiлю захисту.

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

Удосконалення профiлю захисту вiдобража¹ можливостi IТпродукту, якi виходять за рамки завдань захисту та вимог, встановлених у профiлi захисту.

Проект захисту: об рунтування [rationale] роздiл проекту захисту, який повинен показувати, що проект захисту мiстить повну i зв'язну множину вимог, що IТ-продукт, який реалiзу¹ ¨х, буде ефективно протистояти загрозам безпецi. Крiм того, об рунтування мiстить пiдтвердження заявлено¨ вiдповiдностi профiлю захисту. Роздiл деталiзу¹ться у наступному.

Об рунтування завдань захисту повинно демонструвати, що завдання захисту, заявленi в проектi захисту, вiдповiдають властивостям середовища експлуатацi¨, тобто ¨х вирiшення дозволить ефективно протидiяти загрозам безпецi i реалiзувати вибрану пiд них полiтику безпеки.

Об рунтування вимог безпеки показу¹, що виконання цих вимог дозволя¹ вирiшити завдання захисту тому, що:

•сукупнiсть функцiональних вимог безпеки та вимог гарантiй

безпеки, а також умов експлуатацi¨ IТ-продукту вiдповiдають завданням захисту;

•усi вимоги безпеки ¹ несуперечливими i вза¹мно пiдсилюють одна одну;

•вибiр вимог ¹ оправданим;

•рiвень функцiональних можливостей засобiв захисту вiдповiда¹

завданням захисту.

Об рунтування загальних специфiкацiй IТ-продукту повинно демонструвати, що засоби захисту та методи забезпечення ¨хнiх гарантiй вiдповiдають вимогам, що пред'являються, оскiльки:

Стандартизованi моделi та методи оцiнки ефективностi захисту	349

•сукупнiсть засобiв захисту задовольня¹ функцiональним вимогам;

•необхiдний рiвень безпеки та надiйностi захисту забезпечу¹ться засобами, що запропонованi;

•заходи, спрямованi на забезпечення гарантiй реалiзацi¨ фун-

кцiональних вимог, вiдповiдають вимогам гарантiй.

Об рунтування вiдповiдностi профiлю захисту показу¹, що вимоги проекту захисту пiдтримують всi вимоги профiлю захисту. Для цього повинно бути показано, що:

•усi удосконалення завдань захисту порiвняно з профiлем за-

хисту реалiзованi коректно i в напрямку ¨хнього розвитку та конкретизацi¨;

•усi удосконалення вимог безпеки порiвняно з профiлем захисту

реалiзованi коректно i в напрямку ¨хнього розвитку та конкретизацi¨;

•усi завдання захисту профiлю захисту успiшно реалiзованi i всi вимоги профiлю захисту вдоволенi;

•нiякi додатково введенi в проект захисту спецiальнi завдання захисту та вимоги безпеки не суперечать профiлю захисту.

5.3.2 Функцiональнi вимоги до засобiв захисту

5.3.2.1. Загальна характеристика ФВБ

Функцiональнi вимоги безпеки (ФВБ) [security functional requirements] вимоги безпеки, якi в Загальних критерiях регламентують функцiонування компонентiв IТ-продукту, що забезпечують безпеку, i визначають можливостi засобiв захисту. ФВБ декларуються у виглядi добре розроблено¨ формально¨ структури. Набiр ФВБ узагальню¹ усi iснуючi ранiше стандарти iнформацiйно¨ безпеки i вiдрiзня¹ться всеосяжною повнотою i найдокладнiшою деталiзацi¹ю. ФВБ роздiленi на 11 класiв функцiональних вимог безпеки i 67 роздiлiв функцiональних вимог. Опис кожно¨ вимоги буду¹ться за наступною схемою (рис. 5.10):

•назва [component identi cation], що мiстить унiкальну назву ви-

моги, яка використову¹ться для посилань на не¨ iз профiлю i проекту захисту;

350	Ðîçäië 5

Ðèñ. 5.10. Структура функцiональних вимог безпеки

Стандартизованi моделi та методи оцiнки ефективностi захисту	351

•змiст вимоги [functional elements], де проводиться основна дум-

ка про те, що функцiональний склад вимоги Загальнi критерi¨ дозволяють використовувати тiльки без змiн, що забезпечу¹ ¨х стандартизацiю;

•сполученi вимоги [dependencies], що ¹ необов'язковим пунктом,

який мiстить список вимог рiзних роздiлiв i класiв, виконання яких розгляда¹ться як необхiдна попередня умова для реалiзацi¨ дано¨ вимоги.

Êëàñ ÔÂÁ [functional class] в Загальних критерiях верх-

нiй рiвень формально¨ структури функцiональних вимог безпеки. Мiстить наступнi елементи:

•назву класу [class name];

•опис класу [class introduction];

•ðîçäiëè ÔÂÁ [functional families].

Функцiональнi вимоги розподiленi на 11 класiв ФВБ (рис. 5.11):

•аудит;

•причетнiсть до приймання/передавання;

•криптографiя;

•захист iнформацi¨;

•iдентифiкацiя та автентифiкацiя;

•керування безпекою;

•конфiденцiйнiсть роботи в системi;

•надiйнiсть засобiв захисту;

•контроль за використанням ресурсiв;

•контроль доступу до системи;

•пряма вза¹модiя.

Змiст класiв ФВБ вiдрiзня¹ться сво¹ю всеохоплюючою повнотою i багаторiвневим пiдходом до забезпечення безпеки. Окремi класи вимог спрямованi на забезпечення безпеки самих засобiв захисту, контролю за експлуатацi¹ю системи, забезпечення конфiденцiйностi сеансiв доступу до системи та органiзацi¨ обмiну iнформацi¹ю.

Вимоги конфiденцiйностi, цiлiсностi та керування доступом об'¹днанi в один клас захисту iнформацi¨, що вигляда¹ цiлком логiчно i повнiстю вiдповiда¹ ¨х призначенню. Слiд вiдзначити наявнiсть, крiм полiтики керування доступом, також полiтики ке-

352	Ðîçäië 5

Ðèñ. 5.11. Класи функцiональних вимог

рування iнформацiйними потоками, а також вiддiлення вимог до полiтики безпеки вiд вимог до засобiв реалiзацi¨.

Клас вимог до безпеки самих засобiв захисту ¹ найбiльш об'¹мним, що визнача¹ться високим ступенем деталiзацi¨ включених до

Стандартизованi моделi та методи оцiнки ефективностi захисту	353

нього вимог до методiв i засобiв забезпечення нормального функцiонування засобiв захисту.

Особлива увага придiля¹ться контролю за доступом до системи i конфiденцiйностi сеансiв роботи з нею. Вимоги до органiзацi¨ iнформацiйного обмiну обмежуються неможливiстю учасникiв вза¹модi¨ ухилятися вiд вiдповiдальностi.

Ðîçäië ÔÂÁ [assurance family] складова частина класу ФВБ. Структура роздiлу мiстить наступнi елементи:

•назва та позначення роздiлу [family name];

•îïèñ ðîçäiëó [family behaviour];

•ранжирування вимог [component levelling];

•керованi параметри [management];

•об'¹кти ре¹страцi¨ та облiку [audit];

•вимоги [components].

Кожний роздiл ма¹ свою унiкальну назву i семисимвольний iдентифiкатор, який склада¹ться з трибуквеного iдентифiкатора класу, знаку пiдкреслення i трибуквеного позначення роздiлу.

Набiр вимог представля¹ собою i¹рархiчну структуру (рис. 5.12), в якiй пiдсилення вимог здiйсню¹ться монотонно, але при

Ðèñ. 5.12. Декомпозицiя класу ФВБ

354	Ðîçäië 5

цьому не ¹ лiнiйним упорядкованим списком.

Вимоги, якi стоять в i¹рархi¨ вище iнших включають у себе нижчестоящi вимоги. Це означа¹, що у профiлi захисту необхiдно використати тiльки одну з таких вимог.

Вимоги, якi не зв'язанi вiдносинами i¹рархiчностi ¹ незалежними i можуть використовуватися одночасно.

Ранжирування функцiональних вимог здiйсню¹ться не за ¹диною унiверсальною шкалою безпеки, як в iнших критерiях, а за множиною часткових критерi¨в (бiльше 280). Набiр цих критерi¨в явля¹ собою i¹рархiчну структуру у виглядi невпорядкованого списку порiвнянних i непорiвнянних вимог, в якому пiдсилення вимог здiйсню¹ться монотонно вiд нижчих рiвнiв до вищих. Ця структура ма¹ вигляд спрямованого графа пiдсилення вимог безпеки здiйсню¹ться при руховi по його ребрах.

5.3.2.2. Класи функцiональних вимог безпеки

Аудит

Клас ФВБ: аудит [class FAU: security AUdit] включа¹ наступнi роздiли ФВБ (рис. 5.13):

•автоматичне реагування на спроби порушення безпеки;

•ре¹страцiя та облiк подiй;

•аналiз протоколу аудита;

•доступ до протоколу аудита;

•вiдбiр подiй для ре¹страцi¨ й облiку;

•протокол аудита.

Роздiл ФВБ: автоматичне реагування на спроби порушення безпеки [security audit Automatic ResPonse (FAU_ARP)] включа¹ вимогу засоби захисту повиннi реагувати на спроби порушення безпеки [security alarms (FAU_ARP.1)].

Роздiл ФВБ: ре¹страцiя й облiк подiй [security audit data GENeration (FAU_GEN)] включа¹ незалежнi функцiональнi вимоги безпеки:

•ре¹страцiя задано¨ множини подiй i задавання облiково¨ iн-

формацi¨ для подiй кожного типу [audit data generation (FAU_GEN.1)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	355

Ðèñ. 5.13. Декомпозицiя класу ФВБ: аудит

•ре¹страцiя, облiк подiй та ре¹страцiя користувачiв, якi iнiцiювали подi¨ [user identity association (FAU_GEN.2)].

Роздiл ФВБ: аналiз протоколу аудита [Security Audit Analysis (FAU_SAA)] включа¹ функцiональну вимогу безпеки виявлення потенцiйно небезпечних подiй на основi контролю за дi-

356	Ðîçäië 5

апазонами параметрiв облiку на основi фiксовано¨ множини правил [potential violation analysis (FAU_SAA.1)], яка пiдсилю¹ться двома незалежними вимогами:

•статистичне розпiзнавання вторгнень на основi аналiзу про-

фiлiв роботи користувачiв [pro le based anomaly detection (FAU_SAA.2)];

•динамiчне розпiзнавання сигнатур елементарних атак на основi

простих евристик [simple attack heuristics (FAU_SAA.3)]. Вимога FAU_SAA.3 пiдсилю¹ться вимогою розпiзнавання

комплексних атак на основi складних евристик [complex attack heuristics (FAU_SAA.4)].

Роздiл ФВБ: доступ до протоколу аудита [Security Audit Review (FAU_SAR)] включа¹ незалежнi функцiональнi вимоги безпеки:

•надання доступу до протоколу аудита для обмеженого набору авторизованих користувачiв [audit review (FAU_SAR.1)];

•захист протоколу аудита вiд неавторизованих користувачiв [restricted audit review (FAU_SAR.2)];

•вибiркове керування доступом до протоколу аудита [selectable

audit review (FAU_SAR.3)].

Роздiл ФВБ: вiдбiр подiй для ре¹страцi¨ та облiку [security audit event SELection (FAU_SEL)] включа¹ вимогу безпеки визначення множини властивих аудитовi подiй на основi заданого набору атрибутiв [selective audit (FAU_SEL.1)].

Роздiл ФВБ: протокол аудита [security audit event SToraGe (FAU_STG)] включа¹ двi незалежнi функцiональнi вимоги безпеки:

•видiлення ресурсiв пiд протокол аудита, захист протоколiв вiд

неавторизовано¨ модифiкацi¨ або видалення [protected audit trail storage (FAU_STG.1)];

•попередження втрати записiв протоколу аудита у випадку

зменшення об'¹му ресурсiв, якi вiдведенi пiд протокол аудита до певно¨ межi [action in case of possible audit data loss (FAU_STG.3)].

Кожна з незалежних вимог пiдсилю¹ться вiдповiдно вимогами:

•гарантована доступнiсть протоколу аудита [guarantees of audit data availability (FAU_STG.2)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	357

•попередження втрат записiв аудита у випадку вичерпання ре-

сурсiв, якi вiдведенi пiд протокол аудита [prevention of audit data loss (FAU_STG.4)].

Захист iнформацi¨

Клас ФВБ: захист iнформацi¨ [class FDP: user Data Protection] включа¹ наступнi роздiли ФВБ (рис. 5.14, 5.15):

•полiтики керування доступом;

•засоби керування доступом;

•автентифiкацiя iнформацi¨;

•експорт iнформацi¨ iз системи;

•полiтики керування iнформацiйними потоками;

•засоби керування iнформацiйними потоками;

•iмпорт iнформацi¨;

•захист iнформацi¨ при передаваннi внутрiшнiми каналами;

•знищення залишково¨ iнформацi¨;

•âiäêiò;

•контроль цiлiсностi iнформацi¨ у процесi зберiгання;

•захист внутрiшньосистемного передавання iнформацi¨ при використаннi зовнiшнiх каналiв;

•цiлiснiсть внутрiшньосистемного передавання iнформацi¨ при

використаннi зовнiшнiх каналiв.

Роздiл ФВБ: полiтики керування доступом [ACcess Control policy (FDP_ACC) включа¹ i¹рархiчно залежнi вимоги безпеки:

•керування доступом для обмежено¨ множини операцiй i об'¹- ктiв [subset access control (FDP_ACC.1)];

•керування доступом для повно¨ множини об'¹ктiв, суб'¹ктiв i

операцiй. Будь-яка операцiя, яка здiйсню¹ться будь-яким об'- ¹ктом, повинна контролюватися принаймнi одною полiтикою керування доступом [complete access control (FDP_ACC.2)].

Роздiл ФВБ: засоби керування доступом [Access Control Functions (FDP_ACF)] включа¹ вимогу безпеки керування доступом на основi атрибутiв безпеки або iменованих груп атрибутiв iз явним дозволом або вiдмовою в доступi [security attribute based access control (FDP_ACF.1)].

358	Ðîçäië 5

Ðèñ. 5.14. Декомпозицiя класу ФВБ: захист iнформацi¨

Стандартизованi моделi та методи оцiнки ефективностi захисту	359

Ðèñ. 5.15. Декомпозицiя класу ФВБ: захист iнформацi¨ (продовження)

Роздiл ФВБ: автентифiкацiя iнформацi¨ [Data AUtenti-cation (FDP_DAU)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•автентифiкацiя iнформацi¨, що мiститься в об'¹ктi доступу [basic data authentication (FDP_DAU.1)];

•автентифiкацiя iнформацi¨, що мiститься в об'¹ктi доступу з

iдентифiкацi¹ю суб'¹кта, що здiйсню¹ автентифiкацiю [data authentication with identity of guarantor (FDP_DAU.2)].

Роздiл ФВБ: експорт iнформацi¨ iз системи [Export to outside TSF Control (FDP_ETC)] включа¹ незалежнi функцiональнi вимоги безпеки:

•експорт iнформацi¨ без атрибутiв безпеки [export of user data without security attributes (FDP_ETC.1)];

•експорт iнформацi¨ разом з атрибутами безпеки [export of user

data with security attributes (FDP_ETC.2)].

Роздiл ФВБ: полiтики керування iнформацiйними по-

360	Ðîçäië 5

токами [Information Flow Control policy (FDP_IFC)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•керування iнформацiйними потоками для обмежено¨ множини операцiй i потокiв [subset information ow control (FDP_IFC.1)];

•керування доступом до повно¨ множини потокiв, суб'¹ктiв i опе-

рацiй. Будь-яка полiтика керування потоками повинна контролювати всi операцi¨ у системi. Усi потоки iнформацi¨ в системi повиннi контролюватися принаймнi однi¹ю полiтикою керування iнформацiйними потоками [complete information ow control

(FDP_IFC.2)].

Роздiл ФВБ: засоби керування iнформацiйними потоками [Information Flow control Functions (FDP_IFF)] включа¹ незалежнi функцiональнi вимоги безпеки:

•керування iнформацiйними потоками на основi атрибутiв без-

пеки iнформацi¨ й суб'¹ктiв, мiж якими здiйсню¹ться обмiн iнформацi¹ю [simple security attributes (FDP_IFF.1)];

•контроль схованих iнформацiйних потокiв [limited illicit information ows (FDP_IFF.3)];

•монiторинг схованих iнформацiйних потокiв i обмеження

¨хньо¨ пропускно¨ здатностi [illicit information ow monitoring (FDP_IFF.6)].

Вимога FDP_IFF.1 пiдсилю¹ться вимогою керування iнформацiйними потоками на основi i¹рархiчно впорядкованих атрибутiв безпеки, присво¹них усiм iнформацiйним потокам i утворюю- чих грати [hierarchical security attributes (FDP_IFF.2)].

Вимога FDP_IFF.3 пiдсилю¹ться i¹рархiчно залежними вимогами:

•часткова заборона схованих iнформацiйних потокiв [partial elimination of illicit information ows (FDP_IFF.4)];

•повна заборона схованих iнформацiйних потокiв [no illicit

information ows (FDP_IFF.5)].

Роздiл ФВБ: iмпорт iнформацi¨ [Import from outside TSF Control (FDP_ITC)] включа¹ незалежнi функцiональнi вимоги безпеки:

•iмпорт iнформацi¨ без атрибутiв безпеки [import of user data without security attributes (FDP_ITC.1)];

•iмпорт iнформацi¨ разом з атрибутами безпеки [import of user

Стандартизованi моделi та методи оцiнки ефективностi захисту	361

data with security attributes (FDP_ITC.2)].

Роздiл ФВБ: захист iнформацi¨ при передаваннi внутрiшнiми каналами [Internal TOE Transfer (FDP_ITT)] включа¹ незалежнi функцiональнi вимоги безпеки:

•базовi засоби захисту iнформацi¨, що переда¹ться [basic internal transfer protection (FDP_ITT.1)];

•контроль цiлiсностi iнформацi¨, що переда¹ться [integrity moni-

toring (FDP_ITT.3)].

Цi вимоги вiдповiдно пiдсилюються вимогами:

•передавання даних iз рiзними атрибутами безпеки окремими каналами [transmission separation by attribute (FDP_ITT.2)];

•застосування рiзноманiтних методiв контролю цiлiсностi в за-

лежностi вiд атрибутiв безпеки [attribute-based integrity monitoring (FDP_ITT.4)].

Роздiл ФВБ: знищення залишково¨ iнформацi¨ [Residual Information Protection (FDP_RIP)] включа¹ i¹рархiчно залежнi вимоги безпеки функцiональнi:

•знищення залишково¨ iнформацi¨ для певно¨ пiдмножини об'-

¹ктiв при ¨хньому створеннi й вилученнi [subset residual information protection (FDP_RIP.1)];

•знищення залишково¨ iнформацi¨ для всiх об'¹ктiв при ¨х

створеннi або вилученнi [full residual information protection (FDP_RIP.2)].

Ðîçäië ÔÂÁ: âiäêiò [ROLlback (FDP_ROL)] включа¹ незалежнi функцiональнi вимоги безпеки:

•обмеження можливостi здiйснення вiдкоту для певно¨ пiд-

множини операцiй на задане число крокiв [basic rollback (FDP_ROL.1)];

•розширення можливостей здiйснення вiдкоту для всiх операцiй

на задане число крокiв [advanced rollback (FDP_ROl.2)].

Роздiл ФВБ: контроль цiлiсностi iнформацi¨ у процесi зберiгання [Stored Data Integrity (FDP_SDI)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•виявлення порушень цiлiсностi iнформацi¨ у процесi зберiгання [stored data integrity monitoring (FDP_SDI.1)];

•виявлення порушень цiлiсностi iнформацi¨ у процесi зберiгання i визначення реакцi¨ на виявленi помилки [stored data integrity

362	Ðîçäië 5

monitoring and action (FDP_SDI.2)].

Роздiл ФВБ: захист внутрiшньосистемного передаван-

ня iнформацi¨ при використаннi зовнiшнiх каналiв [interTSF User data Con dentiality Transfer protection (FDP_UCT)] включа¹ функцiональну вимогу безпеки захист iнформацi¨ при спрямуваннi ¨¨ у зовнiшнiй канал [basic data exchange con dentiality (FDP_UCT.1)].

Роздiл ФВБ: цiлiснiсть внутрiшньосистемного пере-

давання iнформацi¨ при використаннi зовнiшнiх каналiв

[inter-TSF User data integrity Transfer protection (FDP_UIT)] вклю- ча¹ незалежнi функцiональнi вимоги безпеки виявлення порушень цiлiсностi при передаваннi iнформацi¨ [data exchange integrity (FDP_UIT.1)] i вiдновлення iнформацi¨ одержувачем [source data exchange recovery (FDP_UIT.2)], яка пiдсилю¹ться вимогою повторне передавання iнформацi¨ [destination data exchange recovery (FDP_UIT.3)].

Iдентифiкацiя i автентифiкацiя

Клас ФВБ: iдентифiкацiя i автентифiкацiя [class FIA: Identi cation and Authentication] включа¹ наступнi роздiли ФВБ (рис. 5.16):

•реакцiя на невдалi спроби автентифiкацi¨;

•атрибути безпеки користувачiв;

•автентифiкацiйнi параметри;

•автентифiкацiя користувачiв;

•iдентифiкацiя користувачiв;

•вiдповiднiсть користувачiв i суб'¹ктiв.

Роздiл ФВБ: реакцiя на невдалi спроби автентифiкацi¨

[Authentication FaiLures (FIA_AFL)] включа¹ вимогу безпеки засоби iдентифiкацi¨ й автентифiкацi¨ повиннi припиняти спроби встановлення сеансiв роботи iз системою пiсля встановленого чи- сла невдалих спроб автентифiкацi¨ i призупиняти обслуговування засобiв, що задiянi в ходi цих спроб [authentication failure handling (FIA_AFL.1)].

Роздiл ФВБ: атрибути безпеки користувачiв [user ATtribute De nition (FIA_ATD)] включа¹ вимогу безпеки iндивiду-

Стандартизованi моделi та методи оцiнки ефективностi захисту	363

Ðèñ. 5.16. Декомпозицiя класу ФВБ: iдентифiкацiя i автентифiкацiя

364	Ðîçäië 5

альне призначення атрибутiв безпеки користувачiв [user attribute de nition (FIA_ATD.1)].

Роздiл ФВБ: автентифiкацiйнi параметри [Speci cation Of Secrets (FIA_SOS)] включа¹ незалежнi функцiональнi вимоги безпеки:

•перевiрка якостi автентифiкацiйних параметрiв вiдповiдно до заданих критерi¨в [veri cation of secrets (FIA_SOS.1)];

•автоматична генерацiя автентифiкацiйних параметрiв i перевiрка ¨хньо¨ якостi вiдповiдно до заданих критерi¨в [TSF

generation of secrets (FIA_SOS.2)].

Роздiл ФВБ: автентифiкацiя користувачiв [User AUthentication (FIA_UAU)] включа¹ незалежнi функцiональнi вимоги безпеки:

•обов'язковiсть автентифiкацi¨ користувачiв [timing of authentication (FIA_UAU.1)];

•механiзм автентифiкацi¨ повинен розпiзнавати та попереджу-

вати використання пiдроблених автентифiкацiйних параметрiв або ¨хнiх дублiкатiв [unforgeable authentication (FIA_UAU.3)];

•використання одноразових автентифiкацiйних параметрiв [single-use authentication mechanisms (FIA_UAU.4)];

•використання множини механiзмiв автентифiкацi¨, що ви-

користову¹ться залежно вiд ситуацi¨ [multiple authentication mechanisms (FIA_UAU.5)];

•застосування механiзмiв повторно¨ автентифiкацi¨ для ви-

конання встановлено¨ множини операцiй [re-authenticating (FIA_UAU.6)];

•мiнiмiзацiя iнформацi¨, що нада¹ться користувачевi в процесi

проходження процедури автентифiкацi¨ [protected authentication feedback (FIA_UAU.7)].

Вимога FIA_UAU.1 пiдсилю¹ться вимогою неможливiсть здiйснення дiй, що контролюються засобами захисту, без успiшного проходження процедури автентифiкацi¨ [user authentication before any action (FIA_UAU.2)].

Роздiл ФВБ: iдентифiкацiя користувачiв [User IDenti - cation (FIA_UID)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

• обов'язковiсть iдентифiкацi¨ користувачiв [timing of identi cati-

Стандартизованi моделi та методи оцiнки ефективностi захисту	365

on (FIA_UID.1)];

• неможливiсть здiйсненнi дiй, що контролюються засобами за-

хисту, без успiшного проходження процедури iдентифiкацi¨ [user identi cation before any action (FIA_UID.2)].

Роздiл ФВБ: вiдповiднiсть користувачiв i суб'¹ктiв

[User-Subject Binding (FIA_USB)] включа¹ вимогу безпеки присво¹ння суб'¹ктам, що дiють вiд iменi користувача, його атрибутiв безпеки [user-subject binding (FIA_USB.1)].

Керування безпекою

Клас ФВБ: керування безпекою [class FMT: security ManegemenT] включа¹ наступнi роздiли ФВБ (рис. 5.17):

•керування засобами захисту;

•керування атрибутами безпеки;

•керування параметрами та конфiгурацi¹ю засобiв захисту;

•вiдкликання атрибутiв безпеки;

•обмеження термiну дi¨ атрибутiв безпеки;

•адмiнiстративнi ролi.

Роздiл ФВБ: керування засобами захисту [Management Of Functions in TSF (FMT_MOF)] включа¹ вимогу безпекикерування авторизованими користувачами засобами захисту [management of security functions behaviour (FMT_MOF.1)].

Роздiл ФВБ: керування атрибутами безпеки

[Management of Security Attributes (FMT_MSA)] включа¹ незалежнi функцiональнi вимоги безпеки:

•керування авторизованими користувачами атрибутами безпеки [management of security attributes (FMT_MSA.1)];

•контроль коректностi значень атрибутiв безпеки [secure security attributes (FMT_MSF.2)];

•коректна iнiцiалiзацiя атрибутiв безпеки визначеними значен-

íÿìè [static attribute initialization (FMT_MSA.3)].

Роздiл ФВБ: керування параметрами та конфiгурацi¹ю засобiв захисту [Management of TSF Data (FMT_MTD)] вклю- ча¹ незалежнi функцiональнi вимоги безпеки:

•керування параметрами та конфiгурацi¹ю засобiв захисту авторизованими користувачами [management of TSF data

366	Ðîçäië 5

Ðèñ. 5.17. Декомпозицiя класу ФВБ: керування безпекою

(FMT_MTD.1)];

•виконання заданих дiй у випадку виходу параметрiв функцiо-

нування засобiв захисту за встановленi межi [management of limits on TSF data (FMT_MTD.2)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	367

•автоматичний контроль коректностi конфiгурацi¨ й параметрiв засобiв захисту [secure TSF data (FMT_MTD.3)].

Роздiл ФВБ: вiдкликання атрибутiв безпеки [REVolocation (FMT_REV)] включа¹ вимогу безпеки вiдкликання атрибутiв безпеки вiдповiдно до встановлених правил [revocation (FMT_REV.1)].

Роздiл ФВБ: обмеження термiну дi¨ атрибутiв безпеки

[Security Attribute Expiration (FMT_SAE)] включа¹ вимогу безпеки призначення термiну дi¨ атрибутiв безпеки авторизованими користувачами [time-limited authorization (FMT_SAE.1)].

Роздiл ФВБ: адмiнiстративнi ролi [Security Management Roles (FMT_SMR)] включа¹ наступнi функцiональнi вимоги безпеки:

•використання адмiнiстративних ролей для керування безпекою [security roles (FMT_SMR.1)];

•надання ролевих повноважень за запитом користувача [assuming roles (FMT_SMR.3)].

Вимога FMT_SMR.1 пiдсилю¹ться вимогою використання упорядкованого набору адмiнiстративних ролей для керування безпекою [restrictions on security roles (FMT_SMR.2)]; .

Контроль доступу до системи

Клас ФВБ: контроль доступу до системи [class FTA: TOE Access] включа¹ наступнi роздiли ФВБ (рис. 5.18):

•обмеження на використання атрибутiв безпеки;

•обмеження числа одночасних сеансiв;

•блокування сеансу роботи iз системою;

•об'яви, попередження, запрошення та пiдказки;

•протокол сеансiв роботи iз системою;

•керування сеансами роботи iз системою.

Роздiл ФВБ: обмеження на використання атрибутiв безпеки [Limitation on scope of Selectable Attributes (FTA_LSA)] включа¹ вимогу безпеки обмеження множини атрибутiв безпеки, якi використовуються користувачем у межах однi¹¨ сесi¨ [limitation on scope of selectable attributes (FTA_LSA.1)].

368	Ðîçäië 5

Ðèñ. 5.18. Декомпозицiя класу ФВБ: контроль доступу до системи

Роздiл ФВБ: обмеження числа одночасних сеансiв [limitation on Multiple Concurrent Sessions (FTA_MCS)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•обмеження числа одночасних сеансiв [basic limitation on multiple concurrent sessions (FTA_MCS.1)];

•обмеження числа одночасних сеансiв у залежностi вiд атрибутiв безпеки користувачiв [per user attribute limitation on multiple

concurrent sessions (FTA_MCS.2)].

Роздiл ФВБ: блокування сеансу роботи iз системою

[SeSsion Locking (FTA_SSL)] включа¹ незалежнi функцiональнi вимоги безпеки:

Стандартизованi моделi та методи оцiнки ефективностi захисту	369

•автоматичне блокування сеансу роботи пiсля вказаного перiоду неактивностi [TSF-initiated session locking (FTA_SSL.1)];

•блокування сеансу користувачем [user-initiated locking

(FTA_SSL.2)];

• автоматичне завершення сеансу роботи пiсля закiнчен-

ня заданого перiоду неактивностi [TSF-initiated termination (FTA_SSL.3)].

Роздiл ФВБ: об'яви, попередження, запрошення та пiдказки [TOE Assess Banners (FTA_TAB)] включа¹ вимогу безпекидемонстрацiя об'яв, попереджень, запрошень i пiдказок перед початком сеансу роботи iз системою [default TOE access banners (FTA_TAB.1)].

Роздiл ФВБ: протокол сеансiв роботи iз системою [TOE Assess History (FTA_TAH)] включа¹ вимогу безпеки ре¹страцiя й демонстрацiя користувачам протоколу сеансiв ¨хньо¨ роботи й спроб входу в систему [TOE access history (FTA_TAH.1)].

Роздiл ФВБ: керування сеансами роботи iз системою

[TOE Session Establishment (FTA_TSE)] включа¹ вимогу безпекизаборона встановлення сеансу роботи iз системою на основi задано¨ множини правил [TOE session establishment (FTA_TSE.1)].

Контроль за використанням ресурсiв

Клас ФВБ: контроль за використанням ресурсiв [class FRU: Resource Utilisation] включа¹ наступнi роздiли ФВБ (рис. 5.19):

•ñòiéêiñòü äî âiäìîâ;

•розподiл ресурсiв на основi прiоритетiв;

•квотування ресурсiв.

Ðîçäië ÔÂÁ: ñòiéêiñòü äî âiäìîâ [FauLt Tolerance (FRU_FLT)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•забезпечення працездатностi системи на заданому рiвнi у ви-

падку виникнення вказаних збо¨в [degraded fault tolerance (FRU_FLT.1)];

•забезпечення нормально¨ роботи системи у випадку виникнення вказаних збо¨в [limited fault tolerance (FRU_FLT.2)].

370	Ðîçäië 5

Ðèñ. 5.19. Декомпозицiя класу ФВБ: контроль за використанням ресурсiв

Роздiл ФВБ: розподiл ресурсiв на основi прiоритетiв

[PRiority of Service(FRU_PRS)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•розподiл обмежено¨ пiдмножини ресурсiв системи на основi прiоритетiв [limited priority of service (FRU_PRS.1)];

•розподiл усiх ресурсiв на основi прiоритетiв [full priority of servi-

ce (FRU_PRS.2)].

Роздiл ФВБ: квотування ресурсiв [ReSource Allocation (FRU_RSA)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•обмеження на споживання користувачами ресурсiв системи за допомогою квот [maximum quotas (FRU_RSA.1)];

•обмеження на споживання користувачами ресурсiв системи

за допомогою квот i резервування для споживача гарантовано¨ множини ресурсiв [minimum and maximum quotas (FRU_RSA.2)].

Конфiденцiйнiсть роботи в системi

Клас ФВБ: конфiденцiйнiсть роботи в системi [class FPR: PRivacy] включа¹ наступнi роздiли ФВБ (рис. 5.20):

• анонiмнiсть користувачiв;

Стандартизованi моделi та методи оцiнки ефективностi захисту	371

Ðèñ. 5.20. Декомпозицiя класу ФВБ: контроль доступу до системи

•використання псевдонiмiв;

•анонiмнiсть сеансiв роботи iз системою;

•захист вiд монiторингу сеансiв роботи iз системою.

Роздiл ФВБ: анонiмнiсть користувачiв [ANOnymity (FPR_ANO)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•анонiмнiсть суб'¹ктiв, якi представляють iнтереси користувачiв [anonymity (FPR_ANO.1)];

•анонiмнiсть iдентифiкаторiв користувачiв для середовища за-

хисту [anonymity without soliciting information (FPR_ANO.2)].

Роздiл ФВБ: використання псевдонiмiв [PSEudonymity (FPR_PSE)] включа¹ вимогу безпеки контроль дiй анонiмних користувачiв за допомогою псевдонiмiв [pseudonymity (FPR_PSE.1)], яка пiдсилю¹ться незалежними вимогами:

372	Ðîçäië 5

•встановлення особистостi користувача за псевдонiмом [reversible pseudonymity (FPR_PSE.2)];

•призначення псевдонiмiв вiдповiдно до заданих правил [alias

pseudonymity (FPR_PSE.3)].

Роздiл ФВБ: анонiмнiсть сеансiв роботи iз системою

[UNLinkability (FPR_UNL)] включа¹ вимогу безпеки неможливiсть встановлення iнiцiатора операцiй, що здiйснюються в системi [unlinkability (FPR_UNL.1)].

Роздiл ФВБ: захист вiд монiторингу сеансiв роботи iз системою [UNObservability (FPR_UNO)] включа¹ незалежнi функцiональнi вимоги безпеки:

•захист операцiй, що вiдбуваються в системi, вiд монiторингу [unobservability (FPR_UNO.1)];

•заборона засобам захисту запитувати у користувача конфiден-

цiйну iнформацiю [unobservability without soliciting information (FPR_UNO.3)];

•монiторинг роботи системи та використання ресурсiв тiльки

авторизованими користувачами [authorised user observability (FPR_UNO.4)].

Вимога FPR_UNO.1 пiдсилю¹ться вимогою розосередження критично¨ iнформацi¨ мiж рiзними компонентами засобiв захисту [allocation of information impacting unobservability (FPR_UNO.2)].

Криптографiя

Клас ФВБ: криптографiя [class FCS: Cryptographic Support] включа¹ наступнi роздiли ФВБ (рис. 5.21):

•керування ключами;

•криптографiчнi засоби.

Роздiл ФВБ: керування ключами [Cryptographic Key Management (FCO_CKM)] включа¹ незалежнi функцiональнi вимоги безпеки:

•генерацiя ключiв заданого розмiру за певними алгоритмами у

вiдповiдностi до певних стандартiв [cryptographic key generation (FCO_CKM.1)];

•розподiл ключiв способами, визначеними в спецiальних стандартах [cryptographic key distribution (FCO_CKM.2)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	373

Ðèñ. 5.21. Декомпозицiя класу ФВБ: криптографiя

• здiйснення доступу до ключiв iз використанням методiв, визна-

чених у спецiальних стандартах [(FCO_CKM.3)];

• знищення ключiв iз використанням методiв, визначених

у спецiальних стандартах [cryptographic key destruction (FCO_CKM.4)].

Роздiл ФВБ: криптографiчнi засоби [Cryptographic OPeration (FCO_COP)] включа¹ вимогу безпеки виконання криптографiчних операцiй з використанням ключiв заданого розмiру i визначених алгоритмiв у вiдповiдностi до спецiальних стандартiв [cryptographic operation (FCO_COP.1)].

Надiйнiсть засобiв захисту

Клас ФВБ: надiйнiсть засобiв захисту [class FPT: Protection of the TSF] включа¹ наступнi роздiли ФВБ (рис. 5.22, 5.25):

•тестування апаратно-програмно¨ платформи;

•захист вiд збо¨в;

•готовнiсть засобiв захисту до обслуговування вiддалених клi-

374	Ðîçäië 5

Ðèñ. 5.22. Декомпозицiя класу ФВБ: надiйнiсть засобiв захисту

Стандартизованi моделi та методи оцiнки ефективностi захисту	375

Ðèñ. 5.23. Декомпозицiя класу ФВБ: надiйнiсть засобiв захисту (продовження)

¹íòiâ;

•конфiденцiйнiсть iнформацi¨, що переда¹ться, при роботi з вiддаленими клi¹нтами;

•цiлiснiсть iнформацi¨, що переда¹ться, при роботi з вiддаленими клi¹нтами;

•захист внутрiшнiх каналiв iнформацiйного обмiну мiж засобами захисту;

•фiзичний захист;

•безпечне вiдновлення пiсля збо¨в;

•розпiзнавання повторного передавання iнформацi¨ та iмiтацiя подiй;

•монiторинг вза¹модiй;

•розподiл доменiв;

•синхронiзацiя;

•÷àñ;

376	Ðîçäië 5

•погодженiсть обмiну iнформацi¹ю мiж засобами захисту;

•реплiкацiя iнформацi¨, що використову¹ться засобами захисту;

•самотестування засобiв захисту.

Роздiл ФВБ: тестування апаратно-програмно¨ платформи [underlying Abstract Machine Test (FPT_AMT)] вклю- ча¹ вимогу безпеки перевiрка коректностi функцiонування апаратно-програмно¨ платформи [abstract machine testing (FPT_AMT.1)].

Роздiл ФВБ: захист вiд збо¨в [FaiL Secure (FPT_FLS)] включа¹ вимогу безпеки збереження безпечного стану у випадку виникнення збо¨в [failure with preservation of secure state (FPT_FLS.1)].

Роздiл ФВБ: готовнiсть засобiв захисту до обслуговування вiддалених клi¹нтiв [availability of exported TSF data (FPT_ITA)] включа¹ вимогу безпеки забезпечення готовностi засобiв захисту до обслуговування вiддалених клi¹нтiв iз заданою ймовiрнiстю [inter-TSF availability within a de ned availability metric (FPT_ITA.1)].

Роздiл ФВБ: конфiденцiйнiсть iнформацi¨, що переда¹ться, при роботi з вiддаленими клi¹нтами [con dentiality of exported TSF data (FPT_ITC)] включа¹ вимогу безпеки функцiональну забезпечення конфiденцiйностi iнформацi¨, що переда¹ться мiж засобами захисту i вiддаленими клi¹нтами [inter-TSF con dentiality during transmission (FPT_ITC.1)].

Роздiл ФВБ: цiлiснiсть iнформацi¨, що переда¹ться, при роботi з вiддаленими клi¹нтами [integrity of exported TSF data (FPT_ITI)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•виявлення спотворень iнформацi¨, яка переда¹ться мiж засо-

бами захисту i вiддаленими клi¹нтами [inter-TSF detection of modi cation (FPT_ITI.1)];

•виявлення спотворень iнформацi¨, яка переда¹ться мiж засоба-

ми захисту i вiддаленими клi¹нтами, i ¨хн¹ виправлення [interTSF detection and correction of modi cation (FPT_ITI.2)].

Роздiл ФВБ: захист внутрiшнiх каналiв iнформацiйного обмiну мiж засобами захисту [Internal TOE TSF data transfer (FPT_ITT)]включа¹ вимогу безпеки базовi засоби за-

Роздiл ФВБ: розподiл доменiв

Стандартизованi моделi та методи оцiнки ефективностi захисту	377

хисту iнформацiйного обмiну мiж засобами захисту [basic internal TSF data transfer protection (FPT_ITT.1)], яка пiдсилю¹ться незалежними вимогами:

•розподiл трафiка iнформацiйного обмiну мiж засобами захи-

сту i трафiка прикладних засобiв [TSF data transfer separation (FPT_ITT.2)];

•контроль цiлiсностi iнформацi¨ при вза¹модi¨ засобiв захисту

[TSF data integrity monitoring (FPT_ITT.3)].

Роздiл ФВБ: фiзичний захист [TSF PHysical Protection (FPT_PHP)] включа¹ незалежнi функцiональнi вимоги безпекипасивне виявлення атак на фiзичному рiвнi [passive detection of physical attack (FPT_PHP.1)] i активна протидiя атакам на фiзичному рiвнi [resistance to physical attack (FPT_PHP.3)], перша з яких пiдсилю¹ться вимогою оповiщення адмiнiстратора при виявленнi атак на фiзичному рiвнi [noti cation of physical attack (FPT_PHP.2)].

Роздiл ФВБ: безпечне вiдновлення пiсля збо¨в [trusted ReCoVery (FPT_RCV)] включа¹ незалежнi функцiональнi вимоги безпеки:

•ручне вiдновлення пiсля збо¨в [manual recovery (FPT_RCV.1)];

•вiдновлення пiсля збо¨в шляхом здiйсненнi вiдкоту в безпечний

ñòàí [function recovery (FPT_RCV.4)].

Вимога FPT_RCV.1 пiдсилю¹ться i¹рархiчно залежними вимогами:

•автоматичне вiдновлення пiсля збо¨в [automated recovery (FPT_RCV.2)];

•автоматичне вiдновлення пiсля збо¨в iз мiнiмiзацi¹ю втрат iн-

формацi¨ [automated recovery without undue loss (FPT_RCV.3)].

Роздiл ФВБ: розпiзнавання повторного передавання iнформацi¨ та iмiтацiя подiй [RePLay detection (FPT_RPL)] включа¹ вимогу безпеки забезпечення конфiденцiйностi iнформацi¨, яка переда¹ться мiж засобами захисту i вiддаленими клi¹нтами [replay detection (FPT_RPL.1)].

Роздiл ФВБ: монiторинг вза¹модiй [Reference Mediation (FPT_RVM)] включа¹ вимогу безпеки монiторинг усiх вза¹модiй у системi [non-bypassability of the TSP (FPT_RVM.1)].

[domain SEParation

378	Ðîçäië 5

(FPT_SEP)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•видiлення спецiального домену для засобiв захисту [TSF domain separation (FPT_SEP.1)];

•видiлення окремих доменiв для процедур, що здiйснюють мо-

нiторинг вза¹модi¨ i реалiзують вказанi полiтики безпеки [SFP domain separation (FPT_SEP.2)];

•видiлення окремих доменiв для процедур. що здiйснюють монiторинг вза¹модiй i реалiзують будь-якi полiтики безпеки

[complete reference monitor (FPT_SEP.3)].

Роздiл ФВБ: синхронiзацiя [State Synchrony Protocol (FPT_SSP)] включа¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•пiдтвердження приймання iнформацi¨ [simple trusted acknowledgement (FPT_SSP.1)];

•синхронiзацiя стану учасникiв вза¹модi¨ у ходi обмiну iнформацi¹ю [mutual trusted acknowledgement (FPT_SSP.2)].

Ðîçäië ÔÂÁ: ÷àñ [time STaMps (FPT_STM)] включа¹ вимогу безпеки використання засобами захисту надiйного таймера [reliable time stamps (FPT_STM.1)].

Роздiл ФВБ: погодженiсть обмiну iнформацi¹ю мiж засобами захисту [inter-TSF TSF Data Consistency (FPT_TDC)] включа¹ вимогу безпеки коректнiсть перетворення iнформацi¨ при передаваннi мiж засобами захисту [inter-TSF basic TSF data consistency (FPT_TDC.1)].

Роздiл ФВБ: реплiкацiя iнформацi¨, що використову¹ться засобами захисту [internal TOE TSF data Replication Consistency (FPT_TRC)] включа¹ вимогу безпеки функцiональну контроль узгодженостi копiй iнформацi¨, що використову¹ться засобами захисту [internal TSF consistency (FPT_TRC.1)].

Роздiл ФВБ: самотестування засобiв захисту [TSF Self Test (FPT_TST)] включа¹ вимогу безпеки самотестування засобiв захисту за запитом, у процесi завантаження та функцiонування. Перевiрка цiлiсностi коду i даних засобiв захисту [TSF testing (FPT_TST.1)].

Стандартизованi моделi та методи оцiнки ефективностi захисту	379

Причетнiсть до приймання/передавання

Клас ФВБ: причетнiсть до приймання/передавання

[class FCO: COmmunication] включа¹ наступнi роздiли ФВБ (рис. 5.24):

Ðèñ. 5.24. Декомпозицiя класу ФВБ: причетнiсть до приймання/передавання

•попередження вiдмови вiд факту передавання iнформацi¨;

•попередження вiдмови вiд факту приймання iнформацi¨.

Роздiл ФВБ: попередження вiдмови вiд факту передавання iнформацi¨ [Non-Repudiation of Origin (FCO_NRO)] вклю- ча¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•пiдтвердження факту передавання iнформацi¨ за вимогою [selective proof of origin (FCO_NRO.1)];

•автоматичне пiдтвердження факту передавання iнформацi¨

[enforced proof of origin (FCO_NRO.2)].

Роздiл ФВБ: попередження вiдмови вiд факту приймання iнформацi¨ [Non-Repudiation of Receipt (FCO_NRR)] вклю- ча¹ i¹рархiчно залежнi функцiональнi вимоги безпеки:

•пiдтвердження факту одержання iнформацi¨ за вимогою [selective proof of receipt (FCO_NRR.1)];

•автоматичне пiдтвердження факту одержання iнформацi¨ [enforced proof of receipt (FCO_NRR.2)].

Пряма вза¹модiя

Клас ФВБ: пряма вза¹модiя [class FTP: Trusted

380	Ðîçäië 5

Path/channels] включа¹ наступнi роздiли ФВБ (рис. ??):

Ðèñ. 5.25. Декомпозицiя класу ФВБ: пряма вза¹модiя

•пряма вза¹модiя мiж засобами захисту;

•пряма вза¹модiя мiж користувачами.

Роздiл ФВБ: пряма вза¹модiя мiж засобами захисту

[Inter-TSF Trusted Channel (FTP_ITC)] включа¹ вимогу безпеки пряма вза¹модiя мiж компонентами мiж засобами захисту рiзних продуктiв [inter-TSF trusted channel (FTP_ITC.1)].

Роздiл ФВБ: пряма вза¹модiя мiж користувачами

[TRusted Path (FTP_TRP)] включа¹ вимогу безпеки пряма вза¹модiя з користувачами для вказаного набору ситуацiй або за бажанням користувача [trusted path (FTP_TRP.1)].

5.3.3 Вимоги гарантiй засобiв захисту

5.3.3.1. Загальна характеристика вимог гарантiй безпеки

Вимоги гарантiй безпеки (ВГБ) [security assurance requirements] вимоги безпеки, якi в Загальних критерiях представляють собою характеристику IТ-продукту, що показу¹, наскiльки ефективно забезпечу¹ться заявлений рiвень безпеки, а також ступiнь коректностi реалiзацi¨ засобiв захисту. Як i функцiональнi вимоги безпеки, ВГБ детально структурированi та регламентують усi етапи проектування, створення та експлуатацi¨ IТ-продукту дуже детально. Структура вимог гарантiй аналогiчна функцiональним вимогам.

Стандартизованi моделi та методи оцiнки ефективностi захисту	381

Êëàñ ÂÃÁ [assurance class] верхнiй рiвень формально¨ структури вимог гарантiй безпеки. Мiстить наступнi елементи:

•назву класу [class name];

•опис класу [class introduction];

•роздiли вимог гарантiй безпеки [assurance family]. Вимоги розподiленi на 7 класiв ВГБ (рис. 5.26):

•керування проектом;

•дистрибуцiя;

•розробка;

•документацiя;

•процес розробки;

•тестування;

•оцiнка уразливостей.

Ðîçäië ÂÃÁ [assurance family] складова частина класу ВГБ. Структура роздiлу мiстить наступнi елементи:

•назва та позначення роздiлу [family name];

•ìåòà [objectives];

•ранжирування вимог [component levelling];

•опис застосування [application notes];

•вимоги [assurance component].

Кожний роздiл ма¹ свою унiкальну назву i семисимвольний iдентифiкатор, який склада¹ться з трибуквеного iдентифiкатора класу, знаку пiдкреслення i трибуквеного позначення роздiлу. Ранжирування стандартних вимог представлене у виглядi впорядкованих спискiв (рис. 5.27).

Структура ВГБ склада¹ться з наступних елементiв:

•назва вимоги [component identi cation];

•ìåòà [objectives];

•опис застосування [application notes];

•сполученi вимоги [dependencies];

•елементи вимоги [assurance element].

Вимоги гарантiй використовуються в ходi квалiфiкацiйного аналiзу IТ-продукту вiдповiдного рiвня гарантiй.

382	Ðîçäië 5

Ðèñ. 5.26. Структура вимог гарантiй безпеки

Стандартизованi моделi та методи оцiнки ефективностi захисту	383

Ðèñ. 5.27. Декомпозицiя класу ВГБ

5.3.3.2. Класи вимог гарантiй безпеки

Керування проектом

Клас ВГБ: керування проектом [class ACM: Con guration Management] включа¹ наступнi роздiли ВГБ (рис. 5.28):

Ðèñ. 5.28. Декомпозицiя класу ВГБ: керування проектом

•засоби керування проектом;

•керування версiями;

•конфiгурацiя проекту.

Роздiл ВГБ: засоби керування проектом [Con guration Management AUTomation (ACM_AUT)] включа¹ наступнi вимоги гарантiй безпеки:

•застосування автоматизованих засобiв керування проектом [partial con guration management automation (ACM_AUT.1)];

•повна автоматизацi¨ керування проектом i контролю версiй

384	Ðîçäië 5

[complete con guration management automation (ACM_AUT.2)].

Роздiл ВГБ: керування версiями [Con guration Management CAPabilities (ACM_CAP)] включа¹ наступнi вимоги гарантiй безпеки:

•нумерацiя версiй [version numbers (ACM_CAP.1)];

•iдентифiкацiя компонентiв [con guration items (ACM_CAP.2)];

•контроль цiлiсностi версiй [authorisation controls (ACM_CAP.3)];

•авторизацiя розробникiв при поновленнi версiй [generation support and acceptance procedures (ACM_CAP.4)];

•контроль цiлiсностi й автентичностi дистрибутива системи [advanced support (ACM_CAP.5)].

Роздiл ВГБ: конфiгурацiя проекту [Con guration Management SCoPe (ACM_SCP)] включа¹ наступнi вимоги гарантiй безпеки:

•основнi компоненти проекту (алгоритми, вихiднi тексти, текс-

ти, документацiя) [TOE management automation coverage (ASM_SCP.1)];

•включення до складу конфiгурацi¨ об'¹кта виявлених помилок i

уразливостей [problem tracking management automation coverage (ASM_SCP.2)];

•включення до складу конфiгурацi¨ проекту iнструментальних

засобiв розробки [development tools management automation coverage (ASM_SCP.3)].

Дистрибуцiя

Клас ВГБ: дистрибуцiя [class ADO: Delivery and Operation] включа¹ наступнi роздiли ВГБ (рис. 5.29):

•постачання;

•установка, настройка, запуск.

Роздiл ВГБ: поставка [DELivery (ADO_DEL)] включа¹ наступнi вимоги гарантiй безпеки:

•регламентована процедура поставки [delivery procedures (ADO_DEL.1)];

•виявлення спотворень у процесi поставки [detection of modi - cation (ADO_DEL.2)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	385

Ðèñ. 5.29. Декомпозицiя класу ВГБ: дистрибуцiя

• захист вiд спотворень у процесi поставки [prevention of modi -

cation (ADO_DEL.3)].

Роздiл ВГБ: установка, настройка, запуск [Installation, Generation, and Start-up (ADO_IGS)] включа¹ наступнi вимоги гарантiй безпеки:

•регламентованi процедури установки, настройки, запуску [installation, generation, and start-up procedures (ADO_IGS.1)];

•протоколювання процесу установки, настройки, запуску [generation log (ADO_IGS.2)].

Розробка

Клас ВГБ: розробка [class ADV: DeVelopment] включа¹ наступнi роздiли ВГБ (рис. 5.30):

•загальнi функцiональнi специфiкацi¨;

•архiтектура захисту;

•форма подання продукту на сертифiкацiю;

•структура засобiв захисту;

•частковi специфiкацi¨ засобiв захисту;

•вiдповiднiсть описiв рiзного рiвня;

•полiтика безпеки.

Роздiл ВГБ: загальнi функцiональнi специфiкацi¨

[Functional SPeci cation (ADV_FSP)] включа¹ наступнi вимоги гарантiй безпеки:

•неформальнi специфiкацi¨ для засобiв захисту [informal functional speci cation (ADV_FSP.1)];

386	Ðîçäië 5

Ðèñ. 5.30. Декомпозицiя класу ВГБ: розробка

•неформальнi специфiкацi¨ для усiх iнтерфейсiв засобiв захисту [fully de ned external interfaces (ADV_FSP.2)];

•напiвформальнi специфiкацi¨ для засобiв захисту [semiformal functional speci cation (ADV_FSP.3)];

•формальнi специфiкацi¨ для засобiв захисту [formal functional

speci cation (ADV_FSP.4)].

Роздiл ВГБ: архiтектура захисту [High-Level Design (ADV_HLD)] включа¹ наступнi вимоги гарантiй безпеки:

•опис архiтектури захисту [descriptive high-level design (ADV_HLD.1)];

•вiдповiднiсть архiтектури захисту полiтицi безпеки [security enforcing high-level design (ADV_HLD.2)];

•напiвформальний опис архiтектури захисту [semiformal highlevel design (ADV_HLD.3)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	387

• вiдповiднiсть напiвформального опису архiтектури за-

хисту полiтицi безпеки [semiformal high-level explanation (ADV_HLD.4)];

• формальний опис архiтектури захисту й доказ ¨¨ вiдповiдностi

полiтицi безпеки [formal high-level design (ADV_HLD.5)].

Роздiл ВГБ: форма надання продукту на сертифiкацiю

[IMPlementation representation (ADV_IMP)] включа¹ наступнi вимоги гарантiй безпеки:

•опис реалiзацi¨ обмежено¨ пiдмножини засобiв захисту [subset of the implementation of the TSF (ADV_IMP.1)];

•повний опис реалiзацi¨ усiх засобiв захисту [implementation of the TSF (ADV_IMP.2)];

•структурований опис реалiзацi¨ усiх засобiв захисту [structured implementation of the TSF (ADV_IMP.3)].

Роздiл ВГБ: структура засобiв захисту [TSF INTernals (ADV_INT)] включа¹ наступнi вимоги гарантiй безпеки:

•модульнiсть [modularity (ADV_INT.1)];

•i¹ðàðõi÷íiñòü [reduction of complexity (ADV_INT.2)];

•мiнiмiзацiя складностi [minimization of complexity

(ADV_INT.3)].

Роздiл ВГБ: частковi специфiкацi¨ засобiв захисту [LowLevel Design (ADV_LLD)] включа¹ наступнi вимоги гарантiй безпеки:

•неформальнi частковi специфiкацi¨ засобiв захисту [descriptive low-level design (ADV_LLD.1)];

•напiвформальнi частковi специфiкацi¨ засобiв захисту [semiformal low-level design (ADV_LLD.2)];

•формальнi частковi специфiкацi¨ засобiв захисту [formal low-

level design (ADV_LLD.3)].

Роздiл ВГБ: вiдповiднiсть описiв рiзного рiвня

[Representation CorRespondente (ADV_RCR)] включа¹ наступнi вимоги гарантiй безпеки:

•неформальне пiдтвердження вiдповiдностi [informal correspondence demonstration (ADV_RCR.1)];

•напiвформальне пiдтвердження вiдповiдностi [semiformal correspondence demonstration (ADV_RCR.2)];

•формальний доказ вiдповiдностi [formal correspondence

388	Ðîçäië 5

demonstration (ADV_RCR.3)].

Роздiл ВГБ: полiтика безпеки [Security Policy Modeling (ADV_SPM)] включа¹ наступнi вимоги гарантiй безпеки:

•неформальний опис полiтики безпеки [informal TOE security policy model (ADV_SPM.1)];

•напiвформальний опис полiтики безпеки [semiformal TOE security policy model (ADV_SPM.2)];

•формальна модель полiтики безпеки [formal TOE security policy model (ADV_SPM.3)].

Документацiя

Клас ВГБ: документацiя [class AGD: Guidance Documents] включа¹ наступнi роздiли ВГБ (рис. 5.31):

Ðèñ. 5.31. Декомпозицiя класу ВГБ: документацiя

•керiвництво адмiнiстратора;

•керiвництво користувача.

Роздiл ВГБ: керiвництво адмiнiстратора [ADMinistrator guidance (AGD_ADM)] включа¹ вимогу гарантiй безпеки адмiнiстрування засобiв захисту [administrator guidance (AGD_ADM.1)].

Роздiл ВГБ: керiвництво користувача [USeR guidance (AGD_USR)] включа¹ вимогу гарантiй безпеки використання засобiв захисту [user guidance (AGD_USR.1)].

Процес розробки

Клас ВГБ: процес розробки [class ALC: Life Cycle support]

Стандартизованi моделi та методи оцiнки ефективностi захисту	389

включа¹ наступнi роздiли ВГБ (рис. 5.32):

Ðèñ. 5.32. Декомпозицiя класу ВГБ: процес розробки

•безпека середовища розробки;

•виправлення помилок i лiквiдацiя уразливостей;

•технологiя розробки;

•засоби розробки.

Роздiл ВГБ: безпека середовища розробки [DeVelopment Security (ALC_DVS)] включа¹ наступнi вимоги гарантiй безпеки:

•застосування заходiв безпеки в ходi розробки [identi cation of security measures (ALC_DVS.1)];

•пiдтвердження заходiв безпеки в ходi розробки [su ciency of

security measures (ALC_DVS.2)].

Роздiл ВГБ: виправлення помилок i лiквiдацiя уразливостей [FLaw Remediation (ALC_FLR)] включа¹ наступнi вимоги гарантiй безпеки:

•виправлення виявлених помилок i лiквiдацiя уразливостей [basic aw remediation (ALC_FLR.1)];

•регулярне виправлення помилок i лiквiдацiя уразливостей [ aw reporting procedures (ALC_FLR.2)];

•гарантоване виправлення виявлених помилок i лiквiдацiя вияв-

лених уразливостей [systematic aw remediation (ALC_FLR.3)].

Роздiл ВГБ: технологiя розробки [Life Cycle De nition

390	Ðîçäië 5

(ALC_LCD)] включа¹ наступнi вимоги гарантiй безпеки:

•визначена розробником технологiя розробки [developer de ned life-cycle model (ALC_LCD.1)];

•стандартизована технологiя розробки [standardised life-cycle model (ALC_LCD.2)];

•технологiя розробки, яка дозволя¹ оцiнювати продукт, що розроблю¹ться [measurable life-cycle model (ALC_LCD.3)].

Роздiл ВГБ: засоби розробки [Tools And Techniques (ALC_TAT)] включа¹ наступнi вимоги гарантiй безпеки:

•використання певного набору засобiв розробки [well-de ned development tools (ALC_TAT.1)];

•використання основних засобiв розробки, що вiдповiдають

певним стандартам [compliance with implementation standards (ALC_TAT.2)];

•використання тiльки засобiв розробки, що вiдповiдають певним

стандартам [compliance with implementation standards - all parts (ALC_TAT.3)].

Тестування

Клас ВГБ: тестування [class ATE: TEsts] включа¹ наступнi роздiли ВГБ (рис. 5.33):

•повнота тестування;

•глибина тестування;

•методика тестування;

•незалежне тестування.

Роздiл ВГБ: повнота тестування [COVerage (ATE_COV)] включа¹ наступнi вимоги гарантiй безпеки:

•об рунтування повноти тестування [evidence of coverage (ATE_COV.1)];

•аналiз повноти тестування [analysis of coverage (ATE_COV.2)];

•строгий аналiз повноти тестування [rigorous analysis of coverage (ATE_COV.3)].

Роздiл ВГБ: глибина тестування [DePTh (ATE_DPT)] включа¹ наступнi вимоги гарантiй безпеки:

• архiтектура [testing: high-level design (ALC_DPT.1)];

Стандартизованi моделi та методи оцiнки ефективностi захисту	391

Ðèñ. 5.33. Декомпозицiя класу ВГБ: тестування

•функцiональнi специфiкацi¨ [testing: low-level design (ALC_DPT.2)];

•ðåàëiçàöiÿ [testing: implementation representation

(ALC_DPT.3)].

Роздiл ВГБ: методика тестування [FUNctional tests (ATE_FUN)] включа¹ наступнi вимоги гарантiй безпеки:

•функцiональне тестування й протоколювання результатiв тестiв [functional testing (ALC_FUN.1)];

•тестування у вiдповiдностi з певною методикою [ordered functional testing (ALC_FUN.2)].

Роздiл ВГБ: незалежне тестування [INDependent testing (ATE_IND)] включа¹ наступнi вимоги гарантiй безпеки:

•готовнiсть продукту до незалежного тестування [independent testing - conformance (ALC_IND.1)];

•вибiркове незалежне тестування [independent testing - sample (ALC_IND.2)];

•повне незалежне тестування [independent testing - complete (ALC_IND.3)].

392	Ðîçäië 5

Оцiнка уразливостей

Клас ВГБ: оцiнка уразливостей [class AVA: Vulnerability Assessment] включа¹ наступнi роздiли ВГБ (рис. 5.34):

Ðèñ. 5.34. Декомпозицiя класу ВГБ: оцiнка уразливостей

•аналiз прихованих каналiв;

•аналiз можливостей неправильного використання засобiв захисту;

•аналiз стiйкостi засобiв захисту;

•аналiз продукту на наявнiсть уразливостей.

Роздiл ВГБ: аналiз прихованих каналiв [Covert Channel Analysis (AVA_CCA)] включа¹ наступнi вимоги гарантiй безпеки:

•пошук i документування прихованих каналiв [covert channel analysis (AVA_CCA.1)];

•пошук прихованих каналiв на основi певних методик [systematic covert channel analysis (AVA_CCA.2)];

•вичерпний пошук прихованих каналiв [exhaustive covert channel

analysis (AVA_CCA.3)].

Роздiл ВГБ: аналiз можливостей неправильного використання засобiв захисту [MiSUse (AVA_MSU)] включа¹ наступнi вимоги гарантiй безпеки:

• аналiз керiвництв з адмiнiстрування [examination of guidance

Стандартизованi моделi та методи оцiнки ефективностi захисту	393

(AVA_MSU.1)];

•пiдтвердження повноти керiвництв з адмiнiстрування та безпеки ¨хнього застосування [validation of analysis (AVA_MSU.2)];

•незалежний аналiз можливостей неправильного використан-

ня засобiв захисту [analysis and testing for insecure states (AVA_MSU.3)].

Роздiл ВГБ: аналiз стiйкостi засобiв захисту [Strength Of TOE security Functions (AVA_SOF)] включа¹ вимогу гарантiй безпеки оцiнка стiйкостi засобiв захисту [strength of TOE security function evaluation (AVA_SOF.1)].

Роздiл ВГБ: аналiз продукту на наявнiсть уразливостей

[VuLnerability Analysis (AVA_VLA)] включа¹ наступнi вимоги гарантiй безпеки:

•виявлення уразливостей розробником продукту [developer vulnerability analysis (AVA_VLA.1)];

•незалежний аналiз уразливостей [independent vulnerability analysis (AVA_VLA.2)];

•систематичний незалежний аналiз уразливостей на основi заданих методик [moderately resistant (AVA_VLA.3)];

•вичерпний аналiз уразливостей [highly resistant (AVA_VLA.4)].

5.3.4 Рiвнi гарантiй безпеки

Визначення рiвнiв гарантiй

Рiвнi гарантiй [Evaluation Assurance Level (EAL)] в Загальних критерiях це сiм стандартизованих наборiв вимог гарантiй безпеки, що регламентують застосування рiзноманiтних методiв i технологiй розробки, тестування, контролю та верифiкацi¨ IТпродукту:

•функцiональне тестування;

•структурне тестування;

•методичне тестування та перевiрка;

•методична розробка, тестування та аналiз;

•напiвформальнi методи розробки та тестування;

•напiвформальнi методи верифiкацi¨ розробки та тестування;

•формальнi методи верифiкацi¨ розробки та тестування.

394	Ðîçäië 5

Кожний з рiвнiв визнача¹ ступiнь вiдповiдностi IТ-продукту кожнiй вимозi гарантiй (гарантi¨ зростають вiд першого рiвня до сьомого). Назви рiвнiв вiдображають можливостi засобiв контролю i верифiкацi¨, що застосовуються в ходi розробки та аналiзу IТ-продукту (рис. 5.35).

Ðèñ. 5.35. Рiвнi гарантiй безпеки

Функцiональне тестування

Рiвень функцiонального тестування [EAL1 functionally

Стандартизованi моделi та методи оцiнки ефективностi захисту	395

tested] - перший рiвень гарантiй для випадкiв, коли загрозам безпецi не нада¹ться великого значення. Пропону¹ться використати його в тих ситуацiях, коли все, що необхiдно це незалежна гарантiя того, що до складу IТ-продукту входять засоби захисту персонально¨ або подiбно¨ iнформацi¨.

Вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом у роздiлi ВГБ: керування версiями нумерацiя версiй (ACM_CAP.1).

Óкласi ВГБ: дистрибуцiя в роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ неформальнi специфiкацi¨ для засобiв захисту (ADV_FSP.1);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня неформальне пiдтвердження вiдповiдностi (ADV_RCR.1).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: тестування в роздiлi ВГБ: незалежне тестування

готовнiсть продукту до незалежного тестування (ALC_IND.1). Аналiз IТ-продукту на вiдповiднiсть даному рiвню гарантiй за-

безпечу¹ться дослiдженням функцiй захисту та перевiркою функцiональних специфiкацiй, iнтерфейсiв та документацi¨.

Результати аналiзу пiдтверджуються незалежним тестуванням засобiв захисту IТ-продукту на вiдповiднiсть специфiкацiям i документацi¨.

Сертифiкацiя IТ-продукту на даний рiвень гарантiй ¹ пiдтвердженням вiдповiдностi властивостей IТ-продукту його документацi¨ та специфiкацiям, а також наявностi працездатностi захисту проти загроз безпецi.

Структурне тестування

Рiвень структурного тестування [EAL2 structurally

396	Ðîçäië 5

tested] - другий рiвень гарантiй, призначений для використання при обставинах, коли розробники або користувачi згоднi задовольнитися низьким або помiрним ступенем незалежного пiдтвердження гарантiй рiвня безпеки, який необхiдно забезпечити. Особливо рекомендують застосування даного рiвня для успадкованих систем, якi вже знаходяться в експлуатацi¨.

Другий рiвень гарантiй вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом у роздiлi ВГБ: керування версiями iдентифiкацiя компонентiв (ACM_CAP.2).

Óкласi ВГБ: дистрибуцiя:

•у роздiлi ВГБ: поставка регламентована процедура поставки (ADO_DEL.1);

•у роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ неформальнi специфiкацi¨ засобiв захисту (ADV_FSP.1);

•у роздiлi ВГБ: архiтектура захисту опис архiтектури захисту (ADV_HLD.1);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня неформальне пiдтвердження вiдповiдностi (ADV_RCR.1) (AGD_ADM.1).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: тестування:

•у роздiлi ВГБ: повнота тестування об рунтування повноти тестування (ATE_COV.1);

•у роздiлi ВГБ: методика тестування функцiональне тестування й протоколювання результатiв тестiв (ALC_FUN.1);

•у роздiлi ВГБ: незалежне тестування вибiркове незалежне тестування (ALC_IND.2).

Óкласу ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_SOF.1);

Стандартизованi моделi та методи оцiнки ефективностi захисту	397

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей виявлення уразливостей розробником продукту (AVA_VLA.1).

Розробка продукту вiдповiдно до вимог даного рiвня не вимага¹ вiд виробника нiяких додаткових витрат, порiвняно з розробкою звичайних комерцiйних або промислових продуктiв, окрiм надання результатiв тестування.

Для другого рiвня аналiз повинен проводитися не тiльки по вiдношенню функцiональних специфiкацiй, iнтерфейсiв та документацi¨, але й для архiтектури захисту IТ-продукту.

Крiм незалежного тестування засобiв захисту IТ-продукту результати аналiзу пiдтверджуються протоколами тестування функцiональних специфiкацiй, наданих розробником, а також незалежним вибiрковим контролем результатiв цих випробувань та глибини проведеного тестування, i незалежним пiдтвердженням пошуку розробником явних уразливостей. Крiм того, для цього рiвня необхiдна наявнiсть документованого складу конфiгурацi¨ продукту та доказ безпеки процедури поставки.

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

Методичне тестування та перевiрка

Рiвень методичного тестування та перевiрки [EAL3 methodically tested and checked] третiй рiвень гарантiй, призна- чений для використання при обставинах, коли розробникам або користувачам потрiбна помiрна ступiнь незалежного пiдтвердження властивостей IТ-продукту, а також повне i послiдовне дослiдження властивостей продукту i контроль в процесi створення, але без проведення дорогого зворотного проектування [reengineering].

Вiдповiда¹ наступним вимогам гарантiй безпеки.

У класi ВГБ: керування проектом:

•у роздiлi ВГБ: керування версiями контроль цiлiсностi версiй (ACM_CAP.3);

398	Ðîçäië 5

•у роздiлi ВГБ: конфiгурацiя проекту основнi компонен-

ти проекту (алгоритми, вихiднi тексти, тексти, документацiя) (ASM_SCP.1).

Óкласi ВГБ: дистрибуцiя:

•у роздiлi ВГБ: поставка регламентована процедура поставки (ADO_DEL.1);

•у роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ неформальнi специфiкацi¨ для засобiв захисту (ADV_FSP.1);

•у роздiлi ВГБ: архiтектура захисту вiдповiднiсть архiтектури захисту полiтицi безпеки (ADV_HLD).2;

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня неформальне пiдтвердження вiдповiдностi (ADV_RCR.1).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: процес розробки в роздiлi ВГБ: безпека середовища розробки застосування заходiв безпеки в ходi розробки (ALC_DVS.1).

Óкласi ВГБ: тестування:

•у роздiлi ВГБ: повнота тестування аналiз повноти тестування (ATE_COV.2);

•у роздiлi ВГБ: глибина тестування архiтектура (ALC_DPT.1);

•у роздiлi ВГБ: методика тестування функцiональне тестування й протоколювання результатiв тестiв (ALC_FUN.1);

•у роздiлi ВГБ: незалежне тестування вибiркове незалежне тестування (ALC_IND.2).

Óкласi ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз можливостей неправильного використа-

ння засобiв захисту аналiз керiвництв з адмiнiстрування (AVA_MSU.1);

Стандартизованi моделi та методи оцiнки ефективностi захисту	399

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_SOF.1);

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей виявлення уразливостей розробником продукту (AVA_VLA.1).

Цей рiвень дозволя¹ одержати максимальну ступiнь гарантiй, яка не потребу¹ нiяких змiн у звичайну процедуру розробки, оскiльки всi регламентованi ним заходи, спрямованi на забезпече- ння гарантiй, застосовуються на етапi проектування.

Для цього рiвня проводяться тi ж види аналiзу, що i для другого рiвня, але на доповнення до матерiалiв тестування специфiкацiй функцiй захисту вiд розробника вимага¹ться надання результатiв архiтектури захисту IТ-продукту. Вимоги до процесу створення продукту доповнюються використанням засобiв управлiння конфiгурацi¹ю проекту.

Рiвень розширю¹ вимоги попереднього за рахунок бiльш повного тестування функцiй захисту та засобiв ¨хньо¨ реалiзацi¨, а також застосуванням заходiв, якi дають упевненiсть у тому, що IТ-продукт не був пiдмiнений в процесi розробки.

Методична розробка, тестування та аналiз

Рiвень методично¨ розробки, тестування та аналiзу

[EAL4 - methodically designed, tested and reviewed] четвертий рiвень гарантiй, призначений для використання при обставинах, коли розробники або користувачi вимагають помiрного або високого ступеню незалежного пiдтвердження гарантiй захисту IТпродукту i готовi нести певнi додатковi витрати.

Вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом:

•у роздiлi ВГБ: засоби керування проектом застосування автоматизованих засобiв керування проектом ACM_AUT.1);

•у роздiлi ВГБ: керування версiями авторизацiя розробникiв при поновленнi версiй (ACM_CAP.4);

•у роздiлi ВГБ: конфiгурацiя проекту включення до скла-

ду конфiгурацi¨ проекту виявлених помилок i уразливостей (ASM_SCP.2).

Óкласi ВГБ: дистрибуцiя:

400	Ðîçäië 5

•у роздiлi ВГБ: поставка виявлення спотворень у процесi поставки (ADO_DEL.2);

•у роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ не-

формальнi специфiкацi¨ для усiх iнтерфейсiв засобiв захисту (ADV_FSP.2);

•у роздiлi ВГБ: архiтектура захисту вiдповiднiсть архiтектури захисту полiтицi безпеки (ADV_HLD.2);

•у роздiлi ВГБ: форма надання продукту на сертифiкацiю

опис реалiзацi¨ обмежено¨ пiдмножини засобiв захисту (ADV_IMP.1);

•у роздiлi ВГБ: частковi специфiкацi¨ засобiв захисту неформальнi частковi специфiкацi¨ засобiв захисту (ADV_LLD.1);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня неформальне пiдтвердження вiдповiдностi (ADV_RCR.1);

•у роздiлi ВГБ: полiтика безпеки неформальний опис полiтики безпеки (ADV_SPM.1).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: процес розробки:

•у роздiлi ВГБ: безпека середовища розробки застосування заходiв безпеки у ходi розробки (ALC_DVS.1);

•у роздiлi ВГБ: технологiя розробки визначена розробником технологiя розробки (ALC_LCD.1);

•у роздiлi ВГБ: засоби розробки використання певного набору засобiв розробки (ALC_TAT.1).

Óкласi ВГБ: тестування:

•у роздiлi ВГБ: повнота тестування аналiз повноти тестування (ATE_COV.2);

•у роздiлi ВГБ: глибина тестування архiтектура (ALC_DPT.1);

•у роздiлi ВГБ: методика тестування функцiональне тестува-

Стандартизованi моделi та методи оцiнки ефективностi захисту	401

ння й протоколювання результатiв тестiв (ALC_FUN.1);

•у роздiлi ВГБ: незалежне тестування вибiркове незалежне

тестування (ALC_IND.2).

У класi ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз можливостей неправильного вико-

ристання засобiв захисту пiдтвердження повноти керiвництв iз адмiнiстрування й безпеки ¨хнього застосування (AVA_MSU.2);

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_SOF.1);

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей незалежний аналiз уразливостей (AVA_VLA.2).

Цей рiвень, незважаючи на достатньо сильнi вимоги, не потребу¹ вiд розробника спецiальних знань у галузi розробки захищених систем та застосування спецiальних методiв i технологiй, якi вiдрiзняються вiд загальноприйнятих. Це найвищий рiвень гарантiй, на який можна розраховувати без значних додаткових економi- чних витрат.

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

Додатково до попереднього рiвня результати аналiзу пiддаються незалежним дослiдженням уразливостей засобiв захисту, якi демонструють стiйкiсть системи проти слабких атак. Вимоги до процесу створення продукту розширюються додатковими вимогами застосування автоматизованих засобiв керування конфiгурацi¹ю.

Даний рiвень вiдрiзня¹ться вiд попереднього посиленням вимог до процесу проектування та розробки, а також пiдсиленням заходiв, якi гарантують, що IТ-продукт не був пiдмiненим у процесi створення.

Напiвформальнi методи розробки та тестування

Рiвень напiвформальних методiв розробки та тестува-

402	Ðîçäië 5

ííÿ [EAL5 - semiformally veri ed design and tested] п'ятий рiвень гарантiй, призначений для використання в тих випадках, коли розробники або користувачi вимагають високого ступеню незалежного пiдтвердження гарантiй засобiв захисту, а також строгого застосування певних технологiй розробки IТ-продукту, але без надмiрних витрат.

Вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом:

•у роздiлi ВГБ: засоби керування проектом застосування автоматизованих засобiв керування проектом (ACM_AUT.1);

•у роздiлi ВГБ: керування версiями авторизацiя розробникiв при поновленнi версiй (ACM_CAP.4);

•у роздiлi ВГБ: конфiгурацiя проекту включення до скла-

ду конфiгурацi¨ проекту iнструментальних засобiв розробки (ASM_SCP.3).

Óкласi ВГБ: дистрибуцiя:

•у роздiлi ВГБ: поставка виявлення спотворень у процесi поставки (ADO_DEL.2);

•у роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ напiвформальнi специфiкацi¨ для засобiв захисту (ADV_FSP.3);

•у роздiлi ВГБ: архiтектура захисту напiвформальний опис архiтектури захисту (ADV_HLD.3);

•у роздiлi ВГБ: форма надання продукту на сертифiкацiю повний опис реалiзацi¨ усiх засобiв захисту (ADV_IMP.2);

•у роздiлi ВГБ: структура засобiв захисту модульнiсть (ADV_INT.1);

•у роздiлi ВГБ: частковi специфiкацi¨ засобiв захисту неформальнi частковi специфiкацi¨ засобiв захисту (ADV_LLD.1);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня напiвформальне пiдтвердження вiдповiдностi (ADV_RCR.2);

•у роздiлi ВГБ: полiтика безпеки формальна модель полiтики безпеки (ADV_SPM.3).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування

Стандартизованi моделi та методи оцiнки ефективностi захисту	403

засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засо-

бiв захисту (AGD_USR.1).

У класi ВГБ: процес розробки:

•у роздiлi ВГБ: безпека середовища розробки застосування заходiв безпеки в ходi розробки (ALC_DVS.1);

•у роздiлi ВГБ технологiя розробки стандартизована техно-

логiя розробки (ALC_LCD.2);

• у роздiлi ВГБ: засоби розробки використання основ-

них засобiв розробки, що вiдповiдають певним стандартам (ALC_TAT.2).

Óкласi ВГБ: тестування:

•у роздiлi ВГБ: повнота тестування аналiз повноти тестування (ATE_COV.2);

•у роздiлi ВГБ: глибина тестування функцiональнi специфiкацi¨ (ALC_DPT.2);

•у роздiлi ВГБ: методика тестування функцiональне тестування й протоколювання результатiв тестiв (ALC_FUN.1);

•в роздiлi ВГБ: незалежне тестування вибiркове незалежне тестування (ALC_IND.2).

Óкласi ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз прихованих каналiв пошук i документування прихованих каналiв (AVA_CCA.1);

•у роздiлi ВГБ: аналiз можливостей неправильного вико-

ристання засобiв захисту пiдтвердження повноти керiвництв iз адмiнiстрування й безпеки ¨хнього застосування (AVA_MSU.2);

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_SOF.1);

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей

систематичний аналiз уразливостей на основi заданих методик (AVA_VLA.3).

Цей рiвень вимага¹ вiд розробника застосування певних техно-

логiй та методiв розробки, проте, ¨хн¹ використання може обмежуватися проектуванням та реалiзацi¹ю засобiв захисту.

На вiдмiну вiд попереднiх рiвнiв аналiзу пiддаються всi засоби захисту без виключення. Крiм того, необхiдна наявнiсть фор-

404	Ðîçäië 5

мально¨ моделi полiтики безпеки та напiвформальне представлення функцiональних специфiкацiй та архiтектури захисту, а також напiвформальна демонстрацiя ¨хньо¨ вза¹мно¨ вiдповiдностi. Архiтектура IТ-продукту повинна вiдповiдати вимогам модульностi.

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

Вимоги до процесу розробки доповнюються необхiднiстю розширення складу конфiгурацi¨ продукту, керовано¨ за допомогою автоматичних засобiв.

Таким чином, цей рiвень посилю¹ вимоги попереднього в ча- стинi напiвформального опису процесу проектування та реалiзацi¨, бiльш структуровано¨ архiтектури захисту, бiльш ретельного аналiзу схованих каналiв, бiльш повного контролю в процесi розробки.

Напiвформальнi методи верифiкацi¨ розробки та тестування

Рiвень напiвформальних методiв верифiкацi¨ розробки та тестування [EAL6 semiformally veri ed design andtested] шостий рiвень гарантiй, призначений для використання в ситуацiях iз високим ступенем ризику, де цiннiсть iнформацi¨, що захища¹ться, виправдову¹ високi додатковi витрати.

Вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом:

•у роздiлi ВГБ: засоби керування проектом повна автоматизацiя керування проектом i контролю версiй (ACM_AUT.2);

•у роздiлi ВГБ: керування версiями контроль цiлiсностi й автентичностi дистрибутиву системи (ACM_CAP.5);

•у роздiлi ВГБ: конфiгурацiя проекту включення до скла-

ду конфiгурацi¨ проекту iнструментальних засобiв розробки (ASM_SCP.3).

Óкласi ВГБ: дистрибуцiя:

•у роздiлi ВГБ: поставка виявлення спотворень у процесi поставки (ADO_DEL.2);

Стандартизованi моделi та методи оцiнки ефективностi захисту	405

•у роздiлi ВГБ: установка, настройка, запуск регламентованi

процедури установки, настройки, запуску (ADO_IGS.1). У класi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ напiвформальнi специфiкацi¨ для засобiв захисту (ADV_FSP.3);

•у роздiлi ВГБ: архiтектура захисту вiдповiднiсть напiвформального опису архiтектури захисту полiтицi безпеки

(ADV_HLD.4);

• у роздiлi ВГБ: форма надання продукту на сертифiка-

цiю структурований опис реалiзацi¨ усiх засобiв захисту (ADV_IMP.3);

•у роздiлi структура засобiв захисту i¹рархiчнiсть (ADV_INT.2);

•у роздiлi ВГБ: частковi специфiкацi¨ засобiв захисту

напiвформальнi частковi специфiкацi¨ засобiв захисту (ADV_LLD.2);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня напiвформальний доказ вiдповiдностi (ADV_RCR.2);

•у роздiлi ВГБ: полiтика безпеки формальна модель полiтики безпеки (ADV_SPM.3).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: процес розробки:

•у роздiлi ВГБ: безпека середовища розробки пiдтвердження заходiв безпеки в ходi розробки (ALC_DVS.2);

•у роздiлi ВГБ: технологiя розробки стандартизована технологiя розробки (ALC_LCD.2);

•у роздiлi ВГБ: засоби розробки використання тiльки засобiв розробки, що вiдповiдають певним стандартам (ALC_TAT.3)].

Óкласi ВГБ: тестування:

•у роздiлi ВГБ: повнота тестування строгий аналiз повноти тестування (ATE_COV.3);

•у роздiлi ВГБ: глибина тестування функцiональнi специфiкацi¨ (ALC_DPT.2);

406	Ðîçäië 5

•у роздiлi ВГБ: методика тестування тестування у вiдповiдностi з певною методикою (ALC_FUN.2);

•у роздiлi ВГБ: незалежне тестування вибiркове незалежне

тестування (ALC_IND.2).

У класi ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз прихованих каналiв пошук прихованих каналiв на основi певних методiв (AVA_CCA.2);

•у роздiлi ВГБ: аналiз можливостей неправильного використа-

ння засобiв захисту незалежний аналiз можливостей неправильного використання засобiв захисту (AVA_MSU.3);

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_SOF.1);

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей вичерпний аналiз уразливостей (AVA_VLA.4).

Даний рiвень вимага¹ строгого та послiдовного застосування певних методiв проектування та розробки, якi дозволяють забезпечувати гарантi¨ захисту при експлуатацi¨ в умовах пiдвищеного ризику.

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

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

Вимоги до процесу розробки розширюються необхiднiстю структурування цього процесу та повно¨ автоматизацi¨ керування конфiгурацi¹ю проекту.

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

Стандартизованi моделi та методи оцiнки ефективностi захисту	407

Формальнi методи верифiкацi¨ розробки та тестування

Рiвень формальних методiв верифiкацi¨ розробки та тестування [EAL7 formally veri ed design and tested] сьомий рiвень гарантiй, призначений для використання в ситуацiях iз виключно високим ступенем ризику, i (або) там, де цiннiсть об'¹ктiв, якi захищаються, виправдову¹ високi додатковi витрати. Практи- чне застосування цього рiвня на даний час обмежене компактними IТ-продуктами, в яких сконцентрованi засоби захисту, i якi легко пiддаються формальному аналiзу.

Сьомий рiвень гарантiй вiдповiда¹ наступним вимогам гарантiй безпеки.

Óкласi ВГБ: керування проектом:

•у роздiлi ВГБ: засоби керування проектом повна автоматизацiя керування проектом i контролю версiй (ACM_AUT.2);

•у роздiлi ВГБ: керування версiями контроль цiлiсностi й автентичностi дистрибутива системи (ACM_CAP.5);

•у роздiлi ВГБ: конфiгурацiя проекту включення до скла-

ду конфiгурацi¨ проекту iнструментальних засобiв розробки (ASM_SCP.3).

Óкласi ВГБ: дистрибуцiя:

•у роздiлi ВГБ: поставка захист вiд спотворень у процесi поставки (ADO_DEL.3);

•у роздiлi ВГБ: установка, настройка, запуск регламентованi процедури установки, настройки, запуску (ADO_IGS.1).

Óкласi ВГБ: розробка:

•у роздiлi ВГБ: загальнi функцiональнi специфiкацi¨ формальнi специфiкацi¨ для засобiв захисту (ADV_FSP.4);

•у роздiлi ВГБ: архiтектура захисту формальний опис ар-

хiтектури захисту й доказ ¨¨ вiдповiдностi полiтицi безпеки (ADV_HLD.5);

• у роздiлi ВГБ: форма надання продукту на сертифiка-

цiю структурований опис реалiзацi¨ усiх засобiв захисту (ADV_IMP.3);

•у роздiлi ВГБ: структура засобiв захисту мiнiмiзацiя складностi (ADV_INT.3);

•у роздiлi ВГБ: частковi специфiкацi¨ засобiв захисту

408	Ðîçäië 5

напiвформальнi частковi специфiкацi¨ засобiв захисту (ADV_LLD.2);

•у роздiлi ВГБ: вiдповiднiсть описiв рiзного рiвня формальний доказ вiдповiдностi (ADV_RCR.3);

•у роздiлi ВГБ: полiтика безпеки формальна модель полiтики безпеки (ADV_SPM.3).

Óкласi ВГБ: документацiя:

•у роздiлi ВГБ: керiвництво адмiнiстратора адмiнiстрування засобiв захисту (AGD_ADM.1);

•у роздiлi ВГБ: керiвництво користувача використання засобiв захисту (AGD_USR.1).

Óкласi ВГБ: процес розробки:

•у роздiлi ВГБ: безпека середовища розробки пiдтвердження заходiв безпеки в ходi розробки (ALC_DVS.2);

•у роздiлi ВГБ: технологiя розробки технологiя розробки, яка дозволя¹ оцiнювати продукт, що розроблю¹ться (ALC_LCD.3);

•у роздiлi ВГБ: засоби розробки використання тiльки засобiв розробки, що вiдповiдають певним стандартам (ALC_TAT.3).

Óкласi ВГБ: тестування:

•у роздiлi повнота тестування строгий аналiз повноти тестування (ATE_COV.3);

•у роздiлi ВГБ: глибина тестування реалiзацiя (ALC_DPT.3);

•у роздiлi ВГБ: методика тестування тестування у вiдповiдностi з певною методикою (ALC_FUN.2);

•у роздiлi ВГБ: незалежне тестування повне незалежне тестування (ALC_IND.3).

Óкласi ВГБ: оцiнка уразливостей:

•у роздiлi ВГБ: аналiз схованих каналiв пошук схованих каналiв на основi певних методiв (AVA_CCA.2);

•у роздiлi ВГБ: аналiз можливостей неправильного використа-

ння засобiв захисту незалежний аналiз можливостей неправильного використання засобiв захисту (AVA_MSU.3);

•у роздiлi ВГБ: аналiз стiйкостi засобiв захисту оцiнка стiйкостi засобiв захисту (AVA_MSU.3);

•у роздiлi ВГБ: аналiз продукту на наявнiсть уразливостей

вичерпний аналiз уразливостей (AVA_VLA.4).

На вiдмiну вiд попереднiх рiвнiв необхiдне формальне подан-

Стандартизованi моделi та методи оцiнки ефективностi захисту	409

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

Додатково до попереднiх рiвнiв результати аналiзу вимагають пiдтвердження тестуванням форми реалiзацi¨, а також об рунтованим незалежним пiдтвердженням усiх результатiв проведених розробником випробувань.

Таким чином, цей рiвень пiдсилю¹ вимоги попереднього за рахунок бiльш послiдовного аналiзу з використанням формального опису системи на рiзних рiвнях подання та формального доказу вза¹мно¨ вiдповiдностi цих описiв, а також всеохоплюючого тестування.

Ðîçäië 6

Приклади побудови захищених iнформацiйних технологiй

6.1Сучаснi захищенi розподiленi обчислювальнi середовища та ¨х моделi

6.1.1Типовi умови функцiонування розподiлених обчислювальних середовищ з точки зору забезпечення ¨х цiлiсностi

6.1.1.1. Загальнi вiдомостi

Якщо говорити про контроль òà забезпечення цiлiсностi, прийнято видiляти два аспекти проблеми цiлiснiсть даних, якi обробля¹ система та цiлiснiсть власне системи (системна цiлiснiсть). Цiлiснiсть даних призвана забезпечувати ¨х захист вiд несанкцiоновано¨ змiни або руйнування, а системна цiлiснiсть ма¹ справу iз захистом системи вiд уведення ¨¨ в нештатний режим функцiонування.

Íà âiäìiíó âiä забезпечення конфiденцiйностi даних, контроль цiлiсностi ¹ набагато складнiшим завданням, оскiльки рiшення з надання прав доступу до окремих об'¹ктiв системи повиннi враховувати не тiльки наявнiсть дозволiв та заборон доступу до окремих об'¹ктiв системи, але також i характер допустимих змiн цих об'¹ктiв.

Специфiка завдань, де можуть виникнути вимоги iз захисту даних вiд довiльно¨ модифiкацi¨, ¹ залежною вiд порядку доступу користувачiв до об'¹ктiв системи. Як результат, для реалiзацi¨ довiльних обмежень цiлiсностi в унiверсальних компонентах iнформацiйних технологiй необхiдно задавати критерiй цiлiсностi для даних загального виду. Фактична модель цiлiсностi у цьому випад-

Приклади побудови захищених iнформацiйних технологiй	411

ку повинна описувати множину дозволених та заборонених станiв того чи iншого типу. Вiдповiдно, появля¹ться необхiднiсть у реалiзацi¨ в системах асоцiативних правил обмеження цiлiсностi, тобто правил, прив'язаних до семантики об'¹ктiв, що контролюються.

Ще одна проблема поляга¹ у вiдноснiй суперечностi моделей конфiденцiйностi i цiлiсностi, що виключа¹ або обмежу¹ можливiсть ¨х одночасного застосування у системах. Наприклад, обмеження цiлiсностi даних в системах керування базами даних приводить до утворення прихованих каналiв i до порушення вимог конфiденцiйностi.

Виходячи з перелiчених проблем, цiлiснiсть прикладних даних звичайно забезпечу¹ться функцiональними додатками системи. де можна врахувати семантику предметно¨ частини та спростити за рахунок цього механiзми контролю цiлiсностi.

Для переважно¨ бiльшостi систем практичне значення ма¹ системна цiлiснiсть, повязана iз захистом вiд модифiкацi¨ умовно постiйних даних, таких як виконуваний код додаткiв, довiдковi данi, файли конфiгурацi¨. Умовна постiйнiсть поляга¹ у вiдсутностi варiантностi змiнювання даних або станiв контрольовано¨ системи.

Вибiр засобiв контролю та забезпечення системно¨ цiлiсностi визнача¹ться параметрами порушника. Якщо порушник ма¹ ма¹ мiнiмальний рiвень можливостi несанкцiонованого доступу, цiлiснiсть досяга¹ться створенням систем з функцiонально-замкнутим середовищем.

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

6.1.1.2. Системи з функцiонально замкнутим середовищем

Функцiонально замкнутими системами звичайно називають системи з фiксованою технологi¹ю оброблення iнформацi¨. Такi системи характеризуються виконанням наступних обмежень:

•обмежений список задач (програм) i (або) режимiв ¨х викори-

стання, якi iндивiдуальнi для кожного користувача у складi системи;

412	Ðîçäië 6

•забезпечений контроль цiлiсностi критичних файлiв системи

захисту iнформацi¨ операцiйно¨ системи у процесi завантаження операцiйно¨ системи та виключена можливiсть несанкцiонованого завантаження з альтернативного носiя;

•забезпечена гарантована iдентифiкацiя та перевiрка дiйсностi

користувачiв при роботi з системою (як правило, автентифiкацiя викону¹ться до завантаження операцiйно¨ системи);

•виключена модифiкацiя файлiв додатку та даних конфiгурацi¨, у тому числi мережних та адресних настроювань.

Функцiонально замкнуте середовище ¹ некритичним до вiрусних атак, атак троянськими програмами, несанкцiонованого копiювання iнформацi¨. Забезпечення цiлiсностi умовно постiйних даних в таких системах досяга¹ться засобами дискрецiйного управлiння доступом.

Функцiонально замкнуте середовище ЕОМ може бути забезпе- чене засобами системи захисту iнформацi¨ операцiйно¨ системi, за умови виконання наступних вимог до конфiгурацi¨ ЕОМ:

•усi прикладнi програми разом з файлами конфiгурацi¨, дозво-

ленi для користувача, помiщаються у довiренi каталоги (або логiчнi роздiли жорсткого диску ЕОМ;

•до довiрених каталогiв установлюються дозволи доступу, якi

виключають змiни файлiв, що знаходяться в них, а також копiювання файлiв з недовiрених каталогiв;

•на файли в недовiрених каталогах установлюються права доступу, що виключають виконання цих файлiв;

•iз програмного середовища ПЕОМ виключаються засоби роз-

робки та налагодження додаткiв.

Для операцiйних систем та систем захисту iнформацi¨ операцiйних систем, що вiдповiдають вимогам Жовтогарячо¨ книги за класом C2, наприклад, операцiйна система Windows NT, побудова локальних функцiонально замкнутих середовищ ¹ неможливою, оскiльки власники файлiв вправi робити з ними все, що захочуть. Для операцiйно¨ системи Windows NT функцiонально замкнутi середовища на рiвнi домену можна побудувати через системнi полiтики, що призначаються окремим користувачам з урахуванням входження ¨х в локальнi та глобальнi групи. Проте для автономних ПЕОМ та однорангових мереж на основi операцiйно¨ системи

Приклади побудови захищених iнформацiйних технологiй	413

Windows NT системнi полiтики не пiдтримуються.

6.1.1.3. Системи з вiдкритим функцiональним середовищем

Iнодi використання функцiонально замкнутого середовища не може бути оправданим. Наприклад, функцiонально замкнуте середовище недопустиме для роботи користувачiв, що вiдповiдають за експлуатацiю системи та мають доступ до не¨ на рiвнi адмiнiстратора. Модель загроз для тако¨ системи принципово iнша, оскiльки необхiдно мати засоби захисту програмного середовищ вiд вiрусiв та iнших типiв руйнуючих програмних впливiв, що впроваджуються в систему в результатi помилок користувачiв. Захист iнформацi¨ для систем з вiдкритим функцiональним середовищем не можу бути досягнутим тiльки пiдсистемою управлiння доступом та потребу¹ бiльш iнтелектуальних засобiв антивiрусного захисту.

Звичайно антивiрусний захист досяга¹ться комплексним застосуванням наступних методiв контролю цiлiсностi.

Зовнiшнiй контроль цiлiсностi системи захисту iнформацi¨ i програм до завантаження операцiйно¨ системи шляхом розрахунку криптографiчних контрольних сум файлiв даних та програм та порiвняння ¨х з еталонними значеннями. Зовнiшнiй контроль викону¹ться шляхом завантаження операцiйно¨ системи з довiреного носiя та наступного запуску процедур контролю цiлiсностi. База еталонних контрольних сум та програма для ¨х обчи- слення повиннi розташовуватися на зовнiшньому довiреному носi¨ та виключати фальсифiкацiю або пiдмiну. метод гаранту¹ виявлення помилок, але ¹ незручним, оскiльки вимага¹ багато часу для для контролюючих процедур. Iнший недолiк поляга¹ у неможливостi контролювати цiлiснiсть системи мiж перезавантаженнями операцiйно¨ системи. Даний метод звичайно використову¹ться для перiодичного контролю найбiльш криичних даних. у тому числi головного завантажувального запису (mbr), завантажника, додаткiв та найбiльш важливих даних конфiгурацi¨.

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

414	Ðîçäië 6

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

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

Контроль сигнатур руйнуючих програмних впливiв засновуються на пошуку у файлах програм конструкцiй коду, характерного для руйнуючого програмного впливу. Метод дозволя¹ вiдслiдковувати несанкцiоновану модифiкацiю виконуваних файлiв незалежно вiд моменту внесення ¨х у програмне середовище, проте вимага¹ ведення бази даних сигнатур i не дозволя¹ виявляти нетиповi руйнуючi програмнi впливи (сигнатури яких не внесенi до бази даних). Строго кажучи, кожний новий вiрус потребу¹ аналiзу та виявлення характерних елементiв коду, що вносяться в базу даних сигнатур.

Вакцинацiя програм заснована включення у файли характеристичних ознак (прапорiв), що звичайно використовуються вiрусами для опiзнавання заражених програм (тобто програм, у тiло яких уже внесений вiрус i якi не потребують повторного зараження). Даний метод ма¹ тi ж обмеження застосування, що i контроль сигнатур руйнуючих програмних впливiв годиться тiльки для типiзованих вiрусiв. Вакцинацiя програм, окрiм того, може призвести до порушення ¨х роботи, оскiльки алгоритм вакцинацi¨ залежить вiд алгоритму опiзнавання вiрусами власних екземплярiв. Крiм того, рiзних вiрусiв може бути дуже багато i повна вакцинацiя призведе до непомiрного розростання програм.

Контроль системного оточення дозволя¹ виявляти активнiсть програм. що характерна для руйнуючих програмних впливiв. На вiдмiну вiд iнших методiв контролю, системнi монiтори аналiзують звернення програм до функцiй iнтерфейсу прикладних програм [Application Program Interface (API)] операцiйно¨ системи або додаткiв, а не вмiст коду, який припуска¹ велику варiацiю без змiни результату впливу. Системнi монiтори дозволяють

Приклади побудови захищених iнформацiйних технологiй	415

iдентифiкувати типовi впливи, що звичайно виконуються вiрусами (змiна прав доступу, модифiкацiя критичних ключiв ре¹стру в операцiйнiй системi Windows i т.iн.) у момент вторгнення в систему.

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

6.1.1.4. Багаторiвневий контроль цiлiсностi

Аналiз досто¨нств та недолiкiв контролю цiлiсностi для вiдкритого функцiонального середовища дозволя¹ зробити висновок про можливостi групування окремих завдань контролю в зв'язанi процеси з метою забезпечити оперативнiсть виявлення порушень при мiнiмiзацi¨ затрат системи на виконання процедур контролю. Дана задача може бути розв'язана в рамках технологi¨ багаторiвневого контролю цiлiсностi, засновано¨ на наступних принципах:

•видiляються рiвнi функцiонування системи, що характеризую-

ться метою захисту iнформацi¨ та набором критичних параметрiв, упорядкованих за мiрою важливостi;

•для кожного з рiвнiв, виходячи з допустимих затрат системних

ресурсiв, формуються оптимальнi алгоритми (схеми) контролю, а також правила ¨х iнiцiалiзацi¨ (розклад, зовнiшнi подi¨);

•для кожно¨ пари сумiжних рiвнiв функцiонування визначаю-

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

•остаточна класифiкацiя та дiагностика загроз цiлiсностi викону¹ться на найвищому рiвнi.

Послiдовнiсть процедур багаторiвневого контролю iлюстру¹ться на рис. 6.1. Розглянемо приклад визначення цiлей та критичних параметрiв контрольовано¨ системи.

Перший рiвень: мета поляга¹ у забезпеченнi апаратного контролю коректностi функцiонування системи захисту iнформацi¨. Такий контроль може виражатися в перiодичнiй посилцi ядром

416	Ðîçäië 6

Ðèñ. 6.1. Багаторiвневий контроль цiлiсностi

системи захисту iнформацi¨ сигналу контролеру за певним протоколом. При порушення обмежень протоколу апаратний компонент системи захисту iнформацi¨ блоку¹ ЕОМ та сигналiзу¹ користувачу або адмiнiстратору о проблему, що виникла. Набiр (список) критичних параметрiв зада¹ться параметрами згаданого протоколу.

Другий рiвень: мета поляга¹ у перевiрцi вiдповiдностi системних параметрiв конфiгурацi¨ ЕОМ заданому еталону (список обов'язкових процесiв, у тому числi системи захисту iнформацi¨, активнi мережнi шляхи, правила спiвставлення файлiв та ¨х розширень, оброблюваних додаткiв i т.iн.).

Òðåòié ðiâåíü: мета поляга¹ у забезпеченнi вiдповiдностi контрольних сум критичних файлiв (наприклад, файлiв системи захисту iнформацi¨, файлу, що мiстить еталоннi контрольнi суми для iнших файлiв i т.iн.) ¨х еталонним значенням (вони можуть зберiгатися, наприклад, в енергонезалежнiй пам'ятi контроллера системи захисту iнформацi¨).

Четвертий рiвень: мета поляга¹ у забезпеченнi вiдповiдностi контрольних сум користувальницьких файлiв та додаткiв до еталонiв (у даному випадку список критичних параметрiв множина контрольованих користувальницьких файлiв).

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

Введемо наступнi позначення:

Приклади побудови захищених iнформацiйних технологiй	417

A множина контрольованих загроз цiлiсностi;

{Ti} трудомiсткiсть контрольованих процедур кожного рiв-

íÿ;

{P(Si/A)} ймовiрнiсть iндикацi¨ помилки цiлiсностi у списку Si за умови, що мала мiсце загроза з множини A;

{P(Si)} повна ймовiрнiсть iндикацi¨ подi¨ iз списку Si;

Psup допустима ймовiрнiсть гарантованого виявлення загрози в системi;

Tsup допустимий час виявлення загрози в системi;

Tmax допустимi накладнi витрати на виявлення загроз по

часу роботи центрального процесора на певному рiвнi контролю. При введених позначеннях оптимiзацiя багаторiвневого кон-

тролю виража¹ться наступними спiввiдношеннями:

Max{P(Si/A} ≥ Psup;

PP(Si)T(Si) ≤ Tmax;

PT ≤ T .

i sup

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

6.1.2Типовi захищенi розподiленi обчислювальнi середовища

6.1.2.1.Специфiка загроз в розподiлених мережах

Використання розподiлених мереж характеризу¹ться двома важливими моментами. З однi¹¨ сторони, модель захисту мережних пристро¨в дозволя¹ описати лише найбiльш загальнi аспекти полiтики безпеки при роздiлення каналiв зв'язку та комунiкацiйних

418	Ðîçäië 6

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

Проте мережна полiтика не може ефективно вирiшувати проблему роздiлення iнформацiйних ресурсiв. У цiй частинi вона сильно привязана до вимог середовища функцiонування локально¨ обчислювально¨ системи, у тому числi до операцiйних систем та додаткiв мережi. Неможливо побудувати складну багаторiвневу мережу (iнтермережу ), використовуючи лише надiйнi мережнi пристро¨ та шлюзи мiж мережами.

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

костей криптографiчного захисту , а також за рахунок прихованих каналiв) i технiчними каналами (пограничнi мережнi пристро¨, на вiдмiну вiд iншого обладнання локальних обчислювальних мереж, завжди мають виходи за межi контрольовано¨ зони об'¹ктiв).

До друго¨ групи необхiдно включити загрози, для захисту вiд яких необхiдно вибрати профiль механiзмiв захисту залежно вiд конфiгурацi¨ потокiв даних в iнтермережi (топологiя зв'язкiв мiж пiдмережами, складом та характеристиками захищеностi програмного середовища) i моделi порушника.

6.1.2.2. Типовi технологi¨ захисту даних в каналах зв'язку

Побудова захищено¨ iнтермережi ¹ багатопараметричною зада- чею. Для ¨¨ розв'язання вибира¹ться технологiя передавання даних та об рунтовуються способи захисту iнформацi¨ при передаваннi вiдкритими каналами зв'язку. Для цього на основi наявних у розпорядженнi органiзацi¨ (замовника) телекомунiкацiйних ресурсiв (або коштiв, якi можуть бути видiленi пiд створення телекомунiкацiйно¨ iнфраструктури) обмежень, зумовлених мiркуваннями безпеки iнформацi¨, а також виходячи iз специфiки iнформацi¨, що

Приклади побудови захищених iнформацiйних технологiй	419

переда¹ться, вибира¹ться технологiя обмiну даними. Можна розглянути принципи, якими необхiдно керуватися при виборi тако¨ технологi¨.

Насамперед, необхiдно визначитися з прiоритетами, тобто визначити, що для органiзацi¨ ¹ найважливiшим: вартiсть створення системи, безпека iнформацi¨, що циркулю¹ в системi, або , може бути, технологiчна ефективнiсть. Звичайно розглядають наступнi умови, виходячи з яких вибира¹ться технологiя захисту.

Захищена iнтермережа на лiнiйних шифраторах (ðèñ. 6.2). Мережа створю¹ться на базi ненадiйного програмного забез-

Ðèñ. 6.2. Захищена iнтермережа на лiнiйних шифраторах

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

420	Ðîçäië 6

випадках для реально¨ оцiнки рiвня секретностi необхiдно враховувати агрегацiю даних, що важко виконати на практицi.

У розпорядженнi органiзацi¨ або ¹ корпоративнi канали або можлива оренда таких каналiв у оператора. У цьому випадку найбiльш рацiонально використати технологiю шифрування на фiзи- чному рiвнi (лiнiйнi шифратори ). Вза¹модiя кожно¨ пари територiально вiддалених об'¹ктiв здiйсню¹ться по видiленому фiзичному каналу, закритому парою таких шифраторiв, як показано на рис. 6.2. Для мережi з повною з'¹днанiстю об'¹ктiв число шифраторiв ¹ пропорцiйним числу фiзичних каналiв.

Iнтермережа на криптомаршрутизаторах (ðèñ. 6.3). Створю¹ться вiдносно велика iнтермережа з великим числом ко-

Ðèñ. 6.3. Iнтермережа на криптомаршрутизаторах

ристувачiв i нерегулярними iнформацiйними потоками. Мережi, що об'¹днуються будуються на базi недовiрених програм, а оброблення iнформацi¨ викону¹ться засобами унiверсальних обчислювальних платформ. При цьому користувачi можуть приносити i самостiйно запускати програми на сво¨х робочих мiсцях (режим вiдкритого функцiонального середовища).

В мережi необхiдно забезпечити високий рiвень захищеностi та

Приклади побудови захищених iнформацiйних технологiй	421

високу стiйкiсть до одиничних вiдмов.

Для розглянутих умов найбiльш рацiональне рiшення технологiя вiртуальних корпоративних мереж (на канальному або мережному рiвнi, залежно вiд того, якi технiчнi засоби i якi протоколи використовуються для побудови об'¹днуваних мереж об'¹ктiв). При цьому на кожну локальну обчислювальну мережу можна використати один криптомаршрутизатор , не залежно вiд числа мереж об'¹ктiв, що сполучаються, як показано на рис.6.3.

Абонентське шифрування на транспортному рiвнi (ðèñ. 6.4). Для iснуючо¨ телекомунiкацiйно¨ iнфраструктури органiзацi¨

Ðèñ. 6.4. Абонентське шифрування на транспортному рiвнi

необхiдно забезпечити обмiн критичною iнформацi¹ю з видiлених (тобто не усiх) абонентських персональних обчислювальних машин.

Óрозпорядженнi органiзацi¨ ¹ абонентськi пункти та програми

çдостатнiм рiвнем надiйностi, крiм того, для даних абонентських пунктiв можуть бути виконанi технологiчнi обмеження, що виклю- чають впровадження в ПЕОМ закладок та зменшують вплив людського фактору (у бiльшостi варiантiв цi ЕОМ повиннi вiдноситися до функцiонально замкнутих автоматизованих робочих мiсць). У розглянутому варiантi варiантi умов найбiльш придатним рiшення

422	Ðîçäië 6

з органiзацi¨ захищено¨ вза¹модi¨ слiд вважати технологiю абонентського шифрування на транспортному або прикладному рiвнi.

Абонентське шифрування на прикладному рiвнi (ðèñ. 6.5). Органiзацiя ма¹ необхiднiсть епiзодично обмiнюватися кри-

Ðèñ. 6.5. Абонентське шифрування на прикладному рiвнi

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

Приклади побудови захищених iнформацiйних технологiй	423

обмiну зашифрованою iнформацi¹ю каналами зв'язку. Для цього доцiльно видiлити у складi локально¨ обчислювально¨ мережi окрему захищену пiдмережу або розташованi окремо автоматизованi робочi мiсця, не зв'язанi з рештою локально¨ обчислювально¨ мережi. Для електронних обчислювальних машин у захищенiй мережi використовуються тiльки сертифiкованi програми, що дозволяють зашифровувати повiдомлення та помiщати ¨х на захищенi носi¨ (дискети або iнший носiй).

Аналiз телекомунiкацiйних технологiй iз урахуванням розвитку мережi Iнтернет дозволя¹ зробити висновок про те, що найбiльшi перспективи комерцiйного ринку засобiв захисту iнформацi¨ в iнтермережах ¹ у технологi¨ вiртуальних приватних мереж [Virtual Private Network (VPN)]. Саме вона дозволя¹ використати вигоди вiд пакетного режиму передачi iнформацi¨, знизити капiталовкладення компанiй у власнi телекомунiкацiйнi iнфраструктури i одночасно надати надiйний iнструмент для захисту iнформацi¨ в мережах i каналах зв'язку.

6.1.2.3. Вибiр топологi¨ вiртуальних каналiв

Наступним питанням побудови захищено¨ iнтермережi, яке необхiдно вирiшити пiсля вибору технологi¨ захисту даних в каналах зв'язку, ¹ визначення мережно¨ топологi¨. Виконання цього завдання можна розглянути стосовно до технологi¨ вiртуальних приватних мереж.

Спочатку необхiдно визначитися з вибором об'¹ктiв, що вклю- чаються в захищену iнтермережу, i розгорнути та даних об'¹ктах локальнi обчислювальнi мережi з виходом на криптомаршрутизатор вiртуально¨ приватно¨ мережi.

Для об'¹днання пiдмереж в розподiлену iнтермережу в шлюзi кожно¨ тако¨ локально¨ обчислювально¨ мережi необхiдно створити таблицю вiртуальних каналiв та множину маршрутiв, що використовують цi канали для доставки пакетiв мiж захищеними локальними обчислювальними мережами. Маршрути в захищенiй iнтермережi логiчно вiддiленi вiд фiзичних маршрутiв передавання даних через вiдкриту мережу. Тому кожний VPN-шлюз веде вiдразу двi таблицi маршрутизацi¨, одну для передавання даних

424 Ðîçäië 6

мiж вузлами захищено¨ iнтермережi, а iншу для передавання даних через вiдкриту мережу.

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

зашифрування i розшифрування мережних потокiв. Конфiгурацiя вiртуальних каналiв найбiльш важливий та

вiдповiдальний етап побудови захищено¨ розгалужено¨ iнтермережi. Множина вiртуальних каналiв, накладених на локальну обчи- слювальну мережу, що характеризу¹ потоки iнформацi¨ мiж цими локальними обчислювальними мережами через граничний шлюз, назива¹ться топологi¹ю вiртуальних каналiв .

Теоретично для кожно¨ пари вза¹модiючих локальних обчислювальних мереж може бути визначений один або декiлька вiртуальних каналiв, проте такий вибiр не ¹ оправданим iз-за значних витрат на адмiнiстрування та надмiрнiсть по ключам шифрування. Доцiльно мати можливiсть передавання iнформацi¨ одночасно через два i бiльше вiртуальних каналiв.

Залежно вiд способу призначання вiртуальних каналiв для обмiну iнформацi¹ю по рiзним напрямках можуть бути видiленi наступнi типовi топологi¨:

•повнозв'язна топологiя;

•радiальна топологiя;

•кiльцева топологiя;

•змiшана топологiя.

Повнозв'язна топологiя використову¹ мiж кожною парою локальних обчислювальних мереж iнтермережi меншою мiрою по одному вiртуальному каналу. Така топологiя ма¹ наступнi переваги:

•найбiльш високий рiвень безпеки при передаваннi пакетiв мiж

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

•завантаження криптомаршрутизаторiв не залежить вiд числа

Приклади побудови захищених iнформацiйних технологiй	425

транзитних вузлiв, через якi передаються данi в iнтермережi. Повнозв'язна топологiя забезпечу¹ бiльшу продуктивнiсть, якщо вузьким мiсцем ¹ пiдсистема шифрування;

• забезпечу¹ найбiльш високу стiйкiсть доставки пакетiв, оскiль-

ки на кожному напрямку обмiну використову¹ться ¹диний вiртуальний канал.

При перелiчених перевагах повнозв'язнi топологi¨ характеризуються рядом недолiкiв, серед яких:

•великi адмiнiстративнi витрати на настроювання та супрово-

дження вiртуальних каналiв у складнiй iнтрамережi, що мiстить десятки та сотнi пiдмереж. Складнiсть структури вiртуальних каналiв iз зазначеною топологi¹ю зроста¹ пропорцiйно квадрату числа захищених пiдмереж;

•нерацiональна витрата ключiв, що пiдвищу¹ експлуатацiйнi ви-

трати, оскiльки процедура генерацi¨ та розподiлу ключiв зви- чайно сполучена з органiзацiйними складностями. Повнозв'язна топологiя добре пiдходить для мереж, де полiти-

ка безпеки не дозволя¹ розсекречування транзитного трафiку на маршрутах доставки пакетiв, а також для мереж з рiвномiрним розподiлом трафiку в адресному просторi iнтермережi.

Радiальна топологiя (топологiя типу зiрка ) видiля¹ центральну локальну обчислювальну мережу, що об'¹дну¹ потоки даних вiд iнших (пiдпорядкованих) локальних обчислювальних мереж. До числа переваг радiально¨ топологi¨ слiд вiднести:

•мiнiмальну складнiсть настроювання криптомаршрутизаторiв

iнтермережi i, отже, найбiльш низькi витрати при адмiнiструваннi. Для пiдпорядкованих об'¹ктiв достатньо настро¨ти один вiртуальний канал. Трудомiсткiсть адмiнiстрування лiнiйно зроста¹ з ростом числа з ростом числа пiдмереж iнтермережi, що пiдляга¹ захисту;

•найбiльш економне використання ключiв шифрування, оскiль-

ки число вiртуальних каналiв ¹ мiнiмiзованим. Число ключiв зроста¹ лiнiйним чином залежно вiд числа локальних обчислювальних мереж, що сполучаються в iнтермережу;

•об'¹кти вза¹модi¨ локалiзованi в центральнiй локальнiй обчи-

слювальнiй мережi i, отже, при доставцi пакетiв використову¹ться не бiльше двох комутацiй пакетiв (транзитних вузлiв).

426	Ðîçäië 6

При перелiчених перевагах радiальнiй топологi¨ властивi наступнi недолiки:

•найбiльш високий рiвень завантаження пiдсистеми шифрува-

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

•бiльш низька ефективнiсть доставки пакетiв завдяки наявно-

стi транзитного вузла на маршрутах мiж локальними обчислювальними мережами iнтермережi;

•вiдмова зв'язку при виходi з ладу криптомаршрутизатора центрально¨ локально¨ обчислювально¨ мережi.

Радiальна топологiя ¹ прийнятною для iнтермереж, де потрiбний високий рiвень захисту, а iнформацiйнi ресурси локалiзованi в центральному об'¹ктi. При цьому не потрiбне використання двох вiртуальних каналiв, навантаження на систему шифрування зменшу¹ться i данi не розсекречуються на промiжних вузлах iнтермережi. Забезпечення надiйного зв'язку потребу¹ резервування центрального криптомаршрутизатора. Для прискорення обмiну даними основнi та i резервнi криптомаршрутизатори можуть паралельно обробляти запити вiд вiддалених об'¹ктiв.

Кiльцева топологiя (топологiя кiльце ) визнача¹ спосiб циклiчно¨ вза¹модi¨ вузлових криптомаршрутизаторiв, при якому кiнцевий маршрут по вiртуальних каналах явля¹ собою замкнуте (або розiмкнуте) кiльце. До числа переваг дано¨ топологi¨ вiдносяться:

•висока захищенiсть та стiйкiсть до вiдмов будь-якого ретранс-

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

•найбiльше стiйка до вiдмов конфiгурацiя при одиночних вiдмовах з рiвномiрною мiрою ¨х локалiзацi¨;

•невелика трудомiсткiсть адмiнiстрування. Фактично на кожному об'¹ктi необхiдно мати по два вiртуальних канали на кожну

Приклади побудови захищених iнформацiйних технологiй	427

групу застосувань (один в прямому i один у зворотному напрямку);

•економнi витрати ключiв (по два набори на кожний криптомаршрутизатор).

При перелiчених недолiках топологiя кiльце характеризу¹ться наступними недолiками:

•низька захищенiсть iнформацi¨ в iнтермережi внаслiдок вели-

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

•високе завантаження криптомаршрутизаторiв внаслiдок додаткового транзитного трафiку;

•значна затримка доставки пакетiв, так як загальне число тран-

зитних шлюзiв мiж парою захищених пiдмереж ¹ пропорцiйним до числа вузлових маршрутизаторiв. Виключення склада¹

випадок, коли фiзична топологiя мережi передавання даних, також як i логiчна, вiдповiдають кiльцевiй схемi.

Топологiю кiльце можна рекомендувати для побудови iнтермережi рiвного доступу, коли:

•запити на передавання даних рiвноймовiрнi на усьому протсорi адрес iнтермережi (телеконференцзв'язок);

•рiвень загального завантаження в iнтермережi ¹ невисоким (не призводить до перевантаження криптомаршрутизаторiв);

•бажано забезпечити високу стiйкiсть до вiдмов за мiнiмальних додаткових ресурсiв зв'язку.

Iнодi для вибору оптимально¨ топологi¨ вiртуальних каналiв можна комбiнувати розглянутi елементарнi топологi¨. При цьому спосiб комбiнування визнача¹ться тими властивостями. якi необхiдно досягнути.

Для усунення недолiкiв повнозв'язно¨ топологi¨ при великiй кiлькостi вузлiв можна розбити iнтермережу на домени, в яких використову¹ться повнозв'язна топологiя. Для зв'язку мiж доменами можна використовувати кiльцеву або радiальну топологiю.

Для усунення недолiкiв радiально¨ топологi¨ при органiзацi¨ доступу до загальних ресурсiв однi¹¨ локально¨ обчислювально¨ мережi можна видiлити два i бiльше рiвнiв концентрацi¨ мережного навантаження (i¹рархiчна топологiя).

Для усунення недолiкiв кiльцево¨ топологi¨ ¨¨ можна комбiну-

428	Ðîçäië 6

вати з радiальною топологi¹ю. Домени з радiальною топологi¹ю об'¹днуються в кiльце (централiзована магiстраль).

 òàáë. 6.1 наведений порiвняльний аналiз характеристик рiзноманiтних топологiй. Оптимальний вибiр топологiй вiртуальних каналiв при проектуваннi iнтермережi повинен здiйснюватися на основi компромiсу мiж складнiстю експлуатацi¨, продуктивнiстю та та зниженням захищеностi iнформацi¨. Для практичного вибору

Òàáë. 6.1 Порiвняльний аналiз рiзних топологiй

Характеристики	Типи топологiй
	Повнозв'язна	Çiðêà	Êiëüöå
Захищенiсть обмiну	Висока	Середня	Низька
Íàäiéíiñòü îáìiíó	Висока	Низька	Висока
Завантаження маршрутизаторiв	Низьке	Високе	Низьке
Завантаження шифраторiв	Низьке	Високе	Високе
Складнiсть настроювання	Висока	Низька	Низька
Витрати ключiв	Високi	Низькi	Низькi

топологi¨ звичайно рекомендують використати наступну методику. За результатами дослiдження iнтермережi визначають вихiднi данi з напрямкiв обмiну iнформацi¹ю з урахуванням можливих подальших розширень. Дану iнформацiю зручно групувати у формi табл.6.2, ¾+¿ означа¹. що мiж парою об'¹ктiв встановленi вiдносини довiри, а ¾ ¿ у протилежному випадку. Вiдносини довiри не ¹ симетричними, тобто дозвiл транзиту трафiку в одному вузлi для абонентiв iншого вузла не означа¹, що мають мiсце зворотнi

вiдносини довiри.

У роздiлi Довiренi транзитнi пiдмережi указуються локальнi обчислювальнi мережi, в яких дозволя¹ться розшировування пакетiв, що передаються (комутацiя вiртуальних каналiв). Для кожно¨ пари об'¹ктiв необхiдно також указати множину довiрених локальних обчислювальних мереж, у яких допустиме розшифрування по кожному напрямку обмiну. Множина довiрених локальних обчи- слювальних мереж вибира¹ться вiдповiдно до полiтики безпеки iнтермережi.

Дальше для кожно¨ пари вза¹модiючих локальних обчислю-

Приклади побудови захищених iнформацiйних технологiй	429

Òàáë. 6.2 Результати дослiдження iнтермережi

ËÎÌ		Пропускна	Довiренi транзитнi ЛОМ
Lan I	Lan J	здатнiсть	1	2	3	.........	N
Lan 1	Lan 2	C12	-(+)	-(+)	-(+)	........	-(+)
Lan 1	Lan 3	C13	-(+)	-(+)	-(+)	........	-(+)
.......	.......	.......	......	......	......	........	......
Lan 1	Lan N	C1N	-(+)	-(+)	-(+)	........	-(+)
Lan 2	Lan 3	C23	-(+)	-(+)	-(+)	........	-(+)
Lan 2	Lan 4	C24	-(+)	-(+)	-(+)	.......	-(+)
.......	.......	......	......	.....	.....	.......	.....
Lan N-1	Lan N	CN−1N	-(+)	-(+)	-(+)	-(+)	-(+)

вальних мереж необхiдно визначити оптимальний маршрут передавання пакетiв у наступному виглядi:

R[I, J]opt = {LanI, LanI1, LanI2, ..., LanJ}.

Ïiä R[I, J]opt слiд розумiти послiдовнiсть вузлових криптомар-

шрутизаторiв при проходженнi пакетiв через iнтермережу, для яко¨ пропускна здатнiсть або час гарантовано¨ доставки будуть мiнiмальними. оптимальному маршруту буде вiдповiдати множина вiртуальних каналiв мiж вiдповiдними вузловими маршрутизаторами. Тобто:

R[I, J]opt = BK(LanI, LanI1), BK(LanI1, LanI2), ..

.., BK(LanIk, LanJ),

äå k кiлькiсть транзитних вузлiв на маршрутi. Для вибору опти-

мального маршруту використовуються ймовiрнiсно-часовi характеристики каналiв iнтермережi. Розрахунок цих характеристик та вибiр оптимального маршруту здiйсню¹ться з урахуванням вiдображення потокiв даних вiртуальних каналiв у реальний трафiк вiдкритих мереж та каналiв зв'язку.

Якщо в iнтермережi плану¹ться робота протоколiв динамiчно¨ маршрутизацi¨, для обчислення оцiнки якостi маршрутiв можна використати ¨х середнi або граничнi значення з числа досяжних.

430	Ðîçäië 6

Для визначення результуючо¨ топологi¨ вiртуальних каналiв необхiдно об'¹днати вiртуальнi канали для усiх оптимальних мар-

øðóòiâ R[I, J]opt по усiх напрямках вза¹модi¨ мiж об'¹ктами (I i J).

Сукупнiсть вiртуальних каналiв утворю¹ оптимальну топологiю iнтермережi. Пiсля визначення оптимально¨ топологi¨ вiртуальних каналiв необхiдно сформувати вимоги до настройки кожного вузлового криптомаршрутизатора.

6.1.2.4. Розмежування мiжмережно¨ вза¹модi¨

На завершальному етапi побудови iнтермережi в межах уже створено¨ структури зв'язкiв мiж об'¹ктами необхiдно обмежити мiжмережну вза¹модiю мiж окремими локальними обчислювальними мережами, що входять до iнтермережi. Виконання цього завдання залежить вiд встановлених режимiв обробки iнформацi¨ та типiв порушникiв, присутнiх у мережi.

Недовiрене функцiональне середовище

Якщо в мережах, що сполучаються, викону¹ться оброблення iнформацi¨ з використанням недовiрених засобiв, бiльшiсть механiзмiв мiжмережного екранування стають даремними, адже порушник, використовуючи придатнi програми, легко сформу¹ мережнi запити, що задовольняють будь-яким обмеженням мережно¨ полiтики, у тому числi дозволеним адресам, мiткам безпеки, iдентифiкаторам вiртуальних з'¹днань i т.iн. Для таких мереж можуть стати корисними механiзми, що реалiзують полiтику безпеки на рiвнi порту мережного пристрою. Усi ЕОМ, при¹днанi до локально¨ обчислювально¨ мережi через такий порт, стають рiвнозначними, а рiшення з фiльтрацi¨ запитiв приймаються виходячи тiльки тiльки з того, на який мережний iнтерфейс поступив даний запит i куди вiн адресований.

У випадку якщо у складi локально¨ обчислювально¨ мережi можна видiлити одну або декiлька ЕОМ з довiреним середовищем функцiонування, можуть стати корисними запити iз застосуванням автентифiкацi¨, стiйко¨ до спроб перехоплення паролiв з локальних обчислювальних мереж (наприклад, автентифiкацiя

Приклади побудови захищених iнформацiйних технологiй	431

застосувань за протоколом SOCKS). На жаль, абсолютну надiйнiсть такi механiзми не забезпечують, оскiльки перехоплення активного з'¹днання порушником може бути виконаним уже пiсля автентифiкацi¨.

Бiльш надiйний варiант автентифiкацiя з видаванням сеансових ключiв шифрування для iндивiдуального захисту даних у кожному користувальницькому з'¹днаннi (наприклад, за протоколом KERBEROS). За тако¨ автентифiкацi¨ ста¹ можливим надiйно iзолювати потоки даних пiсля перевiрки користувальницького запиту на вiдповiднiсть полiтицi безпеки. Даний метод ¹ незалежним вiд VPN-технологi¨ i може бути реалiзований як самостiйний сервiс в локальнiй обчислювальнi мережi.

Для захисту даних вiд витоку у зовнiшнi канали за рахунок модуляцi¨ довжин пакетiв та тривалостi мiжпакетних iнтервалiв, необхiдно використати лiнiйнi шифратори, або включити механiзми маскування трафiку для вiртуальних каналiв, якi обслуговують локальнi обчислювальнi мережi з недовiреним обладнанням та програмами. Виняток склада¹ той випадок, коли мережнi ЕОМ при¹днуються до шлюзу не прямо, а через промiжну систему, що викону¹ буферизацiю та перетворення даних. Прикладом тако¨ системи може служити поштовий сервер органiзацi¨.

Вiдкрите функцiональне середовище

Якщо в iнтермережi використовуються довiренi операцiйнi системи, то оброблення iнформацi¨ здiйсню¹ться у режимi вiдкритого функцiонального середовища, розмежування доступу може виконуватися на рiвнi окремих мережних ЕОМ, оскiльки iнформацiя iз службового заголовку пакетiв форму¹ться у довiреному середовищi та придатна для надiйних реалiзацiй iз фiльтрацi¨ в шлюзах iнтермережi.

Здiйснивши мережне екрануванням можна дозволити окремим користувачам доступ до певних мережних сервiсiв, що надаються по зовнiшнiх адресах. Якщо операцiйнi системи пiдтримують режим багаторiвнево¨ обробки в локальнi обчислювальнi мережi, фiльтрацiя за грифами та категорiями iнформацi¨, що обробля¹ться, дозволить спiльно використати одну канальну iнфрастру-

432	Ðîçäië 6

ктуру для для передавання даних iзольованими потоками, тобто не дозволить змiшуватися пакетам з рiзними мiтками безпеки. При цьому в мережi не потрiбно застосовувати криптографiчнi методи роздiлення даних (як у випадку недовiреного середовища). У протилежному випадку усi мережнi ЕОМ, доступнi через даний мережний iнтерфейс повиннi бути рiвномiрно класифiкованi, тобто мати одну й ту ж мiтку безпеки, яка признача¹ться усiм пакетам, що перетинають границю ЛОМ.

Вимоги з маскування трафiку зберiгаються i для режиму вiдкритого функцiонального середовища, оскiльки таке середовище припуска¹ впровадження в систему вiрусiв та троянських програм.

Замкнуте функцiональне середовище

Якщо в iнтермережi обробля¹ться iнформацiя в режимi замкнутого функцiонального середовища, практично усi необхiднi механiзми дискрецiйно¨ фiльтрацi¨ можуть бути реалiзованi застосуваннями кiнцевих систем. Для такого режиму мiжмережне екранування повинно розглядатися як додатковий засiб захисту з бiльш високими гарантiями, оскiльки полiтику мережно¨ вза¹модi¨ бiльш легко контролювати централiзовано, нiж на кiнцевих системах.

Якщо мережна iнфраструктура, що створю¹ться, використову¹ться застосуваннями, що реалiзують локальнi мандатнi полiтики, то застосування фiльтрацi¨ за мiтками безпеки дозволя¹ унiфiкувати правила передачi пакетiв загальними багаторiвневими каналами зв'язку.

Як приклад можна навести ситуацiю, коли окремi канали використовуються для передавання не вище гранично заданого грифу секретностi або визначено¨ категорi¨ секретностi. Маркування пакетiв допоможе вибрати придатний маршрут доставки пакетiв через складну мережу, не дозволяючи даним проходити каналами, що не ¹ авторизованими для передавання iнформацi¨ високого рiвня секретностi.

На вiдмiну вiд режимiв з недовiреним та вiдкритим середовищем, механiзми маскування трафiку можуть не використовуватися, оскiльки у замкнутому функцiональному середовищi виключа-

Приклади побудови захищених iнформацiйних технологiй	433

¹ться можливiсть вбудовування в систему недекларованих можливостей (передавача прихованого каналу) на рiвнi застосувань.

6.1.3 Механiзми аудиту

Управлiння доступом та контроль цiлiсностi форму¹ основний iнструмент полiтики безпеки для систем з вiдносно незмiнним середовищем, оскiльки такi системи не ¹ критичними о впливу випадкових факторiв (рiзноманiтних помилок на неузгоджених дiй користувачiв, що розглядаються як загрози). Проте для бiльшостi реальних систем незмiннiсть середовища не ¹ характерною. В таких системах постiйно здiйснюються змiни, приходять та йдуть новi спiвробiтники, оновлю¹ться програмне забезпечення, змiню¹ться структура системи.

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

Механiзми аудиту виконують збiр статистики доступу користувачiв у систему та надання адмiнiстратору зручних засобiв для ¨¨ аналiзу з метою виявлення вiдхилень вiд правильно¨ поведiнки системи

Аудит нада¹ системi властивостi спостережностi та прозоростi. можна розглянути наступнi кориснi та найбiльш розповсюдженi галузi застосування механiзмiв аудиту в реальних системах.

Прогнозування несанкцiонованого доступу

Несанкцiонований доступ до ресурсiв звичайно здiйсню¹ться к два етапи. На першому етапi порушник збира¹ iнформацiю про систему, яку збира¹ться атакувати. вона допомага¹ йому знайти слабкi мiсця у захистi iнформацi¨. На другому етапi, пiсля вибору прийнятного сценарiю та iнструментальних засобiв, здiйсню¹ться атака. Дi¨ порушника на першому етапi (такi дi¨ часто називають комп'ютерною розвiдкою або скануванням) не ¹ типовими для роботи звичайних користувачiв и можуть бути виявленi адмiнiстратором до спроби атаки. Збiр системно¨ статистики дозволя¹ скла-

434	Ðîçäië 6

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

Розслiдування фактiв несанкцiонованого доступу

Статистика, що створю¹ться засобами аудиту, дозволя¹ збирати матерiал для розслiдування окремих фактiв несанкцiонованого доступу з метою пошуку порушникiв, аналiзу iнцидентiв та усунення повторного прояву порушень у подальшому. Дана статистика, будучи цiнним матерiалом для служб безпеки, повинна ретельно оберiгатися вiд знищення або несанкцiоновано¨ модифiкацi¨ порушником, що замiта¹ слiди сво¹¨ присутностi.

Iдентифiкацiя профiлю системи

Iнодi засоби ре¹страцi¨ дозволяють сформувати уявлення про параметри конфiгурацi¨ системи захисту iнформацi¨ системи. Це можна використати для настройки системи безпеки при роботi користувачiв у режимi замкнутого функцiонального середовища. Iнодi у зовнiшнiх засобах захисту iнформацi¨ операцiйна система використову¹ два режими функцiонування: штатний i технологi- чний. При роботi системи захисту iнформацi¨ в технологiчному режимi доступ у систему мають тiльки довiренi користувачi. За результатами роботи системи захисту iнформацi¨ в технологiчному режимi визнача¹ться типовий профiль розмежування доступу, що використову¹ться для конфiгурацi¨ системи захисту iнформацi¨ при штатному режимi роботи.

Контроль доступу до iнформацi¨

Полiтика управлiння доступом не розрiзня¹ користувачiв, що фактично мали доступ до iнформацi¨, i користувачiв, що мають

Приклади побудови захищених iнформацiйних технологiй	435

формальне право доступу до iнформацi¨. Iнодi таке роздiлення ¹ принципово необхiдним. Наприклад, доступ до файлiв користува- чiв небажано надавати адмiнiстраторам, проте при цьому необхiдно дати ¨м можливiсть виконувати сво¨ службовi обов'язки iз супроводу системи. Проблема вирiшу¹ться шляхом уведення пiдзвiтностi дiй адмiнiстратора, що фiксуються в журналах аудиту. Само собою, адмiнiстратор при цьому не повинен мати можливостi модифiкацi¨ журналiв, власником яких ¹ адмiнiстратор безпеки. Iнший приклад автоматизацiя секретного дiловодства, де будьякий доступ до секретних вiдомостей пiдляга¹ обов'язковiй ре¹страцi¨ з наданням гарантованих посвiдчень про ознайомлення з цими вiдомостями.

Контроль помилок користувачiв

Ре¹страцiя критичних дiй користувачiв системи дозволя¹ виявити помилки в конфiгурацi¨ системи захисту iнформацi¨ та оперативно ¨х виправляти. Ефективнiсть контролю буде вищою при виконаннi функцiй адмiнiстрування та контролю рiзними посадовими особами. У реальних системах часто використовуються двi адмiнiстративнi вертикалi, одну з яких представля¹ експлуатацiйна служба, а iншу служби безпеки.

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

6.1.3.1. Види аудиту

Розглянемо класифiкацiю ре¹страцi¨ (аудиту) в захищених системах, яка наведена в табл.6.3.

За способом реалiзацi¨ в системнiй архiтектурi звичайно видiляють зовнiшнiй i внутрiшнiй аудит. Механiзми внутрiшнього аудиту вбудовуються в систему захисту iнформацi¨ та реалiзуються

436 Ðîçäië 6

Òàáë. 6.3 Класифiкацiя механiзмiв аудиту

Ознаки класифiкацi¨	Характеристика ознак класифiкацi¨
За ступенем оперативностi	Аудит реального часу	Вiдкладений аудит
За цiльовими ознаками	Функцiональний аудит	Аудит об'¹ктiв
За способом реалiзацi¨	Зовнiшнiй аудит	Внутрiшнiй аудит

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

За характеристиками оперативностi аудит дiлиться на аудит реального часу та вiдкладений аудит. Аудит реального часу використову¹ться для негайного оповiщення адмiнiстратора i (або) користувача системи про подi¨, що вiдбулися (наприклад, при виявленнi вiрусах у застосуваннях). Вимоги до механiзмiв аудиту

óреальному часi пред'являються для систем оброблення секретно¨ iнформацi¨. Аудит реального часу може використовуватися для вiдносно невелико¨ кiлькостi подiй, до яких пред'являються наступнi вимоги:

•високий рiвень критичностi, що визнача¹ необхiднiсть прийняття негайних заходiв iз усунення загроз;

•високий рiвень вибiрковостi, що виража¹ться у пiдвищеннi до-

стовiрностi прив'язки подiй до певно¨ загрози в системi. Вiдкладений аудит у бiльшiй мiрi призначений для погли-

бленого аналiзу стану захищеностi системи.

За характеристиками об'¹кта ре¹страцi¨ звичайно видiляють функцiональний та об'¹ктний аудит. Аудит на рiвнi об'¹ктiв призначений для вiдслiдковування доступу до системи на рiвнi окремого об'¹кта або ресурсу. Наприклад, в операцiйнiй системi WINDOWS NT аудит на рiвнi об'¹ктiв дозволя¹ фiксувати доступ до

Приклади побудови захищених iнформацiйних технологiй	437

файлiв до файлiв, каталогiв та принтерiв. Аудит на рiвнi об'¹ктiв у бiльшiй мiрi придатний для систем з вiдкритим функцiональним середовищем.

Функцiональний аудит призначений для ре¹страцi¨ доступу користувачiв до певних системний та прикладних функцiй (задач) та придатний для систем iз замкнутим функцiональним середовищем (коли ¹ важливим не доступ до певного файлу або ресурсу, а виконання користувачем конкретного завдання в системi). Су- часнi операцiйнi системи та системи управлiння базами даних, як правило, мають засоби для аудиту двох типiв. Наприклад, в операцiйнiй системi WINDOWS NT ¹ три журнали безпеки: SYSTEM, APPLICATION i SECURITY. Першi два журнали у цiлому виконують роль функцiонального аудит, у той час як останнiй журнал використову¹ться пiдсистемою об'¹ктного аудиту.

6.1.3.2. Системи виявлення атак

Одним з найперспективнiших напрямкiв у галузi забезпечення безпеки iнформацi¨ розподiлених систем ¹ система виявлення атак IDS (Intrusion Detection System). Основна iдея, покладена в основу цього напрямку засобiв захисту, поляга¹ у злиттi механiзмiв зовнiшнього аудиту i механiзмiв контролю цiлiсностi окремих компонентiв системи, що дозволя¹ IDS автоматично розпiзнавати атаки на ресурси (зовнiшнiй аудит на рiвнi системи) i оперативно на них реагувати (контроль цiлiсностi).

Iснуючi сьогоднi на ринку комерцiйнi системи виявлення атак на мережному або системному рiвнi [47]. Принципи дi¨ IDS системного та мережного рiвня загалом ¹ iдентичними i заснованi на виявлення специфiчно¨ активностi користувачiв, що свiдчать про порушення безпеки. Вiдмiннi поляга¹ в типах контрольованих ресурсiв. Для системних IDS контролю пiддаються ресурси операцiйних систем та застосувань, такi як наприклад, час роботи центрального процесора, системнi змiннi. IDS системного рiвня займа¹ться контролем мережних потокiв на нижнiх рiвням еталонно¨ моделi вза¹модi¨ вiдкритих систем з метою виявлення в мережних пакетах характерних сигнатур загроз.

438	Ðîçäië 6

Кожний пiдхiд ма¹ сво¨ переваги та недолiки, але вони обидва доповнюють один одного, забезпечуючи кращу якiсть контролю.

Можливi варiанти реакцi¨ на атаки, що виявляються, ¹ визна- чальними для будь-яко¨ системи виявлення атак. Такi варiанти можна роздiлити на три типи: сповiщення, запам'ятовування та активна реакцiя (наприклад, блокування системи), завершення роботи користувача та iншi дi¨. Залежно вiд полiтики безпеки системи використовуються рiзнi варiанти реакцi¨.

IDS системного рiвня

Сучаснi системи виявлення атак системного рiвня використовуються для аналiзу уже виконаних атак i визначення вiдповiдних методiв для усунення можливостей ¨х майбутнього застосування. Для цi¹¨ роботи IDS системного рiвня використовують журнали аудиту, що надаються операцiйною системою та додатками системи.

IDS системного рiвня буду¹ться на базi двох архiтектур автономна система i система агент-менеджер . Перша архiтектура найбiльш проста i на даний момент в комерцiйних системах практично не використову¹ться. Системи, побудованi на ¨¨ основi, установлюються на кожний контрольований комп'ютер. При цьому зв'язку мiж системами, встановленими на рiзних комп'ютерах нема, нема, а адмiнiстратору безпеки необхiдно або завантажувати журнали ре¹страцi¨ системи виявлення атак (IDS) на сво¹ автоматизоване робоче мiсце (АРМ) за допомогою iнших засобiв, або аналiзувати цi журнали на кожнiй ЕОМ мережi.

Очевидно, що у великих, територiально розподiлених мережах така архiтектура не ¹ прийнятною. Проте ¨¨ можна використати для захисту окремих ЕОМ, що не об'¹нанi в ¹дину обчислювальну мережу. Архiтектура система агент-менеджер ¹ бiльш ефективною для сучасних мереж, оскiльки iнформацiя про подi¨, що ре¹струються агентами на кожнiй ЕОМ, що контролю¹ться, переда¹ться на центральний компонент (менеджер).

IDS системного рiвня постiйно розвиваються, включаючи все новi та новi методи виявлення. Сво¹часнiсть реагування на виявленi загрози безпосередньо зв'язана з частотою опитування си-

Приклади побудови захищених iнформацiйних технологiй	439

стемних журналiв. Деякi системи прослухають активнi порти та та сповiщають адмiнiстратора, коли дехто пробу¹ одержати до них доступ. Такий тип виявлення вносить в операцiйне середовище елементарний рiвень виявлення атак на мережному рiвнi. Системи виявлення атак системного рiвня не настiльки швидкодiючi, як ¨хнi аналоги мережного рiвнi, але мають переваги, яких не мають останнi. Можна розглянути цi переваги.

Оскiльки IDS системного рiвня використовують журнали ре¹страцi¨, що мiстять данi про подi¨. що дiйсно мали мiсце, то IDS цього класу можуть з високою точнiстю визначать чи дiйсно атака була успiшною чи нi. У цьому вiдношеннi IDS системного рiвня добре доповню¹ система виявлення атак мережного рiвня. Кiнець-кiнцiв, спiльне використання IDS системного та мережного рiвня забезпечують ранн¹ попередження атак за допомогою мережного компонента та iдентифiкують успiшнi атаки за допомогою системного рiвня.

IDS системного рiвня контролю¹ роботу користувача, доступ до файлiв, змiну прав доступу до файлiв, спроби установки нових програм i/або спроби одержати доступ до привiлейованих сервiсiв. Наприклад, IDS системного рiвня може контролювати вхiд i вихiд в систему, а також дi¨, що виконуються при при¹днаннi до системи. Для системи мережного рiвня дуже важко забезпечити такий рiвень деталiзацi¨ подiй. Технологiя виявлення атак на системному рiвнi також може контролювати дiяльнiсть адмiнiстраторiв. Операцiйнi системи ре¹струють будь-яку подiю, при якiй додаються, видаляються або змiнюються облiковi записи користувачiв. IDS системного рiвня можуть виявляти вiдповiдну змiну вiдразу, як тiльки вона вiдбува¹ться. IDS системного рiвня можуть також здiйснювати аудит змiн полiтики безпеки, якi впливають на те, як системи вiдслiдковують сво¨ журнали ре¹страцiй i т.iн. Кiнець-кiнцiв виявлення атак на системному рiвнi контролю¹ змiни в ключових системних файлах та файлах, що виконуються.

IDS системного рiвня можуть виявляти атаки, якi не можуть бути виявленими засобами мережного рiвня. Наприклад, атаки з сервера, що атаку¹ться, не можуть бути виявленими засобами виявлення атак мережного рiвня, оскiльки у даному випадку мережна вза¹модiя або взагалi не використову¹ться, або використову-

440	Ðîçäië 6

¹ться без порушень полiтики.

IDS системного рiвня встановлю¹ться на ЕОМ и може усувати обмеження, що виникають при експлуатацi¨ систем мережного рiвня в мережах з комутацi¹ю та шифруванням.

Комутацiя дозволя¹ управляти великомасштабними мережами як декiлькома невеликими мережними сегментами. У результатi важко визначити найбiльш краще мiсце для установки IDS мережного рiвня. Iнодi можуть допомогти адмiнiстративнi порти [manager port] i порти вiдбиття [mirror ports, span ports] трафiку на комутаторах, але цi методи не завжди можна застосувати. Виявлення атак на системному рiвнi забезпечу¹ бiльш ефективну роботу в комутованих мережах, оскiльки дозволя¹ розташувати IDS тiльки та тих вузлах, на яких це необхiдно. Залежно вiд того, де використову¹ться шифрування (канальне або абонентське), IDS мережного рiвня може залишатися слiпою до певних атак. IDS системного рiвня не мають цього обмеження. До того ж операцiйна система i, отже, IDS системного рiвня аналiзують розшифрований вхiдний трафiк.

При правильному застосуваннi IDS атаки на системному рiвнi можуть вiдслiдковуватися майже у реальному масштабi часу. На вiдмiну вiд застарiлих систем, якi перевiряють статус та змiст журналiв ре¹страцi¨ через наперед визначенi iнтервали, багато су- часних IDS системного рiвня одержують переривання вiд операцiйно¨ системи, як тiльки з'явля¹ться новий запис у журналi ре¹страцiй. Цей новий запис може бути оброблений вiдразу ж, зна- чно зменшуючи час мiж розпiзнаванням атаки та реагуванням на не¨. Залиша¹ться затримка моментом запису операцiйною системою подi¨ в журнал ре¹страцi¨ i моментом розпiзнавання ¨¨ системою виявлення атак, але у багатьох випадках порушник може бути виявленим та зупиненим ранiше, нiж нанесе будь-якi збитки.

Системи виявлення атак на системному рiвнi встановлюються у файловi сервери, Web-сервери та iншi ресурси. Така можливiсть може зробити IDS системного рiвня дуже ефективними, тому що вони не вимагають додаткового вузла мережi, якому необхiдно придiляти увагу, виконувати технiчне обслуговування та управляти ним.

Приклади побудови захищених iнформацiйних технологiй	441

IDS мережного рiвня

Системи виявлення атак мережного рiвня використовують як джерело даних для аналiзу атак мережнi пакети. Як правило, IDS мережного рiвня використову¹ мережний адаптер, що функцiону¹ в режимi прослуховування [promiscuous], i аналiзу¹ трафiк у реальному масштабi часу по мiрi його проходження через сегмент мережi. Модуль розпiзнавання атак використову¹ чотири широко вiдомих методи для розпiзнавання сигнатури атаки:

•вiдповiднiсть трафiка шаблону, що характеризу¹ атаку;

•контроль частоти подiй;

•кореляцiя декiлькох подiй з низьким прiоритетом;

•виявлення статистичних аномалiй.

Як тiльки атака виявлена, модуль реагування нада¹ широкий набiр варiантiв повiдомлення, видачi сигналу тривоги, та реалiзацi¨ контрзаходiв у вiдповiдь на атаку. Цi варiанти змiнюються вiд системи до системи, але, як правила, включають: повiдомлення адмiнiстратора через консоль або електронною поштою, завершення з'¹днання з атакуючим вузлом i/або запис сесi¨ для наступного аналiзу та збирання доказiв.

IDS мережного рiвня встановлюють у найбiльш важливих мiсцях мережi для контролю трафiка, циркулюючого мiж багато- чисельними системами. Системи мережного рiвня не потребують, щоб на кожнiй мережнiй ЕОМ установлювалося програмне забезпечення системи виявлення атак. Оскiльки для контролю всi¹¨ мережi не потрiбно встановлювати IDS на кожнiй ЕОМ, то вартiсть ¨х експлуатацi¨ в мережi ¹ нижчою, нiж вартiсть експлуатацi¨ систем виявлення атак на системному рiвнi, що встановлю¹ться на усiх вузлах мережi.

IDS мережного рiвня аналiзують заголовки мережних пакетiв на наявнiсть пiдозрiло¨ дiяльностi. IDS системного рiвня не працюють iз заголовками пакетiв, отже, вони не можуть визначати цi типи атак. Наприклад, бiльшiсть мережних атак типу вiдмова в обслуговуваннi можуть бути iдентифiкованими тiльки шляхом аналiзу заголовкiв пакетiв, то мiрi того як вони проходять через мережу. Цей тип атак можу бути швидко iдентифiкованим за допомогою IDS мережного рiвня, яка прогляда¹ трафiк у реально-

442	Ðîçäië 6

му масштабi часу. IDS мережного рiвня можуть проглядати структуру пакета, знаходячи команди або певний синтаксис, що використовуються у конкретних атаках. Наприклад, коли порушник пробу¹ використати троянську програму в системах, якi поки ще ураженi нею, то цей факт може бути виявлений шляхом аналiзу змiсту тiла даних пакету.

Як зазначалося вище, IDS системного рiвня не працюють на мережному рiвнi i тому не здатнi розпiзнавати такi атаки.

IDS мережного рiвня аналiзують трафiк у реальному масштабi часу. Таким чином, порушник не може видалити слiди сво¹¨ присутностi. Данi, що аналiзуються, включають не тiльки iнформацiю про метод атаки, але i iнформацiю, яка може допомогти при iдентифiкацi¨ порушника. Оскiльки багато порушникiв добре знайомi з журналами ре¹страцi¨, вони знають, як манiпулювати цими файлами для приховування слiдiв сво¹¨ дiяльностi, знижуючи цим ефективнiсть систем системного рiвня, яки необхiдна iнформацiя для того, щоб виявити атаку.

IDS мережного рiвня виявля¹ пiдозрiлi та ворожi атаки по мiрi того, як вони вiдбуваються, i тому бiльш швидше реагують на атаку, нiж IDS системного рiвня. Наприклад, порушник, що iнiцiю¹ атаку типу вiдмова в обслуговуваннi на TСP-протокол, може бути зупинений IDS мережного рiвня, що посила¹ встановлений прапорець RESET у заголовку TСP-пакета для завершення з'¹днання з вузлом, що атаку¹ться, ранiше нiж атака викличе руйнування або ушкодження ЕОМ, що атаку¹ться.

IDS системного рiвня, як правило, не розпiзнають атаки до моменту вiдповiдного запису в системний журнал та роблять вiдповiднi дi¨ уже пiсля того, як був зроблений запис. До цього моменту найбiльш важливi системи або ресурси уже можуть бути скомпроментованими або порушена працездатнiсть системи, що запуска¹ IDS. Повiдомлення у реальному масштабi часу дозволя¹ швидко реагувати вiдповiдно з попередньо визначеними параметрами. Дiапазон цих реакцiй змiню¹ться вiд дозволу проникнення в режимi спостереження для того, щоб зiбрати iнформацiю про атаку та атакуючого, до негайного завершення атаки.

IDS мережного рiвня може виявляти атаки, нацiленi на ресурси за мiжмережним екраном , незважаючи на те, що мiжмережний

Приклади побудови захищених iнформацiйних технологiй	443

екран, можливо, вiдiб'¹ цi спроби. IDS системного рiвня не контролю¹ вiдбиттi мiжмережним екраном атаки. Ця втрачена iнформацiя може бути найбiльш важливою при оцiнцi та удосконаленнi системи безпеки.

IDS мережного рiвня не залежать вiд операцiйних систем та застосувань корпоративно¨ мережi. Система виявлення атак на системному рiвнi вимага¹ використання конкретних операцiйних систем для правильного функцiонування та генерацi¨ необхiдних результатiв.

6.2Багаторiвневi системи на основi реляцiйних систем управлiння базами даних

Реляцiйнi системи управлiння базами даних (СУБД) на даний час ¹ найбiльш затребуваною iнформацiйною технологi¹ю управлiння даними. Питання ¨х застосування в багаторiвневих системах ¹ надзвичайно актуальними, оскiльки залежнiсть мiж даними не дозволя¹ строго реалiзувати мандатну полiтику. Пряма екстраполяцiя мандатних моделей, що ¹ характерними для операцiйних систем, на реляцiйних СУБД не може бути виконаною без урахування багатьох обмежень та припущень. У зв'язку з цим питання багаторiвневого доступу та iнтеграцi¨ подання даних в iнформацiйних системах на основi реляцiйних СУБД звичайно вирiшуються при проектуваннi додаткiв, а не вiддаються на вiдкуп реляцiйнiй СУБД.

При проектуваннi багаторiвневих систем на основi реляцiйних баз даних (БД) можна скористатися рiзноманiтними пiдходами до декомпозицi¨ даних за рiвнями секретностi. Мiнiмальним елементом iнформацi¨ може бути база даних, вiдношення, подання (view), запис, або кортеж вiдношень i поле запису.

Кожна нова ступiнь деталiзацi¨ забезпечу¹ бiльшу гнучкiсть i бiльш широкi можливостi захисту iнформацi¨. Проте при реалiзацi¨ багаторiвнево¨ системи на основi реляцiйно¨ СУБД, що не представля¹ засоби багаторiвного доступу, великий рiвень деталiзацi¨ напевно буде вимагати великих зусиль зi сторони розробникiв системи i буде значно укладнювати ¨¨. Таким чином, вибiр ступеня деталiзацi¨ об'¹ктiв захисту ¹ питанням компромiсу мiж гнучкiстю

444	Ðîçäië 6

управлiння i очiкуваною складнiстю системи. Iлюстрацiю питань проектування реляцiйно¨ бази даних можна розглянути дальше на простому прикладi [27].

6.2.1 Приклад предметно¨ частини

Для iлюстрацi¨ можна розглянути предметну частину , зв'язану з iлюстрацi¹ю роботи гiпотетичного науково-дослiдного iнституту (НДI). Фрагмент iнфологiчно¨ моделi системи приведений на рис. 6.6. стрiлками мiж таблицями на рисунку показанi типи вiд-

Ðèñ. 6.6. Приклад опису бази даних гiпотетичного науководослiдного iнституту

носин, у тому числi вiдносини один до одного, один до багатьох та багатьох до багатьох. Символом познача¹ться сторона вiдносин

çмножинною вiдповiднiстю.

Óнаведеному далi прикладi НДI здiйсню¹ться виконання комерцiйних проектiв i, крiм того, деякi засекреченi дослiдження у критичних галузях. Цими галузями можуть бути сфери, пов'язанi з нацiональною безпекою або конкурентними комерцiйними те-

Приклади побудови захищених iнформацiйних технологiй	445

хнологiями, що ¹ власнiстю компанiй, що мають на не¨ авторськi права.

Для однакового оброблення та зберiгання даних про всi проекти НДI вiдносини (таблиця) Проекти об'¹днують записи рiзних рiвнiв секретностi. Аналогiчним чином на записи, що представляють документацiю до секретних проектiв, особистi данi спiвробiтникiв НДI, такi як паспортнi данi, також повиннi накладатися обмеження доступу.

I, нарештi, засекреченим можуть бути вiдомостi про деяких замовникiв, для позначеннях яких можуть бути придуманi спецiальнi легенди прикриття. Це призводить до одночасного iснування в однiй таблицi декiлькох записiв рiзно¨ секретностi з однаковим первинним ключом (для цього часто використовують термiн Poly instantiation). Для простоти дальше можна використовувати термiн багатозначнiсть.

Можливим також засекречування тiльки деяких вiдомостей про будь-яких замовниках. Наприклад, координати або контактнi особи деяких органiзацiй та та контрагентiв можуть буди недоступними для загального огляду. У розглянутiй базi даних використовуються наступнi рiвнi декомпозицi¨ об'¹ктiв доступу:

•секретнi записи: секретнi (дослiдження) та несекретнi (замовлення) проекти вiдносини Проекти ;

•секретна документацiя вiдносини Документи ;

•секретнi атрибути: паспортнi та iншi данi спiвробiтникiв атрибут Паспорт вiдносини Спiвробiтники ;

•секретнi поля: координати деяких клi¹нтiв вiдносин Клi¹нти .

6.2.2 Декомпозицiя баз даних

При декомпозицi¨ баз даних iнформацiя рiзного рiвня доступу локалiзу¹ться в рiзних базах даних (екземплярах баз даних), зв'язки мiж сутт¹востями вiдсутнi, що призводить до вiдсутностi потреби у вза¹модi¨.

Такi системи можуть успiшно функцiонувати в iзольованому режимi, не використовуючи засоби розподiлу баз даних. Проте рiзнi бази даних можуть мати загальних користувачiв та ¹дину

446	Ðîçäië 6

полiтику безпеки. Користувачi рiзних сегментiв бази даних можуть знати структуру бази даних, читати, оновлювати, додавати/видаляти об'¹кти баз даних.

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

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

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

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

В таких системах нема необхiдностi у будь-яких додаткових компонентах системи.

6.2.3 Декомпозицiя на рiвнi вiдносин

При декомпозицi¨ на рiвнi вiдносин (реляцiйних таблиць) з'являються зв'язки мiж даними, розмiщеними в екземплярах баз даних, що обробляють iнформацiю рiзного рiвня доступу. Така декомпозицiя достатньо рiдко використову¹ться в реальних системах, багаторiвневий доступ в яких забезпечу¹ться вбудованими засобами системи управлiння базами даних, так як для бiльшостi задач не нада¹ достатньо¨ гнучкостi. У прикладi, що розгляда¹ться на рис. 6.7, розподiл даних рiзного рiвня секретностi по таблицях використову¹ться для забезпечення багатозначностi записiв вiдносин Клi¹нти . Для зберiгання записiв з високим рiвнем секретностi з цього вiдношення видiля¹ться нове вiдношенняОрганiзацi¨ , що мiстить справжнi данi секретних клi¹нтiв, якi у

Приклади побудови захищених iнформацiйних технологiй	447

Ðèñ. 6.7. Розподiл по таблицях

вiдношеннi Клi¹нти представленi у виглядi вiдповiдних легенд прикриття.

При включеннi до розподiлено¨ бази даних зв'язаних таблиць вiдразу виника¹ питання про допустимостi порушень моделi Белла-ЛаПадули, оскiльки в деяких випадках вигода таких порушень перевищу¹ ризик компрометацi¨ даних. У багатьох випадках вимога, що забороня¹ користувачу з високим рiвнем допуску змiнювати iнформацiйнi об'¹кти з бiльш низьким рiвнем секретностi, ста¹ неприйнятним для системи, i розробник може спробувати будь-яким способом пом'якшити це обмеження. Iснують наступнi пiдходи до модифiкацi¨ даних з меншим рiвнем секретностi процесами з бiльш високим рiвнем секретностi:

•приховувати змiненi данi вiд користувачiв високого рiвня;

•забороняти змiни для користувачiв високого рiвня;

•дублювати данi;

•обмежувати дiапазони значень змiнюваних даних.

Iдея приховування змiн заснову¹ться на тому, що записи доступнi користувачi з низьким рiвнем допуску, одержують бiльш високий рiвень пiсля ¨х модифiкацi¨ користувачем з високим рiвнем. Для користувача з низьким рiвнем допуску це вигляда¹ як видалення даних. Як правило, такий пiдхiд ¹ вкрай небажаним, так як понижу¹ доступнiсть системи для користувачiв з низким рiвнем i, крiм того, веде до можливостi приховано¨ вза¹модi¨ користувачiв з рiзними рiвнями допуску.

Наступний пiдхiд, що забороня¹ будь-якi змiни iнформацiйних об'¹ктiв з низьким рiвнем секретностi зi сторони суб'¹кта з високим рiвнем допуску, ¹ прямою реалiзацi¹ю правил Белла-

448	Ðîçäië 6

ЛаПадули. Часто вiн пред'явля¹ надто жорсткi обмеження для iнформацiйно¨ вза¹модi¨, якi можуть бути зробленi бiльш прийнятними при реалiзацi¨ багатозначностi подання даних створення ново¨ копi¨ даних. що пiдлягають модифiкацi¨, та присво¹ння ¨м рiвня секретностi, що вiдповiда¹ рiвню допуску користувача. що створив ¨х. У цьому випадку користувач з низьким рiвнем допуску буде працювати зi старою копi¹ю змiнених даних i не одержить нiяко¨ iнформацi¨ про об'¹кти з високим рiвнем. При цьому користувача з високим рiвнем допуску зможе мати власну, актуальну версiю даних.

Для реалiзацi¨ пiдходу можна використати роздiлення iнформацi¨ рiзно¨ секретностi на рiвнi таблиць, що проiлюстровано на даному прикладi.

Врештi-решт, останнiй спосiб дозвiл модифiкацi¨ користува- чем з високим рiвнем доступу даних даних низького рiвня ¹ прямим порушенням моделi Белла-ЛаПадули та нада¹ широкi можливостi для приховано¨ вза¹модi¨. Для обмеження наслiдкiв такого роду модифiкацiй у застосуваннях бази даних можуть бути реалiзованi спецiальнi процедури, що контролюють характер змiн даних вiдповiдно до вимог предметних галузей. Контролю можуть пiддаватися дiапазони змiн даних у таблицях та частота виконання цих змiн (число операцiй за нормовану одиницю часу.

6.2.4 Декомпозицiя на рiвнi записiв вiдносин

У наведеному на рис. 6.8 прикладi виконаний розподiл записiв у таблицi Проекти . При цьому таблиця `Замовлення мiстить несекретнi записи, а таблиця Дослiдження секретнi. Роздiлення записiв рiзного рiвня секретностi усерединi таблицi може бути зведена до розподiлу цих записiв по декiлькох таблицях з однаковою структурою та збереженням зв'язностi усi¹¨ iнформацiйно¨ структури бази даних у цiлому.

При цьому виника¹ проблема пiдтримки зовнiшнiх ключiв у роздiленiй таблицi, а також у таблицях, що посилалися на не¨. У наведеному прикладi вiдносини Проекти посилалися на вiдносини Клi¹нти за допомогою атрибута клi¹нт . При роздiленнi цих вiдносин на дво¹ нiяких змiн у органiзацi¨ цього посилання

Приклади побудови захищених iнформацiйних технологiй	449

Ðèñ. 6.8. Розподiл вiдносин Проекти

не вiдбулося. Тепер кожне з результуючих вiдносин ма¹ власний зовнiшнiй ключ, що вiдповiда¹ первинному ключу вiдносин Клi¹нти . Аналогiчно зберiга¹ться посилання на вiдносини Групи за допомогою вiдповiдного зовнiшнього ключа.

Iншим чином складаються справи iз зовнiшнiм ключем вiдносин Документи , що вiдповiдають первинному ключу роздiлених вiдносин Проекти . Цей ключ представля¹ться одним атрибутом i може вiдповiдати первинному ключу тiльки однi¹¨ таблицi. У загальному випадку така ситуацiя розряджа¹ться створенням додаткових вiдносин, посилання на якi будуть присутнiми як у вiдносинах, що ранiше мали зовнiшнiй ключ на роздiлення вiдносин, так i вiдносинах, що з'явилися у результатi цього роздiлення. Цi новi вiдносини можуть розташовуватися у базi даних з бiльш низьким рiвнем секретностi та служити для зв'язування роздiлених вiдносин з вiдносинами, що посилалися на них. У наведеному випадку опис функцi¨ викону¹ таблиця Групи i тому для створення ново¨ таблицi нема необхiдностi. Як наслiдок, роздiлення таблицi Проекти на таблицю Дослiдження та таблицю Замовлення

450	Ðîçäië 6

призводить до змiни зовнiшнього ключа в таблицi Документи .

6.2.5 Декомпозицiя на рiвнi полiв записiв

Ðèñ. 6.9 демонстру¹ приховування атрибуту паспорт вiдносин

Ðèñ. 6.9. Приховування атрибуту паспорт

Спiвробiтники . Для такого роздiлення слiд скористатися проекцiями таблиць та розбивкою записiв на поля. Це найпростiший випадок реалiзацi¨ багатозначного атрибута.

При необхiдностi засекречування заданих полiв окремих записiв слiд роздiляти данi записи на два (як i у випадку з роздiленням вiдносин) та забезпечувати роздiлення записiв, що зводиться до наступно¨ задачi. Наприклад, при необхiдностi засекречування координат деяких клi¹нтiв iз таблицi Клi¹нти слiд помiстити в поле координати . що вiдповiда¹ запису цi¹¨ таблицi, нульове значення (NULL), а для зберiгання реального значення координат клi¹нта створити новий запис у таблицi Органiзацi¨ . таким чи- ном, цей новий запис буде посилатися на запис таблицi Клi¹нти , що мiстить нульове значення.

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

На завершення можна навести повну iнфологiчну модель фрагменту бази даних, побудовану вiдповiдно до правил декомпозицi¨ багаторiвнево¨ бази даних.

Íà ðèñ. 6.10 таблицi з низьким рiвнем секретностi утворюють самостiйну закiнчену структуру даних, а таблицi з високим рiвнем

Приклади побудови захищених iнформацiйних технологiй	451

Ðèñ. 6.10. Декомпозицiя багаторiвнево¨ бази даних НДI

секретностi природним чином об'¹днуються з ними, створюючи нову структуру даних, що вiдповiда¹ потребам користувачiв.

Отже, наданi вище типовi рiшення, дозволяють реалiзувати рiзну ступiнь декомпозицi¨ об'¹ктiв багаторiвневого доступу засобами реляцiйних СУБД, що не мають вбудованих механiзмiв реалiзацi¨ MLS-полiтики. За допомогою цих рiшень можна повнiстю забезпечити функцiональнiсть багаторiвнево¨ бази даних на основi традицiйно¨ однорiвнево¨ СУБД. Вони дозволяють iнтегрувати iнформацiю у ¹дину зв'язну структуру, придатну для спiльно¨ обробки користувачами рiзного рiвня доступу. У випадку, коли для побудови iнформацiйно¨ системи використову¹ться довiрена

452	Ðîçäië 6

однорiвнева СУБД (в СУБД вiдсутнi програмнi закладки), вза¹модiя мiж сегментами бази даних рiзного рiвня доступу може бути реалiзовано застосуваннями. У протилежному випадку технологiя тако¨ вза¹модi¨ ¹ бiльш складною та заснову¹ться на застосуваннi спецiальних компонент шлюзiв безпеки.

Допомiжнi термiни та поняття

АДМIНIСТРАТОР [administrator, manager] (вiд лат. administrator розпорядник) 1) Адмiнiстративно-посадова особа, керiвник, розпорядник, органiзатор. 2) Користувач, роль якого включа¹ функцi¨ керування комп'ютерною системою i (àáî) комплексом засобiв захисту .

Адмiнiстратор безпеки [security administrator] 1) Особа або група осiб, вiдповiдальних за забезпечення безпеки системи, за реалiзацiю й безперервнiсть дотримання адмiнiстративних заходiв захисту i здiйснюючих постiйну органiзацiйну пiдтримку функцiонування фiзичних i технiчних засобiв захисту, що застосовуються. 2) Адмiнiстратор, вiдповiдальний за дотримання полiтики безпеки .

АДМIНIСТРУВАННЯ [administration] (вiд лат. administro керую) 1) Керування, завiдування. 2) Формально-бюрократичний метод керування, шляхом команд, наказiв та розпоряджень.

ÀÍÀËIÇ [analysis, interpretation, study, review] (âiä ãðåö. αν` αλυσις´ ðîç-

клад, розчленування) 1)Метод дослiдження, що поляга¹ в мисленому або практичному розчленуваннi цiлого на складовi частини. Протилежне синтез. 2) Уточнення логiчно¨ форми (побудови, структури) мiркування засобами формально¨ логiки.

Àíàëiç òðàôiêà [tra c analysis, sni ng] прослуховування трафiка з метою збирання паролiв, ключiв, iншо¨ iдентифiкацiйно¨ або автентифiкацiйно¨ iнформацi¨.

Системний аналiз [system analysis] 1) Аналiз об'¹кта дослiдження як сукупностi елементiв, що утворюють систему. У наукових дослiдженнях вiн передбача¹ оцiнку поведiнки об'¹кта як системи з усiма факторами, якi впливають на його функцiонування. Системний аналiз можна здiйснювати у вiдповiдностi до етапiв системного аналiзу: постановка задачi системного аналiзу (визначення границь системи, цiлей ¨¨ функцiонування i основних показникiв оцiнки); проведення структуризацi¨ системи, виявлення складових елементiв (основних об'¹ктiв i процесiв), якi визначають досягнення цiлей, що стоять перед системою, з врахуванням умов впливу зовнiшнього середовища у виглядi характеристик, що вiдображають його вплив на елементи системи; складання математично¨ моделi системи, тобто визначе- ння параметрiв системи, допустимих iнтервалiв змiни i залежностей мiж