Порядок атестації інформаційних систем проекту. Аналіз конкретних сценаріїв атак та процесів. Заходи щодо аналізу та управління ризиками

Загальний описпроцедури атестації автоматизованих системз вимог інформаційної безпеки (Астахов)

ЗМІСТ
Вступ
Використовувана термінологія

>Планування
Ініціювання
Аналіз
Планування ресурсів

Збір інформації
Документи, що містять вимоги безпеки

Базовий аналіз
Оцінка адекватності вимог безпеки
Єдині критерії оцінки безпеки інформаційних технологій
Аналіз механізмів безпеки
Перевірка існування механізмів безпеки
Огляд методології реалізації механізмів безпеки
Детальний аналіз
Підходи до детального аналізу
Стратегії зосередження зусиль під час детального аналізу
Аналіз конкретних сценаріїв атак та процесів
Підготовка звітних документів за результатами атестації
Зміст звітних документів
Вступ

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

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

У набір керівних документів у сфері атестації було сформовано ще на початку 80-х. Вивчення та адаптація цих документів до російських умов може суттєво прискорити процес створення вітчизняної нормативної бази. Для федеральних органівСША основним документом у сфері атестації є Посібник з Проведення Атестації та Акредитації безпеки АС (FIPS PUB 102).

Ця робота є спробою використання вітчизняного досвіду та американської нормативної бази для створення спільного керівництва щодо проведення атестації АС з вимог безпеки інформації.
Використовувана термінологія

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

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

Примітка: Для визначеності в решті цієї статті стосовно АС використовуватиметься прийнятий у нашій країні термін - атестація.

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

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

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

У США терміном «акредитація безпеки АС» позначається санкція керівництва підприємства, що ґрунтується на результатах атестації, що дозволяє використовувати АС для обробки життєво-важливої та/або конфіденційної інформації в даному середовищі функціонування.

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

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

Усі АС мають певний ступінь критичності. Важливим питанням є наявність угоди про те, для яких АС потрібно проводити атестацію. Бажано мати упорядкований за пріоритетами перелік таких АС.
Опис процедури атестації

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

План підготовки та проведення атестації повинен визначати проблемні галузі, потреби у спеціальних знаннях, потреби в інструментарії для підтримки процедури оцінювання та інші питання, відповіді на які неможливо дати без проведення відповідного аналізу, характерного для етапу базового оцінювання та специфічного для кожної конкретної ситуації. Можна виділити чотири стадії планування:
Ініціювання.
Аналіз.
Планування ресурсів.
Документування плану проведення атестації.
1. Планування процедури атестації.

Ініціювання

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

Ухвалена схема проведення атестації оформляється у вигляді Технічного завдання та Плану-графіка робіт.
Аналіз

Аналіз становить основну частину процесу планування. У процесі аналізу розглядаються такі вопросы:
Вимоги безпеки
Початкові дані
Межі проведення атестації та розподіл робіт

Аналіз вимог безпеки

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

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

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

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

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

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

При визначенні складу експертної групи та розподілі робіт враховується низка характеристик АС. Основні характеристики, на які звертається увага, включають кількість та складність програмно-технічних компонентів АС та їх документованість.

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

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

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

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

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

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

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

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

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

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

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

Більшість роботи, виконуваної при атестації (включаючи фазу планування), полягає у зборі інформації. Розглянемо три основні методи збору інформації:
Отримання інформації від обслуговуючого персоналу та розробників АС.
Вивчення документації.
Проведення опитувань.

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

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

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

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

Для проведення атестаційних випробувань мають бути підготовлені такі документи:

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

Документи, що містять вимоги безпеки

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

