10. Побудова і структура гарантій реалізації послуг безпеки

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

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

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

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

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

1. Вимоги до архітектури

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

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

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

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

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

2. Середовище розробки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы прочитать лекцию полностью, напишите автору

----------------------------------------------------------------------------------------------------

Книга | Автор | Статьи | Фильмы | Фото | Ссылки | Отзывы

Контакт | Студентам | Ветеранам | Астрология | Карта сайта



Рейтинг@Mail.ru Яндекс.Метрика