Loe raamatut: «Комплексні системи захисту інформації. Проектування, впровадження, супровід», lehekülg 5

3. Вибір варіанту побудови КСЗІ

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

Характеристика можливих варіантів побудови КСЗІ:

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

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

– максимальний – досягнення максимального рівня захищеності інформації за необхідних затрат і мінімального рівня обмежень на технологію її обробки в ІТС.

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

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

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

На підставі визначених завдань і функцій ІТС, результатів аналізу її середовищ функціонування, моделей загроз і порушників та результатів аналізу ризиків визначаються компоненти ІТС (наприклад, ЛОМ, спеціалізований АРМ, Інтернет-вузол тощо), для яких необхідно або доцільно розробляти свої власні політики безпеки, відмінні від загальної політики безпеки в ІТС.

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

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

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

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

4. Оформлення звіту за результатами проведеної роботи

Останній етап формування завдання на створення КСЗІ завершується оформленням «Звіту за результатами проведення аналізу ризиків та формування завдань на створення КСЗІ», який затверджується керівником організації-власника (розпорядника) ІТС.

Звіт повинен містити 2 розділи:

– формалізований або неформалізований опис результатів аналізу ризиків, пов’язаних з реалізацією загроз для інформації в ІТС;

– формулювання, з урахуванням результатів виконаного аналізу ризиків, завдань на створення КСЗІ в ІТС.

7. Основні вимоги до розробки комплексу засобів захисту

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

– безперервний захист;

– «модульність» КЗЗ;

– атрибути доступу;

– керування доступом.

Крім того, КЗЗ від НСД повинен реалізувати:

– концепцію диспетчера доступу;

– реєстрацію дій користувачів;

– послуги безпеки (функції захищеності);

– гарантії реалізації послуг безпеки.

1. Безперервний захист

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

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

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

2. «Модульність» КЗЗ

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

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

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

3. Атрибути доступу

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

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

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

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

Матриця доступу може бути:

– двомірною (наприклад, користувачі/об'єкти або процеси/об'єкти);

– тримірною (користувачі/процеси/об'єкти);

– повною, тобто містити вздовж кожної з осей всі існуючі iдентифікатори ІТС.

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

4. Керування доступом

Є два види або принципи керування доступом в ІТС: довірче та адміністративне.

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

Адміністративне керуванням доступом – це таке керування, при якому КЗЗ дозволяє тільки спеціально уповноваженим користувачам (адміністраторам) управляти потоками інформації в системі між користувачами і об'єктами.

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

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

Створення додаткових потоків інформації може бути зумовлене:

– модифікацією атрибутів доступу користувача, процесу або пасивного об'єкта;

– створенням нових об'єктів (включаючи копіювання існуючих);

– експортом або імпортом об'єктів.

Сталість атрибутів доступу

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

І навпаки, при довірчому керуванні доступом звичайний користувач може змінювати атрибути доступу об'єкта, що належить йому.

Створення нових об'єктів

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

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

Експорт і імпорт об'єктів

При адміністративному керуванні атрибути доступу об'єкта мають зберігатись під час його експорту на зовнішній носiй. Додатково повинні існувати правила для присвоєння атрибутів доступу імпортованому об'єкту.

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

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

5. Концепція диспетчера доступу

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

– безперервний і повний захист;

– захищеність від модифікації;

– невеликі розміри.

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

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

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

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

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

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

6. Реєстрація дій користувачів

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

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

7. Послуги безпеки (функції захищеності)

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

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

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

Функціональні послуги розбиті на 4 групи, кожна з яких описує вимоги до послуг, що забезпечують захист від загроз одного із 4-х основних типів: конфіденційність (К), цілісність (Ц), доступність (Д) і спостереженість (Н).

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

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

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

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

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

8. Гарантії реалізації послуг безпеки

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

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

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

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

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

Класифікація АС

В межах кожного класу АС класифікуються на підставі вимог до забезпечення певних властивостей інформації. З точки зору безпеки інформація характеризується трьома властивостями: конфіденційністю, цілісністю та доступністю. Виходячи з цього, кожний клас АС (Х=1,2,3) поділяється на підкласи, які визначають підвищені вимоги до забезпечення однієї чи декілька цих властивостей.

Таким чином, кількість сполучень з трьох властивостей зумовлює наявність семи груп підкласів АС:

1) підклас Х.К – конфіденційності інформації;

2) підклас Х.Ц – цілісності інформації;

3) підклас Х.Д – доступності інформації;

4) підклас Х. КЦ – конфіденційності та цілісності інформації;

5) підклас Х. КД – конфіденційності та доступності інформації;

6) підклас Х. ЦД – цілісності та доступності інформації.

7) підклас Х. КЦД – конфіденційності, цілісності та доступності інформації.

Якщо врахувати наявність в кожній групі трьох класів АС, сумарна кількість підкласів становить 21.

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

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

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

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

НД ТЗІ 2.5-005-99 визначає стандартний підхід до визначення ФПЗ АС шляхом вибору з множини СФПЗ, який базується на таких припущеннях:

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

– у межах класу АС можна віднести до одного з підкласів, що визначені за критерієм необхідності забезпечення К, Ц і Д;

– вимоги до безпеки АС різних класів суттєво відрізняються, що дозволяє сформувати для їх підкласів множини СФПЗ, що знаходяться у ієрархічній залежності;

– для створення КЗЗ, який найповніше відповідає характеристикам і вимогам до конкретної ІТС, необхідно проведення в повному обсязі аналізу загроз і оцінки ризиків.

Стандартний підхід визначення ФПЗ вимагає таких етапів:

1. Визначення підкласу АС.

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

3. Аналіз сутності вимог, відібраних СФПЗ.

4. Вибір одного із СФПЗ, який найбільш відповідає політиці безпеки.

5. У випадку, коли жоден із СФПЗ не підходить повною мірою, необхідно змінити рівень послуги, що міститься у СФПЗ, або додати нову послугу.

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

Згідно НД ТЗІ 2.5-005-99 кожний профіль має свій буквено-числовий ідентифікатор, який включає:

– номер класу АС (1 – ПЕОМ, 2 – ЛОМ, 3 – РОМ),

– букви, що характеризує види загроз, від яких забезпечується захист (К, Ц, Д),

– номер профілю.

Всі частини ідентифікатора відділяються один від одного крапкою.

Наприклад, СФПЗ АС класу «2» номер 1 з підвищеними вимогами до забезпечення конфіденційності інформації виглядає таким чином

2.К.1 = {КД-2, НР-2, НИ-2, НК-1, НО-1, НЦ-1}

А СФПЗ АС класу «1» номер 2 з підвищеними вимогами до забезпечення конфіденційності, цілісності та доступності інформації виглядає таким чином:

1.КЦД.2 = {КА-1, КО-1, ЦА-1, ЦО-1, ДР-1, ДВ-1, НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-1}

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

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

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

Таким чином, завданням розробника КСЗІ є обстеження властивостей конкретної АС, як об'єкта захисту та вибір необхідного СФПЗ із списку, наведеного у НД ТЗІ 2.5-005-99. У випадку, коли жоден з наявних СФПЗ не підходить до конкретної АС, розробник має створити свій, найбільш придатний для нього ФПЗ, обґрунтувати й затвердити його.