Типовий набір керівних документів, що використовуються при атестації АС у нашій країні, включає, але не вичерпується, наступними документами:
Закон РФ від 20 лютого 1995 р. № 24-Ф3 «Про інформацію, інформатизації та захист інформації»;
Закон РФ від 4 липня 1996 р. № 85-Ф3 «Про участь у міжнародному інформаційному обміні»;
Указ Президента РФ від 6 березня 1997 р. № 188 "Про затвердження переліку відомостей конфіденційного характеру";
«Автоматизовані системи. Захист від несанкціонованого доступу до інформації. Класифікація АС та вимоги до захисту інформації», Гостехкомісія Росії, 1997;
«Кошти обчислювальної техніки. Захист від НСД до інформації. Показники безпеки від НСД до інформації», Гостехкомісія Росії, 1992.

З перерахованих нормативних документів останні два мають особливе значення для атестації.

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

РД Держтехкомісії РФ «АС. Захист від НСД до інформації. Класифікація АС та вимоги щодо захисту інформації» встановлює класифікацію АС, що підлягають захисту від несанкціонованого доступу до інформації, та вимоги щодо захисту інформації в АС різних класів. Визначальними ознаками, за якими проводиться угруповання АС у різні класи, є:
наявність у АС інформації різного рівня конфіденційності;
рівень повноважень суб'єктів доступу АС на доступ до конфіденційної інформації;
режим обробки даних в АС – колективний чи індивідуальний.

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

Крім цього, залежно від характеру АС, можуть використовуватися інші керівні документи Держтехкомісії РФ, які містять вимоги до конкретних класів СВТ, що входять до складу АС.
Звіт за результатами аналізу ризиків

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

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

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

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

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

У результаті базового аналізу вирішуються такі основні завдання:
Оцінка адекватності вимог безпеки.
Оцінка адекватності механізмів безпеки.
Перевірка існування механізмів безпеки.
Огляд методології реалізації механізмів безпеки.
Рисунок 3. Етапи базового аналізу АС

Оцінка адекватності вимог безпеки

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

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

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

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

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

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

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

Ресурси АС можна розділити на три категорії:
Інформаційні ресурси.
Програмне забезпечення.
Технічні кошти.

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

Важливість (або вартість) ресурсу визначається величиною збитків, завданих у разі порушення конфігурації Оновлено: 11.03.2015

Нещодавно, під час перельоту до Іжевська, гортав журнал, отриманий на борту і натрапив на статтю, присвячену персональним даним, у якій були такі висловлювання: « дуже хочеться донести до керівників комерційних підприємств, що роботи з атестації об'єктів інформатизації з вимог безпеки інформації необхідно було розпочати ще в 2006 році, коли був підписаний федеральний закон». І це класична помилка, яка досі зустрічається в регіонах, а іноді й нав'язується окремими працівниками регуляторів. Наскільки це правильно? Чи така обов'язкова атестація інформаційних систем? І взагалі, чи можлива вона в принципі?

Почнемо з визначення. Під атестацією об'єкта інформатизації за вимогами безпеки інформації розуміється комплекс організаційно-технічних заходів, у яких за допомогою спеціального документа - «Атестата відповідності» підтверджується, що об'єкт відповідає вимогам стандартів чи інших нормативних документів захисту інформації, затверджених ФСТЭК Росії. Єдиним документом, який описує цей процес, є Положення «З атестації об'єктів інформатизації з вимог безпеки інформації», затверджене ще 25 листопада 1994 року Головою Держтехкомісії (колишня назва ФСТЕК).

Спочатку розвінчуємо останню частину міфу про обов'язковість атестації. Дійсно, у першій версії документів ФСТЕК із захисту персональних даних була фраза про обов'язковість атестації ІСПДн 1-го та 2-го класів, а також розподілених ІСПДн 3-го класу. Проте документи ФСТЕК, випущені в лютому 2008 року, вже не діють - вони були скасовані рішенням колегії ФСТЕК у березні цього року, 2010-го. У єдиному чинному нині нормативно-правовому акті захисту персональних даних (а це наказ ФСТЕК №58) вимоги з атестації немає. Додатково слід зауважити, що згідно з уже згаданим положенням з атестації. обов'язковій атестації підлягають об'єкти інформатизації, призначені для обробки інформації, що становить державну таємницю, управління екологічно небезпечними об'єктами, ведення секретних переговорів». Додатково положення уточнює, що « в решті випадків атестація носить добровільний характер(добровільна атестація) та може здійснюватися з ініціативи замовника чи власника об'єкта інформатизації». Сама ФСТЕК чітко та ясно у своїх нормативних документах відповідає на питання про обов'язковість атестації інформаційних систем комерційних підприємств.

