Файл: 9_ua_2_.doc

3 Програма безпеки

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

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

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

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

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

• стратегічне планування;

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

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

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

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

Мета програми нижнього рівня - забезпечити надійний і економічний захист конкретного сервісу або групи однорідних сервісів. На цьому рівні розв’язується, які слід використовувати механізми захисту; закупляються і встановлюються технічні засоби; виконується повсякденне адміністрування; відстежується стан слабких місць і т.п. Звичайно за програму нижнього рівня відповідають адміністратори сервісів.

4 Синхронізація програми безпеки з життєвим циклом систем

---

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

В життєвому циклі інформаційного сервісу можна виділити наступні етапи:

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

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

Установка. Сервіс встановлюється, конфігурується, тестується і вводиться в експлуатацію.

Експлуатацію. На даному етапі сервіс не тільки працює і адмініструється, але і піддається модифікаціям.

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

Розглянемо дії, виконувані на кожному з етапів, більш докладно.

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

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

• якого роду інформація призначається для обслуговування новим сервісом?

• які можливі наслідки порушення конфіденційності, цілісності і доступності цієї інформації?

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

• чи є які-небудь особливості нового сервісу (наприклад, територіальна распределенность компонентів), що вимагають вживання спеціальних процедурних заходів?

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

• які законодавчі положення і внутрішні правила, яким винен відповідати новий сервіс?

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

---

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

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

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

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

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

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

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

---

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

---

Список літератури

1. Столлингс Вильям. Криптография и защита сетей: принципы и практика /Пер. с англ – М.: Издательский дом «Вильямс», 2001.

2. Иванов М.А. Криптографические методы защиты информации в компьютерных системах и сетях. – М.: КУДИЦ-ОБРАЗ, 2001.

3. Жельников В. Криптография от папируса до компьютера. – М.: ABF, 1996.

4. Бабенко Л.К. Введение в специальность «Организация и технология защиты информации». – Таганрог: Изд-во ТРТУ, 1999. –54с.

5. Брюхомицкий Ю.А. Введение в информационные системы. – Таганрог: Изд-во ТРТУ, 2001. – 151 с.

6. Зегжда Д.П., Ивашко А.М. Как построить защищенную информационную систему Под научной редакцией Зегжды Д.П. и Платонова В.В. – СПб: Мир и семья-95,1997. – 312 с.

7. Гайкович В.Ю., Ершов Д.В. «Основы безопасности информационных технологий»

8. Котухов М.М., Марков А.С. Законодательно-правовое и организационно-техническое обеспечение информационной безопасности автоматизированных систем. – 1998. – 158 с.

9. Информационно-безопасные системы. Анализ проблемы: Учеб. пособие Алешин Н. В, Коэлод В. Н., Нечаев Д. А., Смирнов А. С., Сычев М. П., Пальчун Б. П., Черноруцкий И. Г., Черносвитов А. В. Под ред. В. Н. Козлова. – СПб.: Издательство С.-Петербургского, гос. техн. университета, 1996. – 69 с.

10. Громов В.И., Василева Г.А. «Энциклопедия компьютерной безопасности»

5

---