Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Залік - відповіді.docx
Скачиваний:
105
Добавлен:
19.03.2015
Размер:
82.98 Кб
Скачать
        1. Розробка й аналіз профілю захисту

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

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

До класу D віднесено такі системи, які не пройшли випробування на більш високий рівень захищеності.

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

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

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

Клас В1: міточний захист. Доступ до об’єктів дозволяється в тому разі, якщо мітка суб’єкта задовольняє певний критерій відносно мітки об’єкта.

Клас В2: структурований захист. У цьому класі додатково до вимог класу В1 додаються вимоги керування інформаційними потоками. Вони вводяться згідно з політикою безпеки.

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

Клас А1: верифікація. Системи цього класу відрізняються від класу В3 тим, що для перевірки специфікацій застосовуються методи формальної верифікації — аналізу специфікацій системи на предмет неповноти або суперечності, що може призвести до появи проривів у безпеці.

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

  1. Структура профілів захисту.

Структура профілю захисту складається з таких поділів:

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

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

Розділ функціональних вимог повинний містити тільки типові вимоги, передбачені відповідними поділами “Єдиних критеріїв”. Функціональні вимоги можуть наказувати або забороняти використання конкретних методів і засобів захисту.

Розділ вимог адекватності також складається з типових вимог поділів “Єдиних критеріїв”.

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

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

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

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

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

31. Задачі та цілі управління інцидентами інформаційної безпеки.

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

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

Цілі управління інцидентами:

1. відновлення нормальної роботи служб в найкоротші терміни;

2. зведення до мінімуму впливу інцидентів на роботу організації;

3. забезпечення злагодженої обробки всіх інцидентів і запитів обслуговування;

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

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

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

Для забезпечення управління інцидентами система повинна виконувати наступні функції:

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

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

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

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

33. Об’єкти систему моніторингу інцидентів:

- апаратні засоби (комутатори, маршрутизатори, сканери, UTM пристрої).

- програмні комплекси (операційні системи, антивірусні шлюзи, персональні антивірусні системи, підсистеми обробки даних, доступні служби та сервіси);

- інформаційні ресурси (бази даних, файли користувачів доступні в мережі тощо);

- дії користувачів корпоративної мережі.

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

1) Планування і підготовки. (здійснюється розробка схеми управління інцидентами, розробка і затвердження ряду організаційно-регламентуючих документів, виділення людських і матеріальних ресурсів, проведення необхідного навчання та апробація обраної схеми управління.Відповідно до ISO/IEC TR 18044 необхідно створити групу щодо розслідування інцидентів ІБ.)

2) Експлуатації. (здійснюється виявлення інциденту ІБ, ідентифікація інциденту ІБ, реагування, розслідування й аналіз.)

3) Аналізу.( Група з реагування на інциденти проводить поглиблений аналіз інциденту, на основі результатів аналізу робляться висновки і складаються рекомендації щодо поліпшення процесу забезпечення ІБ та реагування на інциденти. Формується звіт про інцидент. Основним процесом етапу є поглиблений аналіз інциденту.)

4) Поліпшення. (здійснюється реалізація рекомендацій щодо поліпшення процесів забезпечення ІБ та реагування на інцидент. Затверджені уповноваженою особою організації рекомендації передаються на виконання відповідальним особам.)

35. Інциденти інформаційної безпеки, їх ознаки та основні категорії.

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

Міжнародний стандарт ISO/IEC 27001 «Інформаційні технології – Методи безпеки – Системи управління інформаційною безпекою – Вимоги» вводить наступні визначення: подія інформаційної безпеки: ідентифікований випадок стану системи або мережі, вказуючий на можливе порушення політики інформаційної безпеки або відмову засобів захисту, або раніше невідома ситуація, яка може бути істотною для безпеки.

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

Основні категорії інцидентів:

Додатки:

• служба недоступна;

• помилка в додатку, що не дає змогу клієнту нормально працювати;

• вичерпано дисковий простір.

Устаткування:

• збій системи;

• внутрішній сигнал тривоги;

• відмова принтера.

Заявки на обслуговування:

• надходження заявки на отримання додаткової інформації, поради, документації;

• забутий пароль.

Ознаки інциденту інформаційної безпеки

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

• повідомлення про інцидент інформаційної безпеки надходять одночасно з декількох джерел (користувачі, IDS, журнальні файли);

• IDS сигналізують про багаторазове повторення подій;

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

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

• IDS фіксує переповнення буферу;

• повідомлення антивірусної програми;

• крах web-інтерфейсу;

• користувачі повідомляють про достатньо низьку швидкість при спробі виходу в Internet;

• системний адміністратор фіксує наявність файлів з підозрілими назвами;

• користувачі повідомляють про наявність у своїх поштових скриньках багатьох повторюваних повідомлень;

• хост вносить запис до журналу аудиту про зміну конфігурації;

• додаток фіксує в журнальному файлі множинні невдалі спроби авторизації;

• адміністратор мережі фіксує різке збільшення мережевого трафіку.

36. Аналіз подій інформаційної безпеки, визначення інцидентів.

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

При аналізі інцидентів ІБ організація повинна виконати наступне:

• своєчасно ідентифікувати невдалі та успішні порушення безпеки і інциденти безпеки;

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

Визначення переліку подій, що є інцидентами, – важливий етап розробки процедури управління інцидентами. Зокрема, інцидентами інформаційної безпеки можуть бути:

• відмова в обслуговуванні сервісів, засобів обробки інформації, устаткування;

• порушення конфіденційності і цілісності цінної інформації;

• недотримання вимог до інформаційної безпеки, прийнятих в компанії (порушення правил обробки інформації);

• незаконний моніторинг інформаційної системи;

• шкідливі програми;

• компрометація інформаційної системи (наприклад, розголошення пароля користувача).