Тепер згадаймо другу частину міфу і подивимося, наскільки взагалі можлива атестація сучасної інформаційної системи. Почну з того, що атестації підлягає непросто набір програмних і апартних засобів, обробляють інформацію. Атестується об'єкт інформатизації, який згідно з ГОСТ Р 51275-2006 визначається як « сукупність інформаційних ресурсів, засобів та систем обробки інформації, що використовуються відповідно до заданої інформаційною технологією, засобів забезпечення об'єкта інформатизації, приміщень або об'єктів (будівель, споруд, технічних засобів), в яких вони встановлені, або приміщення та об'єкти, призначені для ведення конфіденційних переговорів». Іншими словами, виконання вимог безпеки перевіряється не тільки для конкретної інформаційної системи, але і для приміщеннях, в яких дана ІС функціонує.

Все б нічого і оцінка відповідності у формі атестації не викликала б таких гарячих суперечок, якби не наступний пункт положення ФСТЕК щодо атестації: « Атестат відповідності видається власнику атестованого об'єкта інформатизації органом з атестації на період, протягом якого забезпечується незмінністьумов функціонування об'єкту інформатизації». Чи можна за сучасних умов забезпечити незмінність об'єкта інформатизації?

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

Сьогодні, коли кількість компонентів сучасних ІС обчислюється десятками, не минає дня, щоб ІТ-департамент не отримував нові патчі та оновлення, що усувають виявлені баги та вразливості. Однак, « у разі зміни умов та технології обробки інформації, що захищається, власники атестованих об'єктів зобов'язані сповістити про це орган з атестації, який приймає рішення про необхідність проведення додаткової перевірки ефективності системи захисту об'єкта інформатизації.». А будь-яка переатестація це гроші та час. Чи готові ви кожні півроку (частіше не погодиться орган з атестації) переатестовувати свою систему, витрачаючи на це чималі гроші (вартість переатестації може досягати 30-50% від початкової ціни, яка приблизно дорівнює 20-30 тисяч рублів на один комп'ютер)? У результаті ви приходите до феномена. Або мати діючий атестат і не мати можливості оновлювати інформаційну систему, залишаючи її в уразливому стані. Або підняти рівень захищеності ІВ, втративши при цьому атестат. Більшість комерційних організацій обере другий варіант. Тоді навіщо взагалі потрібна атестація у тому вигляді, в якому її прийнято в Росії?

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

Чи це означає, що атестація нікому не потрібна? Зрозуміло, ні. Для держорганів та підприємств, що обробляють держтаємницю, це єдина процедура оцінки відповідності нормативним вимогам. Комерційному підприємству також така оцінка потрібна. Тільки зміст її має бути іншим. Наприклад, як зовнішнього аудиту чи проведення самооцінки за стандартами Банку Росії (СТО БР ИББС-1.2 чи РС БР ИББС-2.1).

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

Олександр Астахов, CISA,2000

Вступ

У набір керівних документів у сфері атестації було сформовано ще на початку 80-х. Вивчення та адаптація цих документів до російських умов може суттєво прискорити процес створення вітчизняної нормативної бази. Для федеральних органів США основним документом у сфері атестації є Посібник з Проведення Атестації та Акредитації безпеки АС (FIPS PUB 102).

Використовувана термінологія

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

Примітка: Для визначеності в решті цієї статті стосовно АС використовуватиметься прийнятий у нашій країні термін - атестація.

Опис процедури атестації

Планування

Ініціювання.
Аналіз.
Планування ресурсів.
Документування плану проведення атестації.

Ініціювання

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

Ухвалена схема проведення атестації оформляється у вигляді Технічного завдання та Плану-графіка робіт.

Аналіз

