Основые Критерии Защищенности Ас.Основные Компоненты Безопасности Tcsecни. Функциональные Услуги Безопасности По НД ТЗИ 2.5-004-99

Курсова робота 

з дисципліни “  Системи технічного захисту інформації ”

на тему:  “Основі  критерії захищеності АС.Основні  компоненти безпеки TCSEC.

Функціональні послуги безпеки за НД ТЗІ 2.5-004-99” 

Київ 2010 

План

   1. Критерії  оцінки безпеки комп'ютерих  систем  Міністерства Оборони США «Поморанчева  книга»

      1.1.  Загальна структура вимог  TCSEC

      1.2.  Класи захищеності комп'ютерних  систем по TCSEC

         1.2.1. Вимоги до політики безпеки

         1.2.2. Вимоги до підзвітності

         1.2.3. Вимоги до гарантованості

         1.2.4. Вимоги до документації

      1.2. Інтерпретація і розвиток TCSEC

   2. НД ТЗІ  2.5-004-99

      2.1. Галузь використання 

      2.2. Побудова і структура критеріїв  захищеності інформації

      2.3. Функціональні послуги

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

1. КРИТЕРІЇ ОЦІНКИ  БЕЗПЕКИ КОМП'ЮТЕРНИХ СИСТЕМ МІНІСТЕРСТВА  ОБОРОНИ США ("ПОМАРАНЧЕВА КНИГА")

Критерії оцінки безпеки комп'ютерних систем" (Trusted Computer System Evaluation Criteria -TCSEC), що отримали неформальну, але міцно таку, що закріпилося  назву "Помаранчева книга", були розроблені і опубліковані Міністерством  оборони США в 1983 р. з метою  визначення вимог безпеки, комп'ютерних  систем, що пред'являються до апаратного, програмного і спеціального програмного  і інформаційного забезпечення, і  вироблення методології і технології аналізу міри підтримки політики безпеки в комп'ютерних системах в основному військового призначення.

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

      1.1. Загальна структура вимог TCSEC

У "Помаранчевій книзі" запропоновано три категорії  вимог безпеки: політика безпеки, аудит  і коректність, в рамках яких сформульовано  шість базових вимог безпеки. Перші чотири вимоги направлено безпосередньо  на забезпечення безпеки інформації, а два останніх-на якість засобів  захисту. Розглянемо ці вимоги детальніше.

Політика безпеки

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

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

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

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

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

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

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

Розглянемо перераховані елементи детальніше.

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

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

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

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

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

Безпека повторного використання об'єктів 

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

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

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

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

Мітки безпеки 

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

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

   * цілком  таємний; 

   * таємно;

   * конфіденційно; 

   * нетаємно.

Категорії утворюють  неврегульований набір. Їх призначення - описати наочну область, до якої відносяться  дані. У військової області кожна  категорія може відповідати, наприклад, певному вигляду озброєнь. Механізм категорій дозволяє розділити інформацію "по відсіках", що сприяє кращій захищеності. Суб'єкт не може дістати доступ до "чужих" категорій, навіть якщо його рівень благонадійності - "цілком таємний". Фахівець з танків не взнає тактико-технічні дані літаків.

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

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

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

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

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

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

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

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

Підзвітність

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

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

Гарантії (коректність)

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

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

      1.2.  Класи захищеності комп'ютерних  систем по TCSEC

"Помаранчева  книга" передбачає чотири групи  критеріїв, які відповідають різній  мірі захищеності: від мінімальної  (група D) до формально доведеною  (група А). Кожна група включає  один або декілька класів. Групи  D і А містять по одному класу  (класи D і А відповідно), група  з-класи С1, С2, а група В три  класи -81, В2, ВЗ, що характеризуються  різними наборами вимог захищеності.  Рівень захищеності зростає від  групи D до групи А, а усередині  групи - із збільшенням номера  класу. Посилення вимог здійснюється  з поступовим зсувом акцентів  від положень, опредепяющих наявність  в системі якихось опредепенных  механізмів захисту, до положень  тих, що забезпечують високий  рівень гарантій того, що система  функціонує у відповідності вимогам  попитики безпеки (таблиця. 5.3). Наприклад,  по реалізованих механізмах захисту  класи ВЗ і А1 ідентичні.

Таблиця 1.

 Базові вимоги "Помаранчевої книги" | Класи захищеності |

  | С1 | С2 | В1 | В2 | ВЗ | А1 |

 Політика  безпеки |

1. Дискреційна  політика  безпеки | + | + | + | = | = | = |

2. Мандатна політика  безпеки | - | - | + | + | = | = |

3. Мітки секретності | - | - | + | + | = | = |

4. Цілісність  міток | - | - | + | = | = | = |

5. Робічі мітки | - | - | - | + | = | = |

6. Повторення  міток | - | - | + | = | = | = |

7. Звільнення  ресурсів при повторному використанні  об'єктів | - | + | = | + | = | = |

