Політика безпеки

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

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

Політика безпеки включає:

ü Ідентифікацію та аутентифікацію користувачів;

ü Керування доступом (до електронних файлів, чітко обумовлюються користувачі, які мають доступ до файлів з дозволами на читання, запис і виконання).

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

Стандартними подіями є такі:

ü Спроби входу та виходу в/з систему (успішні або невдалі);

ü Помилки доступу до файлів або системних об’єктів;

ü Спроби віддаленого доступу (успішні або невдалі);

ü Дії привілейованих користувачів (адміністраторів), успішні або невдалі;

ü Системні події (вимикання та перезавантаження системи).

Кожна подія повинна включати наступну інформацію:

ü ID користувача (якщо є);

ü Дату й час;

ü ID процесу (якщо є);

ü Виконану дію;

ü Успішне або невдале завершення події.

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

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

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

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

ü Система з відмовою від захисту;

ü Розділ політики безпеки, відповідність якому буде порушено;

ü Відгалуження організації;

ü Кроки, що вживають для зниження або контролю ступеня небезпеки;

ü План відновлення відповідності системи вимогам політики безпеки;

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