Аналіз становить основну частину процесу планування. У процесі аналізу розглядаються такі вопросы:

Вимоги безпеки
Початкові дані
Межі проведення атестації та розподіл робіт
Області підвищеної уваги
Необхідний рівень деталізації

Аналіз вимог безпеки

Аналіз складу вихідних даних

Визначення меж проведення атестації та розподіл робіт

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

Області підвищеної уваги

Необхідний рівень деталізації

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

Планування ресурсів

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

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

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

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

Збір інформації

Більшість роботи, виконуваної при атестації (включаючи фазу планування), полягає у зборі інформації. Розглянемо три основні методи збору інформації:

Отримання інформації від обслуговуючого персоналу та розробників АС
Вивчення документації
Проведення опитувань

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

Для проведення атестаційних випробувань мають бути підготовлені такі документи:

Документи, що містять вимоги безпеки

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

Закон РФ від 20 лютого 1995 р. № 24-Ф3 «Про інформацію, інформатизації та захист інформації»;
Закон РФ від 4 липня 1996 р. № 85-Ф3 «Про участь у міжнародному інформаційному обміні»;
Указ Президента РФ від 6 березня 1997 р. № 188 "Про затвердження переліку відомостей конфіденційного характеру";
«Автоматизовані системи. Захист від несанкціонованого доступу до інформації. Класифікація АС та вимоги до захисту інформації», Гостехкомісія Росії, 1997;
«Кошти обчислювальної техніки. Захист від НСД до інформації. Показники безпеки від НСД до інформації», Гостехкомісія Росії, 1992.

З перерахованих нормативних документів останні два мають особливе значення для атестації.

перша група містить лише один сьомий клас;
друга група характеризується дискреційним захистом та містить шостий та п'ятий класи;
третя група характеризується мандатним захистом та містить четвертий, третій та другий класи;
четверта група характеризується верифікованим захистом і містить лише перший клас.

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

Звіт за результатами аналізу ризиків

Діаграми інформаційних потоків додатків

Опис механізмів безпеки АС

Базовий аналіз

У результаті базового аналізу вирішуються такі основні завдання:

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

Оцінка адекватності вимог безпеки

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

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

Заходи щодо аналізу та управління ризиками

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

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

Ресурси АС можна розділити на три категорії:

Інформаційні ресурси.
Програмне забезпечення.
Технічні кошти.

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

Дані були розкриті, змінені, видалені або недоступні.
Апаратуру було пошкоджено або зруйновано.
Порушено цілісність ПЗ.

Типові загрози безпеці включають:

локальні та віддалені атаки на ресурси АС;
стихійні лиха;
помилки персоналу;
збої у роботі АС, спричинені помилками в ПЗ чи несправностями апаратури.

Під рівнем загрози розуміється можливість її здійснення.

Оцінка вразливостей передбачає визначення ймовірності успішного здійснення загроз безпеці. Успішне здійснення загрози означає заподіяння шкоди ресурсам АС. Наявність уразливостей в АС обумовлена ??слабкостями захисту.

Таким чином, ймовірність заподіяння шкоди визначається ймовірністю здійснення загрози та величиною вразливості.

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

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

Контрзаходи можуть сприяти зменшенню величини ризиків у різний спосіб:

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

Під час виконання робіт з аналізу та управління ризиками в компанії Інфосистеми Джет використовується методика CRAMM та відповідні інструментальні засоби. Метод CRAMM (UK UK Risk Analysis and Management Method) використовується починаючи з 1985 р. урядовими та комерційними організаціями Великобританії. За цей час він набув популярності у всьому світі.

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

Методика CRAMM кожного етапу визначає набір вихідних даних, послідовність заходів, анкети щодо опитувань, списки перевірки і набір вихідних документів (звітів).

Єдині критерії оцінки безпеки інформаційних технологій

У основі атестації АС нині лежать «Єдині критерії оцінки безпеки ІТ» (Common Criteria for Information Technology Security Evaluation). «Єдині критерії» - це нормативний документ, який визначає вимоги безпеки, на підставі яких проводиться оцінка рівня захищеності продуктів ІТ, загальний набір понять, структур даних та мова для формулювання питань та тверджень щодо безпеки продуктів ІТ.