8. Ізолювання  модулів | - | + | = | = | = | = |

9. Позначка пристроїв  введення/виведення | - | - | + | = | = | = |

10. Позначка  читаного виводу | - | - | + | = | = | = |

 Підзвітність |

11. Ідентифікація  і аутентифікація | + | + | = | = | = | = |

12. Аудит | - | + | + | + | + | = |

13. Захищений  канал (довірена дорога) | - | - | - | + | = | = |

 Гарантії |   |

14. Проектна  специфікація і верифікація | - | - | + | + | + | + |   |

15. Системна  архітектура | + | = | = | + | + | = |   |

16. Цілісність  системи | + | = | = | = | = | = |   |

17. Тестування  системи безпеки | + | + | + | + | + | = |   |

18. Довірене  відновлення після збоїв | - | - | - | - | + | = |   |

19. Управління  конфігурацією системи | - | - | - | + | + | + |   |

20. Довірене  дооснащение системи | - | - | - | + | + | = |   |

21. Довірене  поширення | - | - | - | - | + | = |   |

22. Аналіз прихованих  каналів | - | - | - | + | + | + |   |

 Документація |   |

23. Посібник  користувача | + | = | = | = | = | = |   |

24. Керівництво  по конфігурації системи захисту | + | + | + | + | + | = |   |

25. Документація  по тестуванню | + | = | = | = | = | + |   |

26 Проектна документація | + | = | + | + | = | + |   |

 Примітки. "-"- немає вимог до даного класу; "+"- нові або додаткові вимоги; "="-требования збігаються з  вимогами до СВТ попереднього  класу |   |

  |  |  |  |  |  |  |  |  |  |  |  |  |  |

Розглянемо основні  вимоги класів захищеності по вказаних вище чотирьом категоріям:

• політика безпеки;

• підзвітність;

• гарантії;

• документація.

Центральним об'єктом  дослідження і оцінки по TCSEC є  довірча база обчислень (ТСВ).

         1.3.1. Вимоги до політики безпеки

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

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

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

Клас C2 - на додаток  до C1, права доступу повинні гранулюватися  з точністю до користувача. Механізм управління повинен обмежувати поширення  прав доступу - лише авторизований користувач, наприклад власник об'єкту, може надавати права доступу іншим  користувачам. Всі об'єкти повинні  піддаватися контролю доступу.

Клас B3 - на додаток  до C2, обов'язково повинні використовуватися  списки управління доступом з вказівкою  дозволених режимів. Має бути можливість явної вказівки користувачів або  їх груп, доступ яких до об'єкту заборонений.

(Примітка. Оскільки  класи B1 і B2 не згадуються, вимоги  до них в плані добровільного  управління доступом ті ж, що  і для C2. Аналогічно, вимоги до  класу A1 ті ж, що і для  B3.)

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

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

Мітки безпеки:

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

Клас B2 - на додаток  до B1, позначатися повинні всі  ресурси системи, наприклад ПЗП, прямо або побічно доступні суб'єктам.

Цілісність міток  безпеки:

Клас B1 - мітки  повинні адекватно відображати  рівні секретності суб'єктів і  об'єктів. При експорті інформації мітки  повинні перетворюватися в точну  і однозначно трактуючу зовнішню виставу, супроводжуючу дані. Кожен  пристрій ввода/вывода (у тому числі  комунікаційний канал) повинен трактуватися як однорівневе або багаторівневе. Всі зміни трактування і асоційованих рівнів секретності повинні протоколюватися.

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

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

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

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

Клас B2 - на додаток  до B1, всі ресурси системи (у тому числі ПЗП, пристрої ввода/вывода) повинні  мати мітки безпеки і служити  об'єктами примусового управління доступом.

         1.3.2. Вимоги до підзвітності

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

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

Клас C2 - на додаток  до C1, кожен користувач системи повинен  унікальним чином ідентифікуватися. Кожна реєстрована дія повинна  зв'язуватися з конкретним користувачем.

Клас B1 - на додаток  до C2, обчислювальна база повинна  підтримувати мітки безпеки користувачів.

Надання надійної дороги:

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

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

Аудит:

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

   * використання  механізму ідентифікації і аутентифікації;

   * внесення  об'єктів до адресного простору  користувача, наприклад відкриття  файлу, запуск програми;

   * видалення  об'єктів; 

   * дії  системних операторів, системних  адміністраторів, адміністраторів  безпеки; 

   * інші  події, що зачіпають інформаційну  безпеку. 

Кожен реєстраційний  запис повинен включати наступні поля:

   * дата  і час події; 

   * ідентифікатор  користувача; 

   * тип  події; 

   * результат  дії (успіх або невдача).

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

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

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

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

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

         1.3.3. Вимоги до гарантованості

Архітектура системи:

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

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

Клас B1 - на додаток  до C2, обчислювальна база повинна  забезпечувати взаємну ізоляцію процесів шляхом розділення їх адресних просторів.