9.1. Проблеми створення стандартів із ЗІ
В основному роль стандартів із ЗІ така сама, як і в будь-якій іншій сфері. Кожна людина повинна мати можливість оцінювати і порівнювати все, що є навколо неї і чим вона користується. У цьому сенсі ІБ нічим не відрізняється від інших сфер нашої діяльності. Головне завдання стандартів ІБ - створити основу для взаємодії між виробниками, споживачами та експертами з кваліфікації продуктів інформаційних технологій. Кожна з цих груп має свої інтереси і свої погляди на проблему ІБ.
Споживачі, по-перше, зацікавлені в методиці, яка дозволяє обґрунтовано обрати продукт, що відповідає їх потребам і вирішує їх проблеми, для чого їм необхідна чітка шкала оцінки безпеки, і, по-друге, мають потребу в інструменті, за допомогою якого вони могли б формулювати свої вимоги виробнику. При цьому споживачів (що, до речі, цілком природно й обгрунтовано) цікавлять виключно характеристики і властивості кінцевого продукту, а не методи та засоби їх досягнення. Тут звернемо увагу на те, що саме з цієї точки зору ми цікавимось взагалі будь-якими товарами (тобто не обов'язково пов'язаними з ІБ). З цієї ж точки зору ідеальна шкала оцінки безпеки мала б виглядати приблизно так (звичайно, залежно від можливого для споживача рівня конфіденційності інформації):
Рівень 1. Система для обробки інформації з грифом не вище ніж «для службового користування».
Рівень 2. Система для обробки інформації з грифом не вище ніж «секретно» і т. д.
Відповідно і вимоги споживач міг би сформулювати приблизно в такій формі: «Я хотів би, щоб у мене все було захищене для обробки, наприклад, цілком таємної інформації». Нагадаємо, що коли ми щось купуємо, то, звичайно ж, хочемо, щоб воно було найліпшим, найдовго-вічнішим і т. ін. Однак цей неконструктивний підхід сам по собі не такий страшний, багато гірше інше - більшість споживачів не розуміє і не хоче розуміти, що за все треба платити (і не тільки грошима) і що вимоги безпеки обов'язково суперечать (не можуть не суперечити!) функціональним вимогам (наприклад, зручності роботи, швидкодії і т. п.), накладають обмеження на сумісність і, як правило, вимагають відмовитися від широко розповсюджених незахищених прикладних ПЗ.
Виробники, у свою чергу, мають потребу в стандартах для порівняння можливостей своїх продуктів і в застосуванні процедури сертифікації для об'єктивного оцінювання їх властивостей, а також у стандартизації певного набору вимог безпеки, що міг би обмежити фантазію замовника конкретного продукту і змусити його вибирати вимоги з цього продукту. Знову згадаємо будь-якого звичайного виробника -йому зовсім не хочеться робити все для всіх. З погляду виробника, вимоги повинні бути максимально конкретними і регламентувати необхідність застосування тих чи інших засобів, механізмів, алгоритмів і т. д. Крім того, вимоги не повинні вступати в конфлікт з існуючими методами й алгоритмами обробки інформації, архітектурою КС і технологіями створення інформаційних продуктів. Цей підхід також не може бути визнаний домінуючим, тому що він не враховує потреби користувачів (адже в кінцевому рахунку саме для них все робиться) і намагається підігнати вимоги захисту під існуючі системи і технології, а це далеко не завжди можливо здійснити без збитку для безпеки.
Експерти з кваліфікації і фахівці із сертифікації розглядають стандарти як інструмент, що допомагає їм оцінити рівень безпеки, забезпечуваний продуктами інформаційних технологій, і надати споживачам можливість зробити обґрунтований вибір. Виробники в результаті кваліфікації рівня безпеки одержують об'єктивну оцінку можливостей свого продукту. Експерти з кваліфікації опиняються у двоїстому становищі. З одного боку, вони, як і виробники, зацікавлені в чітких і простих критеріях, над застосуванням яких до конкретного продукту не потрібно ламати голову (найкраще це могла б бути анкета з відповідями типу «так/ні»). З іншого боку, вони повинні дати обґрунтовану відповідь користувачам - задовольняє продукт їх потреби чи ні. Виходить, що сам...