Міжнародна організація зі стандартизації (ISO) розпочала розробку критеріїв оцінки захищеності у 1990 році. Потім автори канадського (CTCPEC), європейського (ITSEC) та американських (FC та TCSEC) критеріїв оцінки захищеності у 1993 році об'єднали свої зусилля та розпочали розробку проекту «Єдиних критеріїв». Метою проекту було усунення концептуальних та технічних відмінностей між існуючими критеріями. 1 грудня 1999 року версія 2.1 «Єдиних критеріїв» була прийнята ISO як міжнародний стандарт ISO 15408.

В «Єдиних критеріях» визначено низку ключових понять, що лежать в основі концепції оцінки захищеності продуктів ІТ. Серед них поняття профілю захисту (PP – Protection Profile), Завдання з безпеки (ST – Security Target) та Об'єкта оцінки (TOE – Target of Evaluation). Як Об'єкт оцінки може виступати будь-яке СВТ або АС.

PP є жорстко структурованим документом, що містить вимоги безпеки для певного класу програмно-технічних засобів. Крім вимог безпеки PP описує безліч загроз безпеки та завдань захисту, а також містить обґрунтування відповідності між загрозами безпеки, завданнями захисту та вимогами безпеки.

ST є жорстко структурованим документом, що визначає, крім вимог безпеки, функціональну специфікацію механізмів безпеки конкретного продукту ІТ. Вимоги безпеки, що містяться в ST, визначаються за допомогою посилань на відповідні Профілі захисту та вимоги «Єдиних критеріїв». Специфічні для конкретного продукту ІТ вимоги формулюються окремо і включаються до ST. Крім цього, ST містить обґрунтування відповідності між вимогами безпеки та функціональною специфікацією TOE.

У «Єдиних критеріях» представлені дві категорії вимог безпеки: функціональні вимоги та вимоги адекватності (гарантованості) механізмів безпеки. Функціональні вимоги визначають сукупність функцій TOE, які забезпечують безпеку. Адекватність - це властивість TOE, що дає певний ступінь впевненості в тому, що механізми безпеки TOE є досить ефективними та правильно реалізованими. Висновки про адекватність TOE робляться на підставі знань про специфікацію, реалізацію та функціонування TOE. Для вираження функціональних вимог та вимог адекватності в «Єдиних критеріях» використовується єдина термінологія та стиль.

Атестація - складний, тривалий та дуже ресурсомісткий процес. Через неможливість провести формальну верифікацію або вичерпне тестування всієї АС, доводиться говорити лише про досягнення певного рівня адекватності (гарантованості) результатів атестаційних випробувань. У «Єдиних умовах» вводиться єдина шкала рівнів адекватності оцінки (EAL – Evaluation Assurance Level). Кожен EAL представлений певною сукупністю вимог адекватності "Єдиних критеріїв".

Вводиться сім рівнів адекватності оцінки: EAL1, EAL2, …, EAL7. Ці рівні впорядковані за зростанням. Мінімальний рівень адекватності - EAL1 (функціональне тестування) надає мінімальні гарантії адекватності шляхом аналізу механізмів безпеки з використанням специфікацій функцій та інтерфейсу TOE, що супроводжується незалежним тестуванням кожного механізму безпеки за методом «чорної скриньки». EAL1 призначений для виявлення лише самих очевидних уразливостей захисту за мінімальних витрат. Він застосовується у тих випадках, коли відсутні серйозні ризики, пов'язані з безпекою. Максимальний рівень адекватності - EAL7 (формальна верифікація проекту та тестування) характеризується використанням при проектуванні комплексу засобів захисту формальної моделі, формального представлення функціональних специфікацій, напівформального представлення проекту нижнього рівня та формальної чи напівформальної демонстрації відповідності між ними. Аналізи супроводжуються незалежним тестуванням механізмів безпеки за методом «білої скриньки». Рівень EAL7 є верхньою межею рівнів адекватності оцінки АС, яку реально досягти на практиці. Його використання слід розглядати тільки як експериментальний для атестації простих та особливо критичних АС.

Згідно з «Єдиними критеріями» етапи оцінки захищеності TOE визначаються, виходячи з різних рівнівабстракції подання: загрози безпеці -> завдання захисту -> вимоги безпеки -> специфікація -> реалізація.

Виділяють два основні етапи проведення оцінювання:

Оцінка базових профілів захисту.
Аналіз об'єкта оцінки.

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

Аналіз об'єкта оцінки проводиться в два етапи: Оцінка Завдання з безпеки та Оцінка TOE.

Оцінка Завдання з безпеки має на меті демонстрацію того, що специфікація (формальний, напівформальний або неформальний опис) механізмів безпеки повністю відповідає вимогам профілю захисту та є придатною для використання як основа для оцінювання TOE;

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

Аналіз механізмів безпеки

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

Коли вимоги безпеки визначено

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

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

Коли вимоги безпеки не визначені

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

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

Рівень деталізації

Важливим питанням аналізу механізмів безпеки є вибір рівня деталізації. У випадку базовий аналіз повинен виконуватися на функціональному рівні. Функціональний рівень - це абстракції, представлений специфікаціями функцій АС. Це стосується як внутрішніх механізмів безпеки, так і зовнішніх (фізичних та адміністративних заходів захисту), хоча останні зазвичай не визначаються у функціональних специфікаціях.

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

Перевірка існування механізмів безпеки

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

Огляд методології реалізації механізмів безпеки

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

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

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

У нашій країні Держтехкомісією РФ було прийнято РД «Тимчасове положення щодо організації розробки, виготовлення та експлуатації програмних та технічних засобів захисту інформації від НСД в АС та СВТ», що визначає такі основні питання:

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

Підвищена увага під час огляду методології приділяється наступним питанням:

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

Детальний аналіз

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

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

Оцінка правильності функціонування механізмів безпеки.
Оцінка експлуатаційних характеристик, таких як надійність та продуктивність.
Оцінка стійкості до спроб злому.

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

Підходи до детального аналізу

Перевірка правильності функціонування механізмів безпеки

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

Під час тестування захисних механізмів вивчаються такі питання:

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

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

людина-людина (повідомлення оператора);
людина-система (команди, процедури);
система-система (внутрішні функції системи);
процес-система (системні виклики);
процес-процес (міжпроцесорна взаємодія).

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

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

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

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

Видається дуже перспективним використання автоматизованих систем доказу коректності програм. На цей час існує вже понад двадцять подібних систем. p align="justify"> Кожна з цих систем розроблялася для верифікації широкого класу програм певної предметної області. В їх основі лежать різні математичні апарати та різні принципи функціонування. Однак можна виділити компоненти, необхідні будь-якій подібній системі:

Мова формальної специфікації.
Цією мовою описуються вхідні та вихідні дані (структури даних, абстрактні типи даних).
Мова програмування.
Цією мовою пишеться програма. Для того, щоб правильність цієї програми можна було довести, семантика цієї мови має бути формально визначена.
Блок синтаксичного аналізу.
На вхід цього блоку надходить вже анотована програма, т. е. програма мовою програмування разом із її специфікацією мовою специфікації. Блок синтаксичного аналізу здійснює синтаксичний контроль та перетворює програму до спеціального вигляду, зручного для подальшої обробки.
Генератор умов коректності (генератор теорем).
Видає перелік умов коректності на вхід блоку підтвердження. Реалізує алгоритми зворотного та прямого простеження.
Блок підтвердження теорем.
Є найскладнішим. Він видає список спрощених умов коректності на вхід блоку аналізу виходу, серед яких виділено доведені умови. Блок доказу має додатковий вхід, який подається інформація від користувача як аксіом.
Блок аналізу вихідних даних
Здійснює спільно з користувачем аналіз списку умов коректності. Якщо всі умови доведені, вхідна програма частково коректна.

Наприклад, система FDM дозволяє користувачеві написати специфікацію формальної моделі (включаючи інваріанти та обмеження безпеки) мовою специфікації Ina Jo, а генератор теорем автоматично генерує теореми (критерій правильності), які повинні бути доведені, щоб гарантувати, що специфікація верхнього рівня відповідає моделі. Генератор теорем також автоматично генерує теореми, які необхідно довести, щоб гарантувати, що специфікація кожного рівня нижче випливає зі специфікації вищого рівня.

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

Існують успішні приклади застосування автоматизованих систем підтвердження коректності програм для верифікації механізмів безпеки. Наприклад, у проекті захищеної операційної системи UNIX, виконаний у Каліфорнійському університеті в місті Лос-Анжелес (UCLA), для перевірки механізмів захисту даних від несанкціонованого доступу використовувалися методи формальної специфікації та верифікації. У цьому проекті для доказу правильності програмного коду використовувався генератор умов коректності мови Паскаль системи AFFIRM. Докази умов правильності рівня проектування були виконані вручну, проте система AFFIRM використовувалася для перевірки частини цих доказів.

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

Оцінка експлуатаційних характеристик

Ефективність механізмів безпеки визначається як коректністю їх функціонування. Багато показників, що визначають ефективність, можна віднести до загальної категорії під назвою «експлуатаційні характеристики», яка є другою областю дослідження під час детального аналізу. До показників ефективності відносяться: надійність, стійкість до відмов, відновлюваність, час реакції і продуктивність. Вони застосовні як до окремих механізмів, і до АС загалом.

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

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

Стійкість до спроб злому

З використанням цього підходу ставиться завдання оцінити стійкість механізмів безпеки АС до спроб їх злому чи обходу. Стійкість – це здатність АС блокувати та оперативно реагувати на можливі атаки. p align="justify"> Методи криптоаналізу, наприклад, можуть використовуватися для злому конкретного механізму безпеки - шифрування. Створення та використання перехоплювача паролів – це приклад обходу механізмів безпеки.

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

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

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

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

Зовнішні порушники за рівнем своїх можливостей можуть підрозділятися на рівні.

У своєму рівні порушник є фахівцем вищої кваліфікації, знає все про АС і, зокрема, про систему та засоби її захисту.

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

Оцінка стійкості АС до спроб злому.
Визначення величини вразливостей (з якими труднощами пов'язане використання проломів у захисті).
Демонстрація можливостей використання проломів у захисті.

Існує кілька підходів до аналізу стійкості АС:

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

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

Стратегії зосередження зусиль під час детального аналізу

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

Аналіз компонентів моделі захисту АС

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

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

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

Атаки на ресурси АС, що вживаються як зовнішніми, і внутрішніми порушниками, поділяються на віддалені (мережні) і локальні.

Локальні атаки характеризуються такими атрибутами:

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

Віддалені (мережові) атаки додатково можуть характеризуватись наступними атрибутами:

Умова початку здійснення дії:
- Атака за запитом від об'єкта, що атакується.
- Атака щодо настання очікуваної події на об'єкті, що атакується.
- Безперечна атака.
За наявності зворотного зв'язку з об'єктом, що атакується:
- Зі зворотним зв'язком.
- Без зворотного зв'язку.
За розташуванням суб'єкта атаки щодо об'єкта, що атакується:
- Внутрішньосегментне.
- Міжсегментне.
За рівнем еталонної моделі OSI, на якому здійснюється вплив:
- Фізичний.
- Канальний.
- Мережевий.
- Транспортний.
- сеансовий.
- Представницький.
- Прикладний.
За характером впливу:
- Активний.
- Пасивне.

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

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

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

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

Аналіз конкретних сценаріїв атак та процесів

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

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

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

Підготовка звітних документів за результатами атестації

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

В американських керівних документах пропонується наступна структура підсумкового звіту:

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

До підсумкового звіту додаються такі документи:

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

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

За наявності зауважень непринципового характеру Атестат може бути виданий після перевірки усунення цих зауважень.

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