Приклади побудови захищених iнформацiйних технологiй

201

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

6.4.3 Засоби виявлення мережних атак

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

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

6.4.3.1. Методи аналiзу мережної iнформацiї

Ефективнiсть системи виявлення атак багато в чому залежить вiд застосовуваних методiв аналiзу отриманої iнформацiї. У перших системах виявлення атак, розроблених на початку 80-х рокiв, використалися статистичнi методи виявлення атак. У цей час до статистичного аналiзу додався ряд нових методик, починаючи з експертних систем, нечiткої логiки й закiнчуючи використанням нейронних мереж [10, 38].

Статистичний метод. Основнi переваги статистичного пiдходу це використання вже розробленого апарата математичної статистики, що добре зарекомендував себе, й адаптацiя до поведiнки суб’єкта.

Спочатку для всiх суб’єктiв аналiзованої системи визначаються профiлi. Будь-яке вiдхилення використовуваного профiлю вiд еталонного вважається несанкцiонованою дiяльнiстю. Статистичнi

202

Роздiл 6

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

“Статистичнi” системи не чутливi до порядку проходження подiй; у деяких випадках тi самi подiї залежно вiд порядку їхнього проходження можуть характеризувати аномальну або нормальну дiяльнiсть.

Дуже важко задати граничнi (граничнi) значення виявлення атак, що вiдслiдковують системою, характеристик, щоб адекватно iдентифiкувати аномальну дiяльнiсть.

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

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

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

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

З недолiкiв основним є неможливiсть вiдбиття невiдомих атак. При цьому навiть невелика змiна вже вiдомої атаки може стати

Приклади побудови захищених iнформацiйних технологiй

203

серйозною перешкодою для функцiонування системи виявлення атак.

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

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

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

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

Важливою перевагою нейронних мереж при виявленнi зловживань є їхня здатнiсть “вивчати” характеристики навмисних атак й iдентифiкувати елементи, якi не схожi на тi, що спостерiгалися в мережi колись.

Кожний з описаних методiв володiє рядом достоїнств i недолiкiв, тому зараз практично важко зустрiти систему, що реалiзує

204

Роздiл 6

тiльки один з описаних методiв. Як правило, цi методи використовуються в сукупностi.

6.4.3.2. Класифiкацiя систем виявлення атак

Механiзми виявлення атак, застосовуванi в сучасних системах виявлення атак IDS (Intrusion Detection System), заснованi на декiлькох загальних методах. Слiд зазначити, що цi методи не є взаємовиключними. У багатьох системах використовується комбiнацiя декiлькох методiв.

Класифiкацiя систем виявлення атак може бути виконана за декiлькома ознаками:

за способом реагування;

за способом виявлення атаки;

за способом збору iнформацiї про атаку.

За способом реагування розрiзняють пасивнi й активнi IDS. Пасивнi IDS просто фiксують факт атаки, записують данi у файл журналу й видають попередження. Активнi IDS намагаються протидiяти атацi, наприклад, шляхом реконфигурации межсетевого екрана або генерацiї спискiв доступу маршрутизатора.

За способом виявлення атаки системи IDS прийнято дiлити на двi категорiї:

виявлення аномального поводження (anomaly-based);

виявлення зловживань (misuse detection або signature-based). Технологiя виявлення атак шляхом iдентифiкацiї аномального

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

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

Приклади побудови захищених iнформацiйних технологiй

205

атак може iдентифiкувати як атаку типу “вiдмова в обслуговуваннi” (denial of service).

При використаннi системи з такою технологiєю можливi два крайнiх випадки:

виявлення аномального поводження, що не є атакою, i вiднесення його до класу атак;

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

При настроюваннi й експлуатацiї систем цiєї категорiї адмiнiстратори зiштовхуються з наступними проблемами:

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

визначення граничних значень характеристик поводження користувача для зниження ймовiрностi появи одного iз двох вищезгаданих крайнiх випадкiв.

Технологiя виявлення аномалiй орiєнтована на виявлення но-

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

Суть iншого пiдходу до виявлення атак виявлення зловживань полягає в описi атаки у виглядi сигнатури (signature) i пошуку даної сигнатури в контрольованому просторi (мережному трафiку або журналi реєстрацiї). Як сигнатура атаки може виступати шаблон дiй або рядок символiв, що характеризують аномальну дiяльнiсть. Цi сигнатури зберiгаються в базi даних, аналогiчної тiєї, котра використовується в антивiрусних системах. Варто вiдзначити, що антивiруснi резидентнi монiтори є часткою случаємо системи виявлення атак, але оскiльки цi напрямки споконвiчно розвивалися паралельно, те прийнято роздiляти їх. Тому дана технологiя виявлення атак дуже схожа на технологiю виявлення вiрусiв, при цьому система може виявити всi вiдомi атаки. Однак системи даного типу не можуть виявляти новi, ще невiдомi види

206

Роздiл 6

атак.

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

Слiд зазначити, що перша проблема вже частково вирiшена в деяких продуктах. Наприклад, компанiєю Internet Security Systems, Inc. реалiзовано систему опису мережних атак Advanced Packets Exchange, i з її допомогою розроблена система аналiзу захищеностi Internet Scanner. Найбiльш популярна класифiкацiя по способi збору iнформацiї про атаку:

виявлення атак на рiвнi мережi (network-based);

виявлення атак на рiвнi хоста (host-based);

виявлення атак на рiвнi додатка (application-based).

Система першого типу (network-based) працює за типом снiф-

фера, “прослуховуючи” трафiк у мережi й визначаючи можливi дiї зловмисникiв. Пошук атаки йде за принципом “вiд хоста до хоста”. Системи, що входять у перший клас, аналiзують мережний трафик, використовуючи, як правило, сигнатури атак й аналiз "нальоту". Метод аналiзу “на лету” полягає в монiторингу мережного трафiка в реальному або близькому до реального часу й використаннi вiдповiдних алгоритмiв виявлення. Часто використовується механiзм пошуку в трафике певних рядкiв, якi можуть характеризувати несанкцiоновану дiяльнiсть. До таких рядкiв можна вiднести `nnWINNTnSYSTEM32n CONFIG0 (даний рядок описує шлях до файлiв SAM, Security i т.iн.) або ` etc passwd0 (даний рядок описує шлях до списку паролiв ОС UNIX).

Системи другого типу (host-based) призначенi для монiторингу, детектувания й реагування на дiї зловмисникiв на певному хостi. Система, розташовується на хостi, що пiдлягає захисту, перевiряє й виявляє спрямованi проти нього дiї. Цi системи аналiзують реєстрацiйнi журнали операцiйної системи або додатка. Аналiз журналiв реєстрацiї є одним з найперших реалiзованих методiв виявлення атак. Вiн полягає в аналiзi журналiв реєстрацiї (log, audit

Приклади побудови захищених iнформацiйних технологiй

207

trail), створюваних операцiйною системою, прикладним програмним забезпеченням, маршрутизаторами й т.iн. Запису журналу реєстрацiї аналiзуються й iнтерпретуються системою виявлення атак. До достоїнств цього методу ставиться простота його реалiзацiї.

Однак за цiєю простотою ховається ряд недолiкiв:

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

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

до дiйсного моменту немає унiфiкованого формату зберiгання журналiв;

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

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

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

Третiй тип IDS (application-based) заснований на пошуку проблем у певному додатку.

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

208

Роздiл 6

6.4.3.3. Компоненти й архiтектура системи виявлення атак

На основi аналiзу iснуючих рiшень можна привести перелiк компонентiв, з яких складається типова система виявлення атак [38].

Модуль спостереження. Цей модуль забезпечує збiр даних з контрольованого простору (журналу реєстрацiї або мережного трафика). Рiзнi виробники дають цьому модулю наступнi назви: сенсор (sensor), монiтор (monitor), зонд (probe) i т.iн.

Залежно вiд архiтектури системи виявлення атак модуль спостереження може бути фiзично вiддiлений вiд iнших компонентiв, тобто перебувати на iншому комп’ютерi.

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

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

Сховище даних. Забезпечує зберiгання даних, зiбраних у процесi функцiонування системи виявлення атак.

Графiчний iнтерфейс. Навiть дуже потужний й ефективний засiб не буде використатися, якщо в нього вiдсутнiй дружнiй iнтерфейс. Залежно вiд операцiйної системи, пiд управлiнням якої функцiонує система виявлення атак, графiчний iнтерфейс повинен вiдповiдати стандартам де-факто для Windows й UNIX.

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

Пiдсистема управлiння компонентами. Дана пiдсистема призначена для управлiння рiзними компонентами системи вияв-

Приклади побудови захищених iнформацiйних технологiй

209

лення атак. Пiд термiном “управлiння” розумiється можливiсть змiни полiтики безпеки для рiзних компонентiв системи виявлення атак (наприклад, модулiв спостереження), а також одержання iнформацiї вiд цих компонентiв (наприклад, вiдомостей про зареєстровану атаку). Управлiння може здiйснюватися за допомогою як внутрiшнiх протоколiв й iнтерфейсiв, так i вже розроблених стандартiв, наприклад SNMP.

Системи виявлення атак будуються на основi двох архитектур: “автономний агент” й “агент-менеджер”. У першому випадку на кожний вузол, що пiдлягає захисту, або сегмент мережi встановлюються агенти системи, якi не здатнi обмiнюватися iнформацiєю мiж собою, а також не можуть управлятися централiзовано з єдиної консолi. Цих недолiкiв позбавлена архiтектура “агент-менеджер”. У цьому випадку в розподiленiй системi виявлення атак dIDS (distributed IDS), що складає з безлiчi IDS, розташованих у рiзних дiлянках великої мережi, сервери збору даних i центральний сервер, що аналiзує, здiйснюють централiзований збiр й аналiз регистрируемых даних, Управлiння модулями dIDS здiйснюється iз центральної консолi управлiння [36]. Для великих органiзацiй, у яких фiлiї рознесенi по рiзних територiях i навiть мiстах, використання такої архiтектури має принципове значення.

Загальна схема функцiонування dIDS наведена на рисунку 6.30. Така система дозволяє пiдсилити захищенiсть корпоративної подсети завдяки централiзацiї iнформацiї про атаку вiд рiзних IDS. Розподiлена система виявлення атак dIDS складається з наступних пiдсистем: консоль управлiння, що аналiзують сервери, агенти мережi, сервер збору iнформацiї про атаку. Центральний сервер, що аналiзує, звичайно складається з бази даних й Webсервера, що дозволяє зберiгати iнформацiю про атаки й манiпулювати даними за допомогою зручного Web-iнтерфейсу. Агент мережi один з найбiльш важливих компонентiв dIDS. Вiн являє собою невелику програму, цiль якої повiдомляти про атаку на центральний сервер, що аналiзує.

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

210

Роздiл 6

Рис. 6.30. Загальна схема функцiонування розподiленої IDS

пних параметрах:

IP-адреса атакуючi;

порт одержувача;

номер агента;

дата, час;

протокол;

тип атаки й т.iн.

Незважаючи на деякi сумнiви в ефективностi застосування IDS користувачi вже широко застосовують як вiльно розповсюджуванi, так i комерцiйнi засоби IDS.

Приклади побудови захищених iнформацiйних технологiй

211

6.4.3.4. Системи виявлення атак на мережному й операцiйному рiвнях

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

Використання методу виявлення атак у мережному трафiку має певнi достоїнства:

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

системи, побудованi з урахуванням цього методу, можуть визначати атаки в реальному масштабi часу;

виявлення невдалих атак або пiдозрiлої дiяльностi.

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

Принципова перевага мережних (network-based) систем виявлення атак полягає в тому, що вони iдентифiкують напади перш, нiж тi досягнуть вузла, що атакує. Цi системи простiше для розгортання у великих мережах, тому що вони не вимагають установки на рiзнi платформи, використовуванi в органiзацiї. Крiм того, системи виявлення атак на рiвнi мережi практично не знижують продуктивностi мережi.

Однак системи виявлення мережних атак також мають i свої недолiки:

такi системи важко застосовнi у високошвидкiсних мережах. Всi сучаснi комерцiйнi системи, незважаючи на те що вони анонсують можливiсть роботи з мережами Fast Ethernet (100 Мбит/с), не можуть працювати в мережах iз пропускною здатнiстю вище 60-80 Мбит/з;

мережнi IDS неефективно працюють у комутованих мережах i мережах з канальним шифруванням.

212

Роздiл 6

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

Такi системи виявлення атак сильно завантажують процесор i вимагають бiльших обсягiв дискового простору для зберiгання журналiв реєстрацiї. Тому вони в принципi незастосовнi для высококритичних систем, що працюють у режимi реального часу (наприклад, системи “Операцiйний день банку” або системи диспетчерського управлiння).

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

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

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

Iдеальним рiшенням була б система виявлення атак, що поєднує в собi обоє цi пiдходу. Цiй вимозi задовольняє система RealSecure, розроблена компанiєю Internet Security Systems, Inc. До складу цiєї системи входять мережний i системний агенти, що виявляють атаки на рiвнi мережi й хоста вiдповiдно.

Iснує ще одна класифiкацiя систем виявлення атак. Вона дiлить

Приклади побудови захищених iнформацiйних технологiй

213

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

Переваги й недолiки кожного з пiдходiв залежать вiд того, як буде застосовуватися система виявлення атак. У випадку высококритичных систем, таких як, наприклад, “Банкiвський операцiйний день”, виявлення атак у реальному режимi часу є обов’язковим, оскiльки зловмисник може проникнути в систему, зробити все необхiдне й зникнути протягом декiлькох хвилин або навiть секунд.

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

6.4.3.5. Методи реагування

Атака не тiльки повинна бути виявлена, необхiдно ще правильно й вчасно зреагувати на неї. В iснуючих системах застосовується широкий спектр методiв реагування, якi можна роздiлити на три категорiї [10, 38]:

повiдомлення;

зберiгання;

активне реагування.

Застосування того або iншого методу залежить вiд багатьох

факторiв.

214

Роздiл 6

Повiдомлення. Найпростiшим i широко розповсюдженим методом повiдомлення є вiдправлення адмiнiстраторовi безпеки повiдомлень про атаку на консоль системи виявлення атак. Така консоль може бути встановлена не в кожного спiвробiтника, що вiдповiдає в органiзацiї за безпеку, крiм того, цих спiвробiтникiв можуть цiкавити не всi подiї безпеки, тому необхiдно застосування iнших механiзмiв повiдомлення. Такими механiзмами можуть бути вiдправлення повiдомлень по електроннiй поштi, на пейджер, по факсу або по телефонi. Останнi два варiанти присутнi в системi виявлення атак RealSecure американської компанiї Internet Security Systems, Inc.

До категорiї “повiдомлення” ставиться також посилка керуючих послiдовностей до iнших систем, наприклад до систем мережного управлiння або до мiжмережних екранiв (Checkpoint FireWall-1, Raptor Firewall i т.д.). У першому випадку використовується стандартизований протокол SNMP, а в другому внутрiшнi або стандартизованi (наприклад, SAMP) протоколи.

Збереження. До категорiї “збереження” ставиться два варiанти реагування:

реєстрацiя подiї в базi даних;

вiдтворення атаки в реальному масштабi часу.

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

Активне реагування. До цiєї категорiї ставляться наступнi варiанти реагування:

блокування роботи атакуючого;

завершення сесiї з атакуючим вузлом;

управлiнням мережним устаткуванням i засобами захисту. Системи виявлення атак можуть запропонувати наступнi кон-

кретнi варiанти реагування: блокування облiкового запису атакуючого користувача, автоматичне завершення сесiї з атакуючим вузлом, реконфiгурацiю мiжмережних екранiв i маршрутизаторiв i

Приклади побудови захищених iнформацiйних технологiй

215

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

Огляд сучасних засобiв виявлення атак

У цей час на розвиток i захищенiсть мереж значно впливає ряд факторiв:

об’єднання локальних мереж пiдроздiлiв у єдину корпоративну мережу органiзацiї;

пiдключення корпоративної мережi органiзацiї до мережi Iнтернет;

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

рiзке збiльшення швидкостей передачi й обсягiв переданої iнформацiї;

використання в корпоративнiй мережi рiзноманiтного програмного й апаратного забезпечення.

Дiя цих факторiв приводить до розширення границь мережi,

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

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

Ефективний захист складається не тiльки iз застосування традицiйних механiзмiв забезпечення безпеки (криптографiї, автентифiкацiї, контролю доступу й т.д.). Модель адаптивного управлiння безпекою мережi ANS (Adaptive Network Security) дозволяє контролювати й виявляти постiйно, що змiнюються погрози, i ризики безпеки, реагувати на них у режимi реального часу, використовуючи правильно спроектованi й добре керованi процеси й за-

216

Роздiл 6

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

Приведемо приклади конкретних реалiзацiй технологiй управлiння безпекою мережi. Очевидно, що одна система не в змозi ефективно реалiзувати весь комплекс таких технологiй. Тому для реалiзацiї концепцiї адаптивної безпеки необхiдно використати сукупнiсть систем, об’єднаних загальним задумом. На ринку представлено кiлька десяткiв комерцiйних систем IDS, що забезпечує вибiр прийнятного рiшення. У цей час закiнченi рiшення пропонують компанiї Internet Security Systems, Cisco Systems i деякi iншi [10, 38]. Нижче описанi продукти зазначених компанiй.

Продукти компанiї Internet Security Systems

Компанiя ISS займає провiднi позицiї в частинi реалiзацiї систем виявлення атак. Вона пропонує цiле сiмейство рiшень для рiзних рiвнiв.

RealSecure Network Sensor програмне рiшення, призначене для установки на видiлений комп’ютер у критичному сегментi мережi. Аналiзуючи мережний трафик i зiставляючи його з базою сигнатур атак, сенсор виявляє рiзнi порушення полiтики безпеки.

Система RealSecure Gigabit Sensor обробляє бiльше 500 тис. пакетiв у секунду, використовуючи запатентований алгоритм семиуровневого аналiзу, виявляє велику кiлькiсть атак, що пропускають iншими системами. Застосовується головним чином у мережах, що працюють iз великим навантаженням.

RealSecure Server Sensor дозволяє виявляти атаки, спрямованi на конкретний вузол мережi, на всiх рiвнях. Крiм виявлення атак RealSecure Server Sensor має можливiсть проведення аналiзу захищеностi й виявлення уразливостей на контрольованому вузлi.

Система виявлення атак RealSecure Desktop Protector (ранiше називалася BlacklCE Agent) є програмним рiшенням, призначеним для виявлення в реальному масштабi часу мережних атак, спрямованих на робочi станцiї корпоративної мережi.

Приклади побудови захищених iнформацiйних технологiй

217

RealSecure for Nokia це програмно-апаратне рiшення, розроблене компанiями Internet Security Systems й Nokia. Воно поєднує в собi всi функцiональнi можливостi мережного сенсора RealSecure Network Sensor й Nokia IP Network Security Solutions. Система RealSecure for Nokia функцiонує пiд управлiнням захищеної операцiйної системи IPSO, що базується на ОС FreeBSD.

Система RealSecure Guard є програмним рiшенням, що сполучає в собi можливостi межсетевого екрана й системи виявлення атак у режимi реального часу. Система RealSecure Guard установлюється мiж що захищає й вiдкритим сегментами мережi (так називана inline-IDS) i аналiзує весь минаючий через неї трафик у пошуках заборонених або небезпечних пакетiв. Система RealSecure Guard може виявляти атаки як на сегменти мережi (Fast Ethernet), так i на окремi, найбiльш важливi вузли.

Для управлiння перерахованими системами RealSecure використається модуль RealSecure SiteProtector, що служить основним компонентом централiзованого управлiння й для систем Internet Scanner й System Scanner. Дана система орiєнтована на застосування у великих, територiально-розподiлених мережах або в органiзацiях, що використають одночасно кiлька рiшень компанiї ISS.

Бiльше простий модуль RealSecure WorkGroup Manager призначений для управлiння тiльки RealSecure Network Sensor, Gigabit Sensor, RealSecure Server Sensor й RealSecure for Nokia. Цей модуль управлiння орiєнтований на застосування в компанiях, у яких вiдсутнi iншi рiшення компанiї ISS й у мережi встановлене невелике число сенсорiв (до п’яти).

RealSecure Command Line Interface призначений для управлiння з командного рядка тiльки RealSecure Network Sensor й Gigabit Sensor. Цей модуль управлiння орiєнтований на локальне використання. Модуль RealSecure Sensor Manager являє собою графiчну надбудову над iнтерфейсом командного рядка.

Продукти компанiї Cisco Systems

Серiя продуктiв Cisco IDS,що випускається компанiєю Cisco Systems мiстить рiшення для рiзних рiвнiв. У неї входять три системи 42хх версiї 2.2.1 (network-based), серед яких:

218

Роздiл 6

Cisco IDS 4210 v.2.2.1 оптимизирована для монiторингу атак у середовищi 10/100BASE-T, швидкiсть 45 Мб/з (network-based);

Cisco IDS 4235 v.2.2.1 оптимизирована для монiторингу атак у середовищi 10/100/1000BASE-TX, швидкiсть 200 Мб/з (networkbased);

Cisco IDS 4250 v.2.2.1 оптимизирована для монiторингу атак у середовищi 10/100/1000BASE-TX, швидкiсть 500 Мб/з, може бути використана для захисту гiгабiтной мережi (network-based).

У комутаторi Catalyst є пiдсистема IDS Catalyst 6000 Intrusion Detection System Module (swithed-integrated network-based).

Cisco IDS Host Sensor 2.0 й Cisco IDS Host Sensor Web Server, розробленi компанiєю Entercept, забезпечують захист на рiвнi хоста (host-based).

IDS на рiвнi маршрутизатора (Firewall Feature Set 12.1(4)T) здатна вiдбивати 59 найнебезпечнiших видiв атак (система network-based).

При використаннi IDS на рiвнi межсетевого екрана PIX 535, 525, 515Е, 506Е, 501 (v.6.2.2) вiдбивається бiльше 55 найнебезпечнiших видiв атак (система network-based).

Управлiння системами захисту здiйснюється за допомогою CiscoWorks VPN/ Security Management Solution (VMS) або Cisco IDS software version 3.1(2).

Кориснi системи й продукти IDS випускають i ряд iнших компанiй, зокрема Symantec, Enterasys Networks, Computer Associates, NFR Security, Intrusion Inc., OneSecure, Recourse Technologies й iн.

6.5 Технологiї керування безпекою

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

Приклади побудови захищених iнформацiйних технологiй

219

то зараз потрiбно забезпечити iнформацiйну безпеку корпоративних бiзнес-процесiв.

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

централiзовано й оперативно робити керуючi впливи на всю iнформацiйну iнфраструктуру;

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

накопичувати статистичнi данi про роботу iнформацiйної iнфраструктури для прогнозування її розвитку.

6.5.1Завдання управлiння системою iнформацiйної безпеки

Найважливiшим компонентом системи управлiння корпоративною мережею є система iнформацiйної безпеки пiдприємства. Сформулюємо основнi завдання управлiння системою iнформацiйної безпеки масштабу пiдприємства.

Система управлiння засобами захисту iнформацiї в розподiленiй мережi масштабу пiдприємства повинна вирiшувати наступнi завдання:

управлiння полiтикою безпеки в рамках мережi пiдприємства, формування локальних полiтик безпеки (ЛПБ) окремих пристроїв i доведення ЛПБ до всiх пристроїв захисту iнформацiї;

управлiння конфiгурацiєю об’єктiв i суб’єктiв доступу; включає управлiння складом, версiями, компонентами пристроїв i ПЗ захисти, а також управлiння патчами, якi служать для закриття “дiр”, виявлених у поставлених продуктах забезпечення безпеки;

надання сервiсiв захисту розподiленим прикладним системам, реєстрацiя захищених додаткiв й їхнiх ресурсiв. Додатки цiєї групи повиннi забезпечувати насамперед iнтерфейс (API) для управлiння сервисами захисту з боку прикладних систем;

управлiння криптозасобами, зокрема управлiння ключами (ключова iнфраструктура). Ключова iнфраструктура повинна

220

Роздiл 6

функцiонувати в складi iнфраструктурних (системостворюючих) служб;

протоколювання подiй; включає настроювання видачi логiв на рiзнi пристрої, управлiння рiвнем деталiзацiї логiв, управлiння складом подiй, по яких ведеться протоколювання;

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

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

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

забезпечення роботи проектно-iнвентаризацiйної групи додаткiв; ця група додаткiв повинна здiйснювати:

- визначення точок установки засобiв захисту в мережi пiдприємства;

-облiк застосовуваних засобiв захисту; - контроль модульного складу засобiв захисту;

-контроль стану засобiв захисту й iн.

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

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

Приклади побудови захищених iнформацiйних технологiй

221

Cisco Systems, Computer Associates, Hewlett Packard, PLATINUM Technology, Tivoli Systems) пiшли по шляху iнтеграцiї механiзмiв управлiння засобiв захисту в традицiйнi системи управлiння мережами. Однак часто такi комплекснi системи управлiння вiдрiзняються високою вартiстю, i крiм того, деякi аспекти управлiння безпекою залишаються за межами уваги цих систем.

Другий пiдхiд полягає у використаннi засобiв призначенi для рiшення тiльки одного завдання управлiння безпекою. Наприклад, Open Security Manager (OSM) вiд Check Point Software Technologies дає можливiсть централiзовано управляти корпоративною полiтикою безпеки й iнсталювати її на мережнi пристрої по всiй компанiї. Продукт OSM є однiєї з основних компонентiв технологiї OPSEC (Open Platform for Secure Enterprise Connectivity), розробленою компанiєю Check Point, вiн створює iнтерфейс для управлiння пристроями мережної безпеки рiзних виробникiв (наприклад, Cisco, Bay, 3Com).

6.5.2Архiтектура управлiння засобами мережної безпеки

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

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

222

Роздiл 6

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

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

6.5.2.1. Основнi поняття

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

первинних пристроїв занадто багато, що може привести до перевантаження єдиного центра управлiння другорядними даними й завданнями;

єдиному центру не завжди доступна детальна iнформацiя, необхiдна для здiйснення оптимального управлiння;

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

Зiншого боку, децентралiзацiя управлiння може привести до втрати його ефективностi й рiзкому зниженню безпеки ресурсiв мережi в цiлому.

Досвiд провiдних пiдприємств-виробникiв засобiв мережної безпеки показує, що компанiя зможе успiшно реалiзувати свою полiтику безпеки в розподiленiй корпоративнiй iнформацiйнiй системi, якщо управлiння безпекою буде централiзованим i не залежним вiд використовуваних ОС i прикладних систем. Крiм того, система реєстрацiї подiй, що вiдбуваються в КIС (подiї НСД, змiна привiлеїв користувачiв i т.д.), повинна бути єдиної й дозволяти

Приклади побудови захищених iнформацiйних технологiй

223

адмiнiстраторовi скласти повну картину змiн, що вiдбуваються в КIС.

Для вирiшення ряду завдань управлiння безпекою потрiбне застосування єдиних вертикальних iнфраструктур типу каталогу Х.500. Наприклад, полiтика мережного доступу вимагає знання iдентифiкаторiв користувачiв. Ця iнформацiя потрiбна й iншим додаткам, наприклад, у системi кадрового облiку, у системi однократного доступу до додаткiв (single sign-on) i т.д. Дублювання тих самих даних приводить до необхiдностi синхронiзацiї, збiльшенню трудомiсткостi й ризику виникнення плутанини. Тому, щоб уникнути такого дублювання, часто використовують єдинi вертикальнi iнфраструктури.

До таких вертикальних структур, що використовуються рiзними користувальницькими пiдсистемами, якi працюють на рiзних рiвнях OSI/ISO, вiдносяться:

iнфраструктури управлiння вiдкритими ключами PKI. Слiд зазначити цiкавий аспект, поки не одержав широкого поширення, але важливий для управлiння. Зараз використаються цифровi сертифiкати в основному у виглядi так званих “посвiдчень особи” (identity certificates), але вже пiдспудно розвиваються й подекуди застосовуються цифровi сертифiкати у виглядi так званих “вiрчих грамот” (credential certificates);

видаючи й вiдзиваючи такi “вiрчi грамоти”, можна бiльш гнучко управляти доступом;

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

системи автентифiкацiї (звичайно RADIUS, сервери TACACS, TACACS+);

системи протоколювання подiй, монiторингу й аудита (слiд зазначити, що цi системи не завжди вертикальнi, часто спецiалiзуються й працюють автономно в iнтересах конкретних пiдси-

стем).

Науково-iнженерне пiдприємство TrustWorks Systems розробило концепцiю глобального управлiння безпекою, що дозволяє по-

224

Роздiл 6

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

управлiння безпекою корпоративної мережi повинне здiйснюватися на рiвнi глобальної полiтики безпеки (ГПБ GSP, Global Security Policy). Глобальна полiтика безпеки являє собою набiр правил безпеки для безлiчi взаємодiй мiж об’єктами корпоративної мережi, а також мiж об’єктами корпоративної мережi й зовнiшнiх об’єктiв;

ГПБ повинна вiдповiдати бiзнес-процесам компанiї. Для цiєї властивостi безпеки об’єктiв i необхiднi сервiси безпеки повиннi бути описанi з урахуванням їх бiзнес-ролей у структурi компанiї;

для окремих засобiв захисту формуються локальнi полiтики безпеки (ЛПБ LSP, Local Security Policy). Трансляцiя ЛПБ повинна здiйснюватися автоматично на основi аналiзу правил ГПБ i топологiї, що захищає мережi.

Зогляду на, що розроблена НIП TrustWorks Systems методологiя централiзованого управлiння мережною безпекою досить повно вiдбиває сучаснi тенденцiї розвитку технологiй безпеки, розглянемо докладнiше цю методологiю й деякi аспекти її реалiзацiї.

6.5.2.2.Концепцiя глобального управлiння безпекою

Восновi централiзованого управлiння безпекою КIС лежить концепцiя глобального управлiння GSM (Global Security Management). Концепцiя GSM дозволяє побудувати комплексну систему управлiння й захисту iнформацiйних ресурсiв пiдприємства з наступними властивостями:

управлiння всiма iснуючими засобами захисту на базi полiтики безпеки пiдприємства, що забезпечує цiлiснiсть, несуперечнiсть i повноту набору правил захисту для всiх ресурсiв пiдприємства (об’єктiв полiтики безпеки) i погоджене виконання полiтики безпеки як засобами захисту Trusted Agent виробництва компанiї TrustWorks Systems, так i засобами захисту, що поставляють третiми виробниками;

Приклади побудови захищених iнформацiйних технологiй

225

визначення всiх iнформацiйних ресурсiв пiдприємства через єдиний (розподiлений) каталог середовища пiдприємства, що може актуалiзуватися як за рахунок власних засобiв опису ресурсiв, так i за допомогою зв’язку з iншими каталогами пiдприємства (у тому числi, за протоколом LDAP);

централiзоване, засноване на полiтику безпеки (policy-based) управлiння локальними засобами захисту iнформацiї;

строга автентифiкацiя об’єктiв полiтики в середовищi пiдприємства з використанням РКС5#11-токенов й iнфраструктури вiдкритих ключiв PKI, включаючи можливiсть застосування додаткових локальних засобiв автентифiкацiї LAS (на вибiр споживача);

розширенi можливостi адмiнiстрування доступу до певних у каталозi ресурсiв пiдприємства або частин усього каталогу (з пiдтримкою понять груп користувачiв, доменiв, департаментiв пiдприємства), управлiння ролями як набором прав доступу до ресурсiв пiдприємства, введення в полiтику безпеки елементiв непрямого визначення прав через атрибути прав доступу (credentials);

забезпечення пiдзвiтностi (реєстрацiя всiх операцiй взаємодiй розподiлених об’єктiв системи в масштабах корпоративної мережi) i аудита, монiторингу безпеки, тривожної сигналiзацiї;

iнтеграцiя iз системами загального управлiння, iнфраструктурними системами безпеки (PKI, LAS, IDS).

Урамках даної концепцiї пiд визначенням “управлiння, засноване на полiтицi безпеки РВМ (Policy based management)” розумiється реалiзацiя набору правил управлiння, сформульованих для бiзнес-об’єктiв пiдприємства, що гарантує повноту охоплення бiзнес-галузi об’єктами й несуперечнiсть використовуваних правил управлiння.

Система управлiння GSM, орiєнтована на управлiння безпекою пiдприємства на принципах РВМ, задовольняє наступним вимогам:

полiтика безпеки пiдприємства являє собою логiчно й семантично зв’язану, формовану, редаговану й аналiзовану як єдине цiле структуру даних;

полiтика безпеки пiдприємства визначається в єдиному кон-

226

Роздiл 6

текстi для всiх рiвнiв захисту, як єдине цiле мережної полiтики безпеки й полiтики безпеки iнформацiйних ресурсiв пiдприємства;

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

Для того щоб мiнiмiзувати число параметрiв полiтики, використовуються наступнi прийоми:

Груповi визначення об’єктiв безпеки.

Непрямi визначення, наприклад на основi вiрчих (credential) атрибутiв.

Мандатне управлiння доступом (на додаток до фiксованого доступу), коли рiшення про доступ визначається на основi зiставлення рiвня доступу, яким володiє суб’єкт, i рiвня конфiденцiйностi (критичностi) ресурсу, до якого здiйснюється доступ.

Система управлiння GSM забезпечує рiзноманiтнi механiзми аналiзу полiтики безпеки за рахунок засобiв багатокритерiальної перевiрки вiдповiдностi полiтики безпеки формальним моделям концепцiї безпеки пiдприємства.

Нижче приводиться розроблена компанiєю TrustWorks оригiнальна концепцiя визначення глобальної полiтики безпеки мережi пiдприємства й опис побудованої на базi полiтики ГПБ системи управлiння безпекою (policy based security management).

6.5.2.3. Глобальна й локальна полiтики безпеки

Глобальна полiтика безпеки корпоративної мережi являє собою скiнченну множину правил безпеки (security rules), якi описують параметри взаємодiї об’єктiв корпоративної мережi в контекстi iнформацiйної безпеки:

необхiдний для з’єднання сервiс безпеки: правила обробки, захисту й фiльтрацiї трафiка;

напрямок надання сервiсу безпеки;

правила автентифiкацiї об’єктiв;

правила обмiну ключами;

правила запису результатiв подiй безпеки в системний журнал;

правила сигналiзацiї про тривожнi подiї й iн.

Приклади побудови захищених iнформацiйних технологiй

227

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

Завдання захисту бiзнес-об’єктiв розподiленої корпоративної системи можна сформулювати в термiнах правил, оскiльки мережна взаємодiя представляється як проста передача iнформацiї мiж суб’єктом Subj й об’єктом Obj доступу на основi деякого мережного сервiсу захисту SecSrv, настроєного за допомогою параметрiв Р. У результатi глобальна полiтика безпеки пiдприємства представляється як набiр правил виду

(Subj, Obj, SecSrv (P)).

При цьому вiдсутнiсть правила для об’єкта Obj означає заборону будь-якого доступу до даного об’єкта.

Для простоти визначення цiлей безпеки пiдприємства в GSM передбачено два типи об’єктiв, що виступають у якостi Subj й Obj. Це - користувач (U) i ресурс (R).

Ресурс R може бути iнформацiйним (IR) або мережним (NR). Користувач i ресурс можуть виступати в кожнiй з форм агрегацiї, пiдтримуваних у системi: групи, домени, ролi, департаменти,

роздiли каталогу.

Приклад: правило (U, IR, S1) являє собою правило захисту S1, що забезпечується при доступi користувача U до iнформацiйного ресурсу IR. Правило (IR1, IR2, S2) означає дозвiл мережної взаємодiї двох iнформацiйних модулiв (програм) з необхiднiстю забезпечення властивостей захисту S2.

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

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

228

Роздiл 6

ного управлiння, - стартова полiтика безпеки пристрою. Правила ГПБ можуть бути поширенi як на мережнi взаємодiї,

так i на функцiї контролю й управлiння самої системи. Функцiонально правила ГПБ розбитi по групах:

правила VPN. Правила даного типу реалiзуються за допомогою протоколiв IPsec; агентом виконання даного правила є драйвер VPN у стецi клiєнтського пристрою або шлюзу безпеки (IP1, IP2, VPNRule);

правила пакетної фiльтрацiї, включаючи NAT. Цi правила за-

безпечують пакетну фiльтрацiю типу stateful й stateless; виконання цих правил забезпечують тi ж агенти, що й для VPNправил (IP1, IP2, PacketRule);

proxy-правила, включаючи антивiрусний захист “на лету”. Цi правила вiдповiдають за фiльтрацiю трафiка, переданого пiд управлiнням заданих прикладних протоколiв; виконавчим агентом цих правил є proxy-агент, наприклад (User, Protocol, ProxyRule) або (Application, Protocol, ProxyRule);

правила автентифiкованого/авторизованого доступу, включаючи правила Single Sign-On. Управлiння доступом Single SignOn забезпечує даному користувачевi роботу на єдиному паролi або iншiй автентифiкованiй iнформацiї з багатьма iнформацiйними ресурсами; звiдси легко бачити, що символiчний запис правила мережного доступу легко поширюється на Single SignOn (User, Application, Authentication Scheme). Правила цiєї групи можуть комбiновано виконуватися агентами рiзного рiвня, вiд VPN-драйвера до proxy-агентiв; крiм того, агентами виконання таких правил можуть бути системи автентифiкацiї типу “запит-вiдгук” i продукти третiх розроблювачiв;

правила, вiдповiдальнi за сигналiзацiю й протоколювання по-

дiй. Полiтика протоколювання може оперативно й централiзовано управлятися агентом протоколювання; виконавцями правил є всi компоненти системи.

Розходження мiж правилами, що реалiзують ГПБ у мережi й ЛПБ конкретного пристрою, полягає в тiм, що в правилах групи ГПБ об’єкти й суб’єкти доступу можуть бути розподiленi довiльним образом у межах мережi, а правила групи ЛПБ, включаючи суб’єкти й об’єкти ЛПБ, призначенi й доступнi тiльки в межах

Приклади побудови захищених iнформацiйних технологiй

229

простору одного з мережних пристроїв.

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

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

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

вкеруючi модулi вiдповiдних засобiв захисту.

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

6.5.2.4. Реалiзацiя системи управлiння засобами безпеки

Структурно-продуктна лiнiя TrustWorks пiдроздiляється на агентiв безпеки (Trusted Agent), центр управлiння (Trusted GSM Server) i консоль управлiння (Trusted GSM Console). Загальна структурна схема реалiзацiї показана на рис. 6.31.

Призначення основних засобiв безпеки

Агент безпеки, установлений на персональному комп’ютерi клiєнта, орiєнтований на захист iндивiдуального користувача, що виступає, як правило, клiєнтом у додатках “клiєнт-сервер”.

230

Роздiл 6

Рис. 6.31. Загальна структурна схема системи управлiння засобами iнформацiйної безпеки

Агент безпеки, установлений на серверi додаткiв, орiєнтований на забезпечення захисту серверних компонентiв розподiлених додаткiв.

Агент безпеки, установлений на шлюзовому комп’ютерi, забезпечує розв’язку сегментiв мережi усерединi пiдприємства або мiж пiдприємствами (business-to-business), вирiшуючи завдання узгодження полiтик безпеки рiзних мереж.

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

Приклади побудови захищених iнформацiйних технологiй

231

подiленої схеми управлiння безпеки пiдприємства в системi GSM передбачається установка декiлькох (до 65535) серверiв GSM.

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

Локальний агент безпеки являє собою програму, що розташовується на кiнцевому пристрої (клiєнтi, серверi, шлюзi) та виконує наступнi функцiї захисту:

автентифiкацiю об’єктiв полiтики безпеки, включаючи iнтеграцiю рiзних сервiсiв автентифiкацiї;

визначення користувача в системi й подiй, пов’язаних з даним користувачем;

забезпечення централiзованого управлiння засобами безпеки й контролю доступу;

управлiння ресурсами в iнтересах додаткiв, пiдтримку управлiння доступом до ресурсiв прикладного рiвня;

захист й автентифiкацiю трафiка;

фiльтрацiю трафiка;

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

вскладi рiшення GSM):

поставка криптосервiсу (multiple concurrent pluggable modules);

управлiння параметрами Single Sign-On (як пiдзавдання автентифiкацiї користувачiв);

сервiс в iнтересах захищених додаткiв (криптосервiс, сервiс доступу до PKI, доступ до управлiння безпекою);

ущiльнення трафiка (IPcomp, pluggable module);

управлiння резервуванням мережних ресурсiв (Qo);

функцiї локального агента мережного антивiрусного захисту. Центральним елементом локального агента є процесор локаль-

ної полiтики безпеки (LSP processor), що iнтерпретує локальну полiтику безпеки й розподiляє викликiв мiж iншими компонентами.

232

Роздiл 6

Захист ресурсiв

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

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

автентифiкацiя користувача при доступi до середовища GSM або локальної операцiйної системи;

автентифiкацiя користувача при доступi в мережу (сегмент мережi);

взаємна мережна автентифiкацiя об’єктiв (додаток-додаток).

Для вибору способу iдентифiкацiї передбаченi наступнi варiанти, такi, що звичайно використовуються спiльно в будь-якiй конфiгурацiї: токен (смарт-карта), пароль, “зовнiшня” автентифiкацiя.

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

Контроль доступу на рiвнi прикладних об’єктiв. Для незахищених розподiлених додаткiв в GSM забезпечується сервiс розмежування прав доступу на рiвнi внутрiшнiх об’єктiв даного додатка. Контроль доступу на рiвнi об’єктiв прикладного рiвня забезпечується за рахунок застосування механiзму proxy. Proxy розробляється для кожного прикладного протоколу. Наперед встановленим є протокол HTTP.

Для побудови розподiленої схеми управлiння й зниження завантаження мережi в GSM використовується архiтектура розподiлених proxy-агентiв (proxy-модуль у складi локального агента), кожний з яких:

має абстрактний унiверсальний iнтерфейс, що забезпечує мо-

Приклади побудови захищених iнформацiйних технологiй

233

дульне пiдключення рiзних proxy-фiльтрiв;

має iнтерфейс до системи управлiння, але використає тимчасовий кеш для управлiння параметрами фiльтрацiї;

здiйснює фiльтрацiю, керовану узагальненими правилами типу:

автентифiкувати суб’єкт X у додатку-об’єктi Y;

дозволити доступ суб’єктовi X до об’єкта Y з параметрами Р; item заборонити доступ суб’єктовi X до об’єкта Z.

Семантика правил управлiння proxy-фiльтром й опису суб’є- ктiв й об’єктiв доступу залежать вiд конкретного прикладного протоколу, однак центр управлiння має можливiсть реєструвати proxy-фiльтри й забезпечувати управлiння ними в контекстi загальної глобальної полiтики безпеки.

Proxy-агент може бути встановлений на шлюзi безпеки, безпосередньо на серверi, що виконує контрольованi додатки, i на клiєнтському мiсцi системи.

Управлiння засобами захисту. Найважливiшим елементом реалiзацiї TrustWorks є централiзована, заснована на полiтицi (policy based) система управлiння засобами мережної й iнформацiйної безпеки масштабу пiдприємства. Ця система забезпечує наступнi якiснi споживчi характеристики:

високий рiвень захищеностi системи управлiння (шляхом видiлення захищеного периметра управлiння усерединi мережi пiдприємства);

розширюванiсть системи управлiння iнформацiйною безпекою;

високий рiвень надiйностi системи управлiння й ключових її компонентiв;

iнтеграцiю з корпоративними системами загального мережного й iнформацiйного управлiння;

просте, iнтуїтивно сприймане, ергономiчне й iнфраструктурне середовище опису, формування, монiторингу й дiагностики полiтики безпеки масштабу пiдприємства (enterprise level policy based management).

Управлiння здiйснюється спецiальним програмним забезпече-

нням адмiнiстратора консоллю управлiння. Кiлькiсть i функцiї кожного з екземплярiв установленої в системi ПЗ консолi управлiння задаються головним адмiнiстратором системи залежно вiд ор-

234

Роздiл 6

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

Функцiї управлiння GSM. Залежно вiд виду керованих об’- єктiв набiр керуючих функцiй в GSM можна умовно розбити на 3 категорiї:

управлiння iнформацiйним каталогом;

управлiння користувачами й правами доступу;

управлiння правилами ГПБ.

Функцiї управлiння iнформацiйним каталогом визначають iн-

формацiйну складову GSM:

формування роздiлiв каталогу;

опис послуг каталогу;

призначення й контроль мережних ресурсiв, необхiдних для виконання послуги;

реєстрацiя опису послуги;

контроль стану послуг або роздiлiв каталогу послуг; монiторинг виконання послуг;

пiдготовка й пересилання звiтiв (протоколiв) iз стану каталогу. Для управлiння правами доступу користувачiв системи до по-

слуг (iнформацiйним або мережним ресурсам) GSM виконує наступнi функцiї:

формування груп користувачiв по ролях й/або привiлеям доступу до послуг системи;

формування iєрархiчних агрегацiй користувачiв за адмiнiстративними, територiальними або iншими критерiями (домени й/або департаменти);

формування ролей доступу користувачiв до послуг (iнформацiйних або мережних ресурсiв);

призначення рiвнiв таємностi для послуг i користувачiв системи (пiдтримка мандатного механiзму розмежування прав);

призначення фiксованих прав доступу групам, ролям, агрегацiям користувачiв або окремих користувачiв системи до iнформацiйних або мережних ресурсiв системи;

пiдготовка й пересилання звiтiв (протоколiв) iз доступу користувачiв до послуг системи;

Приклади побудови захищених iнформацiйних технологiй

235

пiдготовка й пересилання звiтiв (протоколiв) iз роботи адмiнiстраторiв системи.

Правила ГПБ ставлять у вiдповiднiсть конкретнi властивостi

захисту (як для мережних з’єднань, так i для доступу користувачiв до iнформацiйних послуг) наперед встановленим рiвням безпеки системи. Контроль за дотриманням правил ГПБ виконує спецiальний модуль у складi сервера системи процесор полiтики безпеки (Security Policy Processor), що забезпечує наступнi функцiї системи:

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

призначення рiвнiв безпеки конкретним послугам або роздiлам каталогу послуг;

призначення рiвнiв безпеки користувачам або будь-яким агрегацiям користувачiв системи (групам, ролям, доменам, департаментам;

контроль за цiлiснiстю ГПБ (повнотою правил);

обчислення ЛПБ локальних пристроїв захисту агентiв безпеки i контроль за їх виконанням;

контроль за виконанням ГПБ за рiзними критерiями;

пiдготовка й пересилання звiтiв (протоколiв) про стан системи

й всiх спроб порушення ГПБ.

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

З метою забезпечення несуперечностi з iснуючими в користувача системами управлiння пiдприємства (Enterprise & Network Management System) i простоти управлiння в GSM реалiзується тiсна iнтеграцiя з найбiльш популярними платформами управлiння (СА Unicenter TNG або HP OV), вибiр визначається менеджером продуктiв.

236

Роздiл 6

6.5.3 Аудит i монiторинг безпеки

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

6.5.3.1. Аудит безпеки iнформацiйної системи

Поняття аудиту безпеки

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

На сьогоднi актуальнiсть аудита безпеки IС рiзко зросла, це пов’язане зi збiльшенням залежностi органiзацiй вiд iнформацiї й IС. Зросла уразливiсть IС за рахунок пiдвищення складностi елементiв IС, появи нових технологiй передачi й зберiгання даних, збiльшення обсягу програмного забезпечення. Розширився спектр погроз для IС через активне використання пiдприємствами вiдкритих глобальних мереж для передачi повiдомлень i транзакцiй. Крiм того, по даним деяких захiдних аналiтичних агентств, до 95% спроб несанкцiонованого доступу до конфiденцiйної iнформацiї IС вiдбувається з iнiцiативи колишнiх спiвробiтникiв органiзацiї [4].

Аудит безпеки IС дає можливiсть керiвникам i спiвробiтникам органiзацiй одержати вiдповiдi на наведенi нижче питання, а також намiтити шляхи рiшення виявлених проблем:

як оптимально використати iснуючу IС при розвитку бiзнесу;

Приклади побудови захищених iнформацiйних технологiй

237

як вирiшуються питання безпеки й контролю доступу;

як установити єдину систему управлiння й монiторингу IС;

коли i як необхiдно провести модернiзацiю обладнання й ПО;

як мiнiмiзувати ризики при розмiщеннi конфiденцiйної iнфор-

мацiї в IС органiзацiї?

На цi й iншi подiбнi питання не можна миттєво дати однозначну вiдповiдь. Достовiрну й обґрунтовану iнформацiю можна одержати, тiльки розглядаючи всi взаємозв’язки мiж проблемами, з огляду на нюанси й недолiки. Проведення аудита дозволяє оцiнити поточну безпеку IС, оцiнити ризики, прогнозувати й управляти їхнiм впливом на бiзнес-процеси органiзацiї, коректно й обґрунтовано пiдiйти до питання забезпечення безпеки iнформацiйних ресурсiв органiзацiї.

Цiлями проведення аудита безпеки IС є:

оцiнка поточного рiвня захищеностi IС;

локалiзацiя вузьких мiсць у системi захисту IС;

аналiз ризикiв, пов’язаних з можливiстю здiйснення загроз безпецi вiдносно ресурсiв IС;

вироблення рекомендацiй iз впровадження нових i пiдвищенню ефективностi iснуючих механiзмiв безпеки IС;

оцiнка вiдповiдностi IС iснуючим стандартам у галузi iнформацiйної безпеки.

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

Асоцiацiя ISACA i стандарт COBIT

До теперiшнього часу пiдхiд до проведення аудита IС став стандартизованим. Великi й середнi аудиторськi компанiї утворили асоцiацiї союзи професiоналiв в областi аудита IС, якi займаються створенням i супроводом стандартiв аудиторської дiяльностi в сферi IТ. Ще в 1969 роцi була заснована асоцiацiя аудита й управлiння iнформацiйними системами ISACA (The Information Systems Audit and Control Association & Foundation). На сьогоднi асоцiацiя поєднує близько 20 тисяч членiв з бiльш нiж 100 країн, у

238

Роздiл 6

тому числi й України. Ця асоцiацiя координує дiяльнiсть понад 12 тисяч аудиторiв iнформацiйних систем CICA (Certified Information System Auditor).

Основна задекларована цiль асоцiацiї ISACA це дослiдження, розробка, публiкацiя й просування стандартизованого набору документiв з управлiння iнформацiйною технологiєю для щоденного використання адмiнiстраторами й аудиторами iнформацiйних систем. У допомогу професiйним аудиторам, адмiнiстраторам i зацiкавленим користувачам асоцiацiєю ISACA i притягнутими фахiвцями iз провiдних свiтових консалтингових компанiй був розроблений вiдкритий стандарт COBIT (Control Objectives for Information and Related Technology).

Асоцiацiя ISACA розвиває свою концепцiю управлiння iнформацiйними технологiями вiдповiдно до вимог IБ. На основi цiєї концепцiї описуються елементи iнформацiйної технологiї, даються рекомендацiї з органiзацiї управлiння, забезпеченню режиму IБ. Документ називається COBIT (Control Objectives for Information and Related Technology) i складається iз чотирьох частин:

1.Executive Summary короткий опис концепцiї.

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

3.Control Objectives специфiкацiї керуючих процесiв i можливi iнструменти впливу.

4.Audit Guidelines рекомендацiї з виконання аудита. Частина Control Objectives є в деякому змiстi аналогом британ-

ського стандарту BS7799. Приблизно з тим же ступенем подробицi даються практичнi рекомендацiї з управлiння IБ.

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

СOBIT ураховує особливостi iнформацiйних систем будь-якого масштабу й складностi. Стандарт зв’язує iнформацiйнi технологiї й дiї аудиторiв, поєднує й погоджує багато iнших стандартiв у єдиний ресурс, що дозволяє компетентно управляти цiлями й завданнями, розв’язуваними IС. Основне правило, покладене в основу COBIT, наступне: ресурси IС повиннi управлятися набором гар-

Приклади побудови захищених iнформацiйних технологiй

239

монiйно згрупованих процесiв для забезпечення органiзацiї необхiдною й надiйною iнформацiєю. Структура стандарту COBIT показана на (рис. 6.32).

Рис. 6.32. Структура стандарту COBIT

У стандартi COBIT ураховуються наступнi види ресурсiв:

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

додатки прикладне програмне забезпечення, що використовується в роботi органiзацiї;

технологiї операцiйнi системи, бази даних, системи управлi-

240

Роздiл 6

ння й т.д.;

устаткування всi апаратнi засоби IС органiзацiї з урахуванням їх обслуговування;

данi (у самому широкому розумiннi) зовнiшнi й внутрiшнi, структурованi й неструктурованi, графiчнi, звуковi, мультимедiа й т.д.

Всi цi ресурси оцiнюються COBIT на кожному з етапiв побудови або аудита IС за наступними критерiями:

ефективнiсть критерiй, що визначає доречнiсть i вiдповiднiсть iнформацiї завданням бiзнесу;

технiчний рiвень критерiй вiдповiдностi стандартам й iнструкцiям; безпека захист iнформацiї;

цiлiснiсть точнiсть i закiнченiсть iнформацiї;

придатнiсть доступнiсть iнформацiї необхiдним бiзнеспроцесам сьогоднi й у майбутньому, а також захист необхiдних i супутнiх ресурсiв;

погодженiсть виконання законiв, iнструкцiй i домовленостей, що впливають на бiзнес-процес, тобто зовнiшнi вимоги до бiзнесу;

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

Застосування стандарту COBIT можливо як для проведення

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

Надалi при розглядi аудита IС передбачається, що на будьякому етапi можливе вирiшення зворотного завдання проектування IС.

Розробники цього стандарту намагалися, щоб, незважаючи на малий розмiр, стандарт був прагматичним i вiдповiдав потребам бiзнесу, при цьому зберiгаючи незалежнiсть вiд конкретних виробникiв, технологiй i платформ. На базовiй схемi COBIT вiдбита послiдовнiсть, склад i взаємозв’язок базових груп. Бiзнес-процеси

Приклади побудови захищених iнформацiйних технологiй

241

(у верхнiй частинi схеми) висувають свої вимоги до ресурсiв IС, якi аналiзуються з використанням критерiїв оцiнки COBIT на всiх етапах побудови й проведення аудита.

Чотири базовi групи (домени) мiстять у собi 34 пiдгрупи, якi, у свою чергу, складаються з 302 об’єктiв контролю. Об’єкти контролю надають аудиторовi достовiрну й актуальну iнформацiю про поточний стан IС.

Стандарт COBIT характеризується наступними вiдмiнними рисами:

бiльша зона охоплення (всi завдання вiд стратегiчного планування й основних документiв до аналiзу роботи окремих елементiв IС);

перехресний аудит (зони перевiрки критично важливих елементiв перекриваються);

адаптовано нарощуваний стандарт.

Достоїнствами стандарту СОВIT є такi його якостi, як доста-

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

Практика проведення аудита безпеки iнформацiйних систем

Роботи з аудита безпеки IС мiстять у собi ряд послiдовних етапiв, якi в цiлому вiдповiдають етапам проведення комплексного IТ аудита автоматизованої системи:

iнiцiювання процедури аудита; збiр iнформацiї аудита; аналiз даних аудита; вироблення рекомендацiй;

пiдготовка аудиторського звiту.

Послiдовнiсть виконання етапiв аудита безпеки IС, показана на рис. 6.33[4]. Розглянемо цi етапи докладнiше.

Iнiцiювання процедури аудита. Аудит проводиться з iнiцiативи керiвництва компанiї, яке у даному питаннi є основною зацiкавленою стороною. Пiдтримка керiвництва компанiї є необхiдною умовою для проведення аудита. Аудит являє собою ком-

242

Роздiл 6

Рис. 6.33. Послiдовнiсть етапiв проведення аудита IС

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

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

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

Одержання iнформацiї про органiзацiю, функцiонування й по-

Приклади побудови захищених iнформацiйних технологiй

243

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

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

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

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

244

Роздiл 6

забезпечити для даної IС. Необхiдна також методика, що дозволяє оцiнити цю вiдповiднiсть. Через свою простоту й надiйнiсть описаний пiдхiд найпоширенiший на практицi. Вiн дозволяє при мiнiмальних витратах ресурсiв робити обґрунтованi висновки про стан IС.

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

Вироблення рекомендацiй. Результати проведеного аналiзу є базою для вироблення рекомендацiй. Рекомендацiї, що видаються аудитором, визначаються особливостями обстежуваної IС, станом справ з iнформацiйною безпекою й ступенем деталiзацiї, що використовується при проведеннi аудита. Рекомендацiї аудитора повиннi бути конкретними й застосовними до даного IС, економiчно обґрунтованими, аргументованими (пiдкрiпленими результатами аналiзу) i ранжируваними за ступенем важливостi. У той же час не слiд очiкувати вiд аудитора, що в результатi проведення аудита буде виданий технiчний проект пiдсистеми iнформацiйної безпеки або детальних рекомендацiй iз впровадження конкретних програмно-технiчних засобiв захисту iнформацiї. Такi рекомендацiї вимагають бiльше глибокого пророблення конкретних питань органiзацiї захисту. Регулярне проведення аудита гарантує стабiльнiсть функцiонування IС, тому одним з результатiв професiйного аудита є формування плану-графiка проведення наступних перевiрок.

Пiдготовка звiтних документiв. Аудиторський звiт є основним результатом проведення аудита. Його якiсть характеризує якiсть роботи аудитора. Залежно вiд характеру й цiлей проведеного аудита структура звiтiв може iстотно розрiзнятися. Однак певнi роздiли повиннi обов’язково бути присутнiм в аудиторському звiтi.

Звiт повинен мiстити опис цiлей проведення аудита, характеристику обстежуваної IС, обсяги проведення аудита й перелiк вико-

Приклади побудови захищених iнформацiйних технологiй

245

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

Результати проведення аудита. Результати аудита IС органiзацiї можна роздiлити на три основнi групи:

органiзацiйнi планування, управлiння, документообiг IС;

технiчнi збої, несправностi, оптимiзацiя роботи елементiв IС, безперервне обслуговування, створення iнфраструктури й т.д.;

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

.

Проведений аудит дозволяє обґрунтовано розробити наступнi документи:

полiтику безпеки IС органiзацiї;

методологiю роботи й доведення IС органiзацiї;

довгостроковий план розвитку IС;

план вiдновлення IС у надзвичайнiй ситуацiї.

6.5.3.2. Монiторинг безпеки системи

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

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

список уразливостей мережного обладнання, програмного забезпечення постiйно росте, i простежити за тим, щоб всi знову виникаючi загрози були лiквiдованi, в адмiнiстратора не вистачає нi сил, нi засобiв;

246

Роздiл 6

при наявностi в зловмисника можливостi проведення багатьох атак iмовiрнiсть того, що вiн зрештою виявить уразливiсть i проведе успiшну атаку, багаторазово зростає;

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

Принципи роботи перерахованих вище традицiйних засобiв захисту такi, що останнi здатнi лише блокувати атаку, але не запобiгти або виявити її наслiдки.

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

Пiдхiд, на якому засноване рiшення даної проблеми, одержав назву технологiї активного аудита або технологiї активного (адаптивного) управлiння безпекою [15,46] (див. главу 10). Технологiя активного управлiння безпекою мiстить у собi наступнi компоненти:

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

засоби виявлення й аналiзу атак;

засоби адаптацiї й управлiння настроюваннями засобiв захисту

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

Приклади побудови захищених iнформацiйних технологiй

247

роботи називають також сканерами безпеки.

Iснує багато детальних описiв слабостей настроювань засобiв захисту, а також уразливостей iнформацiйних об’єктiв. Iз таких описiв виконується сканування об’єктiв на предмет наявностi в них цих уразливостей. Залежно вiд того, наскiльки повно описанi уразливостi i як ретельно проводиться аналiз, робота сканера безпеки є бiльш-менш ефективною. У результатi аналiзу сканер формує звiт, що направляється адмiнiстраторовi безпеки й мiстить опис виявлених уразливостей i правила їхнього усунення. Якщо сканер мiстить засоби управлiння настроюваннями засобiв безпеки, то вiн може виконати їхню переконфiгурацiю самостiйно.

До основних типiв уразливостей вiдносяться:

неправильна конфiгурацiя мiжмережних екранiв i маршрутизаторiв;

“дiри” в операцiйних системах, базах даних, додатках;

уразливостi до рiзного роду мережним атакам;

вiдсутнiсть необхiдних вiдновлень i патчiв;

наявнiсть незахищених мережних з’єднань i точок доступу в

глобальну мережу.

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

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

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

248

Роздiл 6

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

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

Управлiння засобами безпеки є реагуванням системи управлiння безпекою на змiннi умови й може бути рiзним за формою, наприклад:

пасивним, тобто реалiзовувати лише повiдомлення системи мережного управлiння за протоколом SNMP або адмiнiстратора по електроннiй поштi або пейджеру;

активним, тобто самостiйно автоматично завершувати сесiю з атакуючим вузлом або користувачем, реконфiгурувати настроювання мiж мережного екрана або таких мережних пристроїв,

як маршрутизатори.

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

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

Приклади побудови захищених iнформацiйних технологiй

249

iншої спрямованостi, що вiдслiдковують специфiчнi аспекти поведiнки IС (рис. 6.34).

Рис. 6.34. Iнтеграцiя сервiсiв безпеки й системи управлiння

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

Один з вiдомих фахiвцiв в галузi iнформацiйної безпеки Маркус Ранум (Markus Ranum) вважає, що дiї з виявлення помилок, вторгнень або вiдмов є аспектами єдиної проблеми управлiння мережами [15]. Зокрема, продукт для активного аудита NFR (Network Flight Recorder) М. Ранум розглядає як компонент системи мережного управлiння.

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

стема SAFEsuite Decisions, розроблена компанiєю Internet Security Systems i призначена для збору й аналiзу iнформацiї, отриманої вiд рiзних засобiв захисту iнформацiї, а також для аналiзу порушень безпеки, виявлення на їхнiй основi тенденцiй i прогнозування можливих у майбутньому атак.

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

систему аналiзу захищеностi на рiвнi мережi Internet Scanner;

систему аналiзу захищеностi на рiвнi операцiйної системи System Scanner;

систему виявлення атак на рiвнi мережi й хоста RealSecure;

мiжмережний екран Check Point FireWall-1;

мiжмережний екран Gauntlet Firewall й iн.

6.5.4Огляд сучасних систем управлiння мережною безпекою

Завдання управлiння великими iнформацiйними системами стали актуальними в епоху масового поширення клiєнт-серверних технологiй i децентралiзованих обчислень. Приймаючи цей виклик часу, постачальники почали розробляти продукти, що дозволяють вирiшувати завдання управлiння розподiленими iнформацiйними системами. Лiдерами на ринку засобiв управлiння безпекою розподiлених iнформацiйних систем є такi компанiї, як IBM Tivoli, Cisco Systems, Check Point й iн. Нижче розглядаються конкретнi реалiзацiї засобiв управлiння безпекою вiд компанiй IBM Tivoli й Cisco Systems. Продукти й рiшення компанiї Check Point описуються в роздiлi 13.3.2.

6.5.4.1. Продукти компанiї IBM Tivoli

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

Приклади побудови захищених iнформацiйних технологiй

251

дiйсно безпечне середовище функцiонування IС пiдприємства. На рис. 6.35 представлена iнформацiя про продукти компанiї IBM Ti-

Рис. 6.35. Продукти IBM Tivoli для забезпечення безпеки

voli для забезпечення безпеки IС [81].

При формуваннi стратегiї безпеки пiдприємства компанiя IBM Tivoli видiляє як прiоритетнi завдання:

вироблення полiтики доступу до ресурсiв або даних i реалiзацiю її на всiх рiвнях корпоративної iнфраструктури;

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

Для вирiшення цих проблем забезпечення безпеки в компанiї IBM Tivoli передбачено декiлька функцiй:

Управлiння iдентифiкацiєю (Identity Management) включає управлiння процесами автентифiкацiї й авторизацiї користувачiв по вiдношенню до iнформацiйних ресурсах пiдприємства.

252

Роздiл 6

Управлiння доступом (Access Management) дозволяє створювати глобальнi каталоги прав доступу до даних.

Усунення або мiнiмiзацiя погроз (Threat Management) спрямованi на комплексний захист периметра мережi й заснованi на використаннi кореляцiйного аналiзу. Функцiя дає можливiсть визначати справжнє вторгнення ззовнi й зсередини й автоматично запускати превентивнi процедури.

Забезпечення конфiденцiйностi (Privacy Management) передбачає управлiння полiтиками доступу до конфiденцiйної iнформацiї на основi ефективного рольового механiзму для систем електронного бiзнесу.

Для реалiзацiї перерахованих функцiй компанiя IBM Tivoli пропонує наступнi продукти:

IBM Tivoli Secure Way User Administration;

IBM Tivoli Identity Manager;

IBM Tivoli Access Manager for e.business;

IBM Tivoli Access Manager for Operating Systems;

IBM Tivoli Access Manager for Business Integration;

IBM Tivoli Privacy Manager for e.business;

IBM Tivoli Public Key Infrastructure;

IBM Tivoli Risk Manager;

IBM Tivoli Intrusion Manager й iн. [81].

Надання користувачам всiх необхiдних прав доступу разом iз

забезпеченням конфiденцiйностi корпоративної iнформацiї є самим складним завданням менеджера iнформацiйної системи пiдприємства.

Продукт IBM Tivoli SecureWay User Administration є одним з основних засобiв Tivoli для забезпечення безпеки. Вiн забезпечує безпечний спосiб управлiння атрибутами й службами користувачiв у гетерогенних розподiлених мережах i дозволяє автоматизувати вiдповiднi дiї з управлiння. У цьому продуктi реалiзовано декiлька принципово нових особливостей органiзацiї управлiння безпекою:

управлiння на основi певної полiтики;

управлiння за пiдпискою;

безпечне надання прав доступу;

незалежний вiд платформи iнтерфейс. Вiдзначимо основнi достоїнства цього продукту:

Приклади побудови захищених iнформацiйних технологiй

253

простий у застосуваннi й дозволяє заощаджувати час за рахунок централiзованого управлiння гетерогенною системою;

має властивiсть масштабованостi;

забезпечує безпечне управлiння на основi стратегiй, що дає мо-

жливiсть визначати й застосовувати єдиний пiдхiд до управлiння.

Продукт IBM Tivoli Identity Manager являє собою автоматизоване, захищене i засноване на полiтиках рiшення з управлiння користувачами. Цей продукт входить до складу програмного пакета Tivoli Enterprise, що поєднує програмнi продукти для управлiння корпоративними клiєнт-серверними середовищами. Tivoli Identity Manager надає:

iнтуїтивно зрозумiлий Web-iнтерфейс адмiнiстрування;

складну модель адмiнiстрування на основi ролей, що дозволяє делегувати адмiнiстративнi повноваження;

Web-iнтерфейси самообслуговування й запитiв/вiдповiдей;

убудований механiзм документообiгу для автоматичного вiдправлення користувальницьких запитiв на затвердження, а затверджених запитiв на виконання;

убудований механiзм автоматизацiї виконання адмiнiстративних запитiв;

набiр iнструментiв для управлiння додатками. Використовуючи iнтерфейс самообслуговування й делегування

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

Tivoli Identity Manager забезпечує пiдтримку продукту IBM Tivoli Risk Manager, призначеного для оцiнки ризику й управлiння подiями.

Програмний продукт IBM Tivoli Risk Manager дозволяє централiзовано управляти й реагувати на рiзнi загрози для захисту системи й спроби вторгнення, спрямованi на iнформацiйнi ресурси

254

Роздiл 6

пiдприємства.

Цей продукт має наступнi можливостi:

дозволяє вiдслiдковувати, переглядати й управляти подiями захисту за допомогою простої консолi;

дозволяє iнтегрувати засоби управлiння iз системами зовнiшнього захисту;

допомагає роздiлити подiї захисту на категорiї для того, щоб швидко iдентифiкувати й обробляти найнебезпечнiшi подiї;

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

мiстить заздалегiдь певнi набори дiй для вiдбиття атак типу “вiдмова в обслуговуваннi”, для знешкодження вiрусiв i припи-

нення несанкцiонованого доступу.

До складу програмного забезпечення Tivoli Risk Manager входять:

система виявлення вторгнень Tivoli Network Intrusion Detection System, що розпiзнає бiльше 200 рiзних типiв атак i займає досить мало мiсця на диску;

система виявлення вторгнень Tivoli Web Intrusion Detection System (Tivoli Web-IDS), що дозволяє вiдслiдковувати факти несанкцiонованого проникнення в систему й рiзнi види атак на

Web-сервери.

Програмне забезпечення Tivoli Risk Manager мiстить наступнi функцiї, що дозволяють централiзовано управляти ризиками:

централiзована обробка повiдомлень про вторгнення;

централiзоване архiвування повiдомлень захисту в реляцiйнiй базi даних;

масштабована iнфраструктура управлiння подiями, що дозволяє управляти подiями на тисячах рiзних пристроїв;

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

пiдтримка прийняття рiшень, до складу якої входять пiдготовленi звiти для управлiння брандмауерами, визначення втор-

Приклади побудови захищених iнформацiйних технологiй

255

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

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

6.5.4.2. Модуль управлiння в архiтектурi безпеки SAFF компанiї Cisco

З погляду компанiї Cisco, першим кроком у реалiзацiї будь-якої стратегiї управлiння й звiтностi є управлiння мережними системами по видiленiй лiнiї 00У (Out-of-Band). Цей термiн означає, що для управлiння використається мережа, по якiй не передається виробничий трафiк [84].

По можливостi пристрої повиннi мати прямий локальний доступ до такої мережi. Якщо такої можливостi немає (з географiчних або системних причин), пiдключення пристроїв повинне вiдбуватися через виробничу мережу по приватному зашифрованому тунелi. Цей тунель повинен бути настроєний на зв’язок тiльки через певнi порти, призначенi для управлiння й звiтностi. Крiм того, тунель повинен блокуватися так, щоб вiдкривати або закривати його могли тiльки певнi хости. Хоча видiлена мережа й дозволяє передавати данi в контрольованому захищеному середовищi, де її неможливо спотворити, все-таки використання додаткових засобiв захисту (протоколiв SSL або SSH) дозволяє пiдвищити рiвень захищеностi.

Завдання пiдсистем управлiння доступом, аудита й монiторингу, а також пiдсистеми управлiння й пiдтримки затвердження рiшення при побудовi системи безпеки корпоративних мереж за ар-

256

Роздiл 6

хiтектурою SAFE реалiзуються в одному модулi модулi управлiння (рис. 6.36).

Рис. 6.36. Модуль управлiння: функцiї запобiгання атак

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

Як видно з наведеної схеми, модуль управлiння SAFE має два мережних сегменти, якi роздiленi маршрутизатором IOS, що виконує роль мiжмережного екрана й пристрою термiнування вiртуальної приватної мережi. Сегмент, що перебуває iз зовнiшньої сторони мiжмережного екрана, з’єднується з усiма пристроями, якi мають потребу в управлiннi. Сегмент, що перебуває iз внутрiшньої сторони, включає хости управлiння й маршрутизатори IOS, якi виступають як термiнальнi сервери. Обидвi пiдмережi управ-

Приклади побудови захищених iнформацiйних технологiй

257

лiння працюють в адресному просторi, що повнiстю вiддiлений вiд виробничої мережi.

Компоненти мережi, надаванi компанiєю Cisco Systems, мають наступнi умовнi позначки:

система розпiзнавання атак на мережному рiвнi;

маршрутизатор;

маршрутизатор з функцiями мiжмережного екрана;

мiжмережний екран;

комутатор другого рiвня;

комутатор третього рiвня;

концентратор VPN;

сервер доступу.

Основнi компоненти

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

Cisco Works VPN/Security Management Solution (VMS);

сервер безпечного доступу Cisco Secure Access Control Server;

маршрутизатор Cisco IOS з функцiями мiжмережного екрана;

сервер одноразових паролiв RSA Securel;

система виявлення атак Cisco Secure Intrusion Detection System;

комутатори канального рiвня Catalyst 3500.

Cisco Works VPN/VMS мiстить рiзнi Web-засоби для настрою-

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

Cisco Works VMS складається з наступних основних частин:

Менеджер ресурсiв RME (Resource Manager Essentials) це потужний набiр Web-орiєнтованих додаткiв, що пропонує рiзнi варiанти управлiння маршрутизаторами, комутаторами й

258

Роздiл 6

серверами доступу Cisco. Iнтерфейс RME надає легкий доступ до критично важливої iнформацiї про стан мережi, зменшуючи при цьому час на виконання яких-небудь завдань адмiнiстрування. У менеджерi ресурсiв RMЕ передбачена можливiсть об’єднання, якщо буде потреба, з iншими засобами управлiння Cisco;

сервер автооновлень (Auto Update Server Software) пiдтримує гнучку модель настроювань, що надалi може бути використана для початкових настроювань, вiдновлень настроювань, вiдновлень операцiйних систем, а також перiодичної перевiрки настроювань. Це зручний засiб розсилання вiдновлень для вилучених мiжмережних екранiв PIX, а також для тих вiдддалених МЕ, якi розподiленi динамiчно в адресному просторi (DHCPадресацiя);

Центр управлiння системами виявлення вторгнень (Management Center for IDS Sensors) це засiб настроювань мережних систем виявлення вторгнень IDS (Intrusion Detection System) i IDS комутаторiв. Дане ПЗ дозволяє управляти рiзними IDS одночасно, створюючи групи IDS й у такий спосiб скорочуючи час адмiнiстрування. Центр управлiння IDS також надає можливiсть створювати шаблони нових атак для зiставлення, тому адмiнiстратори можуть бiльш точно визначати атаки;

Центр управлiння мiжмережними екранами PIX (Management Center for PIX Firewall) дозволяє нарощувати функцiї централiзованого управлiння мiжмережними екранами аж до 1000 одиниць. Центр управлiння для МЕ PIX забезпечує повне управлiння правилами доступу, трансляцiєю мережних адрес, системами виявлення вторгнень, установленими на МЕ, а також засобами побудови VPN, що входять у функцiональний склад МЕ. У випадку управлiння захистом наскрiзного з’єднання центр управлiння може виступати як єдина консоль разом з iншими центрами управлiння;

Центр управлiння VPN-з’єднань (Management Center for VPN routers) пропонує управлiння захистом розширюваної системи з настроювання й розгортання VPN-з’єднань. Це потужни, гнучкий i iнтуїтивно зрозумiлий засiб з настроювання й розгортання як повномасштабних, так й VPN-з’єднань “вiд-сайту-до-

Приклади побудови захищених iнформацiйних технологiй

259

сайту”. Однiєї з особливостей даного додатка є гнучкий i зручний розподiл рольових прав й обов’язкiв мiж адмiнiстраторами й простими користувачами усерединi великих корпоративних мереж;

Менеджер полiтики безпеки (Policy Manager) розширювана й потужна система управлiння полiтикою безпеки для МЕ й VPN-шлюзiв компанiї Cisco. За допомогою даного продукту можна визначати, поширювати, здiйснювати, а також проводити звiтнiсть будь-якої полiтики безпеки з одного центра. Даний продукт допомагає спростити завдання управлiння складних елементiв забезпечення безпеки мереж, таких як захист периметра, контроль доступу, NAT, а також VPN-шлюзiв.

Контроль доступу

Функцiї контролю доступу компанiя Cisco реалiзувала в одному продуктi серверi захищеного контролю доступу ACS (Cisco Secure Access Control Server), що визначає, хто має доступ у мережу i якi дiї вiн може виконувати в данiй мережi. Це високоефективна, розширювана й централiзована структура контролю доступу користувачiв, що пропонує єдине й органiзоване управлiння всiма процесами автентифiкацiї, авторизацiї й облiку користувачiв за допомогою Web-орiєнтованого графiчного iнтерфейсу й поширює команди управлiння сотням i тисячам шлюзам доступу корпоративної мережi. Управлiння й адмiнiстрування доступом користувачiв до IOS-маршрутизаторiв, вiртуальним приватним мережам, а також до МЕ виконується за допомогою протоколу контролю доступу IEEE 802.1х. Крiм того, можливе посилення структури ACS шляхом уведення контролю доступу самих адмiнiстраторiв i контролю настроювань всiх пристроїв, що працюють по протоколi TACACS+.

Аудит i монiторинг

Як уже було сказано вище, завдання управлiння, аудита й контролю (у рамках архiтектури SAFE) реалiзуються одним програм-

260

Роздiл 6

ним продуктом CiscoWorks VMS. Розглянемо складовi VMS, на якi покладають завдання монiторингу й аудита.

Монiтор VPN (VPN Monitor) це Web-орiєнтований засiб управлiння, що дозволяє збирати, зберiгати й переглядати iнформацiю про VPN-з’єднання, що працюють по протоколi IPSec, а також про VPN-термiнування вiддаленого доступу i мiж сайтами, що працює по протоколах РРТР, L2TP, IPSec. Монiтор VPN пiдтримує VPN-концентратори Cisco серiї 3000 i маршрутизатори Cisco з можливiстю побудови VPN-обладнання може управлятися за допомогою графiчного iнтерфейсу Web-оглядача, що дозволяє здiйснити швидкий перегляд поточного стану VPN-обладнання.

Центр монiторингу безпеки (Monitoring Center for Security). Багатьом органiзацiям доводиться обробляти вручну численнi потоки звiтної iнформацiї про стан рiзних мережних вузлiв i з’єднань. Центр монiторингу безпеки вирiшує це питання, пропонуючи єдиний засiб збору, перегляду, обробки й зберiгання iнформацiї, що надходять вiд рiзних центрiв управлiння й монiторингу, що входять в CiscoWorks VMS. Центр монiторингу безпеки також має потужний i наочний механiзм оповiщення критичних подiй.

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

Виявлення атак

Система виявлення атак Cisco Secure Intrusion Detection System заснована на запатентованiй технологiї Entercept i поєднує такi останнi розробки в областi розпiзнавання атак, як виявлення Internet-черв’якiв, атак типу "вiдмова в обслуговуваннi а також атак, що виконуютьcя при електроннiй комерцiї. Разом з МЕ й

Приклади побудови захищених iнформацiйних технологiй

261

VPN-пристроями Cisco Secure IDS це життєво важлива частина всiєї iнфраструктури захисту периметра корпоративних мереж. Компанiя Cisco пропонує п’ять рiзновидiв IDS:

мережнi IDS (Network IDS) порiвнюють трафiк з вiдомим зразком атаки або шукають евристичнi зразки атак (наприклад, типу “вiдмова в обслуговуваннi”), а також перевiряють дiйснiсть пакетiв, протоколiв i додаткiв. У випадку виявлення атаки IDS виконує дiї, передбаченi на даний випадок (наприклад, скидання ТСР-сесiї);

сервернi IDS (Host IDS) розташовуються на кожному захищати серверi. На вiдмiну вiд мережного IDS, сервернi IDS сильно залежать вiд операцiйних систем, установлених на серверах, що пiдлягають захисту;

IDS комутаторiв (Switch IDS) модуль IDS вбудовується в комутатор, виконує основнi функцiї попередження атак;

IDS маршрутизаторiв (Router IDS) модуль IDS вбудовується в маршрутизатори, виконує основнi функцiї попередження атак;

IDS МЕ (Firewall IDS) модуль IDS вбудовується в МЕ, виконує основнi функцiї попередження атак.

Комутатори канального рiвня Catalyst 3500

У рамках корпоративної iнформацiйної безпеки данi комутатори мають такi особливостi, як:

повна пiдтримка технологiї VLAN;

пiдтримка протоколу управлiння доступом TACACS+;

можливiсть вбудовування модулiв IDS, VPN i модуля мiж мережного екранування.

6.5.4.3. Система централiзованого управлiння безпекою компанiї ЭЛВИС+

Принцип централiзованого управлiння безпекою корпоративної мережi, розроблений компанiєю TrustWorks Systems (див. роздiл 12.2) i реалiзований у продуктах ЗАСТАВА 3.3 компанiї ЭЛВИС+, ґрунтується на наступних концептуальних положеннях:

262

Роздiл 6

управлiння безпекою корпоративної мережi повинне здiйснюватися на рiвнi ГПБ наборi правил безпеки для як завгодно складної безлiчi взаємодiй мiж рiзноманiтними об’єктами корпоративної мережi, а також мiж об’єктами корпоративної мережi й зовнiшнiх об’єктiв;

ГПБ повинна максимальним чином вiдповiдати бiзнеспроцесам компанiї; для цього необхiдний спосiб опису властивостей безпеки об’єктiв i необхiдних для їхньої реалiзацiї сервiсiв безпеки, заснований на їхнiх бiзнес-ролях у структурi компанiї;

формування ЛПБ для окремих засобiв захисту i їхня трансляцiя повиннi здiйснюватися автоматично на основi аналiзу правил ГПБ i топологiї захищає сети, що, з обов’язковою автоматичною перевiркою їхньої коректностi, цiлiсностi й несуперечностi ГПБ (рис. 6.37).

Глобальна полiтика безпеки корпоративної мережi являє собою деяку скiнченну множину правил безпеки (рис. 6.38), якi описують параметри взаємодiї об’єктiв корпоративної мережi в контекстi iнформацiйної безпеки:

необхiдний для з’єднання сервiс безпеки: правила обробки, захисту й фiльтрацiї трафiка;

напрямок надання сервiсу безпеки;

правила автентифiкацiї об’єктiв;

правила обмiну ключами;

правила запису результатiв подiй безпеки в системний журнал; правила сигналiзацiї про тривожнi подiї й iн.

При цьому об’єктами ГПБ можуть бути як окремi робочi стан-

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

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

Приклади побудови захищених iнформацiйних технологiй

263

Рис. 6.37. Структура централiзованого управлiння безпекою мережi

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

Рiшення на базi VPN ЗАСТАВА 3.3 реалiзує ефективний пiдхiд до проблеми забезпечення безпеки корпоративної мережi: пiсля формування ГПБ адмiнiстратором центр управлiння TGSM на основi її iнтерпретацiї автоматично обчислює й, якщо це необхiдно, коректує окремi ЛПБ для кожного засобу захисту й автоматично завантажує необхiднi настроювання в керуючi модулi вiдповiдних

264

Роздiл 6

Рис. 6.38. Структура правила глобальної полiтики безпеки

засобiв захисту:

в автоматичному режимi по протоколi РМР (Policy Management Protocol), що є стандартним розширенням протоколу IKE у виглядi повiдомлення у форматi PKCS#7;

у ручному режимi шляхом видачi ЛПБ на PKCS# 11-сумiсний iдентифiкатор користувача (смарт-карту, USB-токен, програмний емулятор токена на дискетi або жорсткому диску) у форматi PKCS#7.

Таким чином, принцип централiзованого управлiння безпекою корпоративної мережi на базi полiтик ГПБ i ЛПБ дозволяє формувати цiлiсну й несуперечливу полiтику безпеки компанiї, незалежну вiд форматiв i змiсту настроювань окремих засобiв захисту, що реалiзують дану полiтику. Для цього використовується патентована технологiя TrustWorks, що дозволяє iнтерпретувати правила безпеки ГПБ i ставити їх у вiдповiднiсть iз топологiєю захищає сети, що, автоматично обчислювати й надавати локальнi полiтики безпеки всiм вузлам, де реалiзується задана полiтика безпеки корпоративної мережi.

Приклади побудови захищених iнформацiйних технологiй

265

6.6Технологiї захисту iнформацiйних сховищ

6.7Використання технологiй вiртуалiзацiї для вирiшення завдань захисту iнформацiї

Вiдповiдно до ДСТУ 2296-94 [?] вiртуальний умовний, фiзично вiдсутнiй але за допомогою спецiальних методiв наданий у розпорядження.

1.Iзоляцiя та Карантин. (вразливого ПЗ вiд iншої частини АС, Веб-сервер, Серфiнг, контроль мережного трафiку (вiртуальної конфiгурацiї), реалiзацiя HoneyPot (збирання iнформацiї, монiторинг), тестування фрагментiв перед їх впровадженням до системи)

2.Спецiалiзацiя та спрощення (створення спецiалiзованих серверiв (спрощення аналiзу, пiдвищення стiйкостi системи, вибiр кращої платформи), створення адмiнiстративних серверiв)

3.Керування клiєнтськими платформами (поширення спецiалiзованих пiдсистем, встановлення та поширення систем з заплатками)

4.Проведення випробувань

5.Резервування та вiдновлення систем.

6.Тестування фрагментiв системи.

6.8Оцiнка ефективностi розроблених систем захисту

Оцiнка СЗ передбачає наступнi складовi (див. рис. 6.39) [26]. Особливостi проведення випробувань ефективностi функцiону-

вання засобiв та систем захисту КСМ.

Питання та практичнi завдання

1.Аналiз iнформацiйних потокiв та вiдображення їх на вiдповiдних схемах.

2.Визначення моделей загроз.

3.Визначення моделей порушника.

4.Використання методик аналiзу ризикiв.

266

Роздiл 6

Рис. 6.39. Основнi складовi оцiнювання ефективностi систем захисту

Роздiл 7

ПIДХОДИ ДО СТВОРЕННЯ ЗАХИЩЕНИХ IНФОРМАЦIЙНИХ ТЕХНОЛОГIЙ ПРОВIДНИХ ВИРОБНИКIВ СИСТЕМ ЗАХИСТУ

Останнiм часом сформувалася так називана краща практика (best practices) полiтик iнформацiйної безпеки. Це насамперед практика розробки полiтик, процедур, стандартiв i керiвництв безпеки таких визнаних технологiчних лiдерiв, як IBM, Sun Microsystems, Cisco Systems, Microsoft, Symantec, SANS й iн. Розглянемо наскiльки цi практики й рекомендацiї можуть бути кориснi для розробки полiтик безпеки у вiтчизняних компанiях.

7.1Концепцiя розроблення захищених систем компанiї IBM

На думку фахiвцiв IBM, розробка корпоративних керiвних документiв в областi безпеки повинна починатися зi створення полiтики iнформацiйної безпеки. При цьому рекомендується використати мiжнародний стандарт ISO 17799:2005 i розглядати полiтику безпеки компанiї як складову частину процесу управлiння iнформацiйними ризиками (див. рис. 7.1). Уважається, що розробка полiтики безпеки вiдноситься до стратегiчних завдань менеджменту компанiї, що здатний адекватно оцiнити вартiсть її iнформацiйних активiв i прийняти обґрунтованi рiшення зi захисту iнформацiї з урахуванням цiлей i завдань бiзнесу.

Компанiя IBM видiляє наступнi основнi етапи розробки полiтики безпеки:

визначення iнформацiйних ризикiв компанiї, здатних завдати максимальної шкоди, для подальшої розробки процедур i захо-

267

268

Роздiл 6

Рис. 7.1. Процес розробки полiтики безпеки компанiї

дiв iз попередження їхнього виникнення;

розробка полiтики безпеки, що описує заходи захисту iнформацiйних активiв, адекватнi цiлям i завданням бiзнесу;

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

оцiнка залишкових iнформацiйних ризикiв й ухвалення рiшення про додатковi iнвестицiї в засоби й заходи безпеки. Рiшення приймає керiвництво на основi аналiзу залишкових ризикiв.

7.1.1 Структура документiв безпеки

Полiтика безпеки компанiї, з погляду IBM, повинна мiстити явна вiдповiдь на питання “Що потрiбно захистити?”. Дiйсно, якщо керiвництво компанiї розумiє, що необхiдно захистити, якi iнформацiйнi ризики й загрози iнформацiйним активам компанiї iснують, тодi можна приступати до створення ефективної полiтики iнформацiйної безпеки. При цьому полiтика безпеки є першим стратегiчним документом, якому необхiдно створити i який мiстить мiнiмум технiчних деталей, будучи настiльки статичним (незмiнним), наскiльки можливо. Передбачається, що полiтика безпеки компанiї буде мiстити:

визначення iнформацiйної безпеки з описом позицiї й намiрiв керiвництва компанiї по її забезпеченню;

опис вимог по безпецi, у якi входить:

Приклади побудови захищених iнформацiйних технологiй

269

–вiдповiднiсть вимогам законодавства й контрактних зобо- в’язань;

–навчання питанням iнформацiйної безпеки;

–попередження й виявлення вiрусних атак;

–планування безперервностi бiзнесу;

–визначення ролей й обов’язкiв по рiзних аспектах загальної програми iнформацiйної безпеки;

–опис вимог i процесу звiтностi по iнцидентах, пов’язаним з iнформацiйною безпекою;

–опис процесу пiдтримки полiтики безпеки.

Компанiя IBM рекомендує виконати наступнi дiї для розробки ефективної полiтики безпеки компанiї:

аналiз бiзнесу-стратегiї компанiї й визначення вимог по iнформацiйнiй безпецi;

аналiз IТ-стратегии, що течуть проблем iнформацiйної безпеки

йвизначення вимог по iнформацiйнiй безпецi;

створення полiтики безпеки, взаємно ув’язаної з бiзнес- i IТстратегиями.

У цьому випадку рекомендує структура, що, що керують до-

кументiв по забезпеченню iнформацiйної безпеки компанiї може бути представлена в такий спосiб (рис. 7.2).

Рис. 7.2. Структура керiвних документiв безпеки

270

Роздiл 6

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

У поданнi IBM полiтики й стандарти безпеки створюються для:

розробки правил i норм безпеки рiвня компанiї;

аналiзу iнформацiйних ризикiв i способiв їхнього зменшення;

формалiзацiї способiв захисту, якi повиннi бути реалiзованi;

визначення очiкувань iз боку компанiї й спiвробiтникiв;

чiткого визначення процедур безпеки, яким потрiбно випливати;

забезпечення юридичної пiдтримки у випадку виникнення проблем в областi безпеки.

Стандарти реалiзуються за допомогою практик й/або проце-

дур. Практики є реалiзацiєю стандартiв в операцiйних системах, додатках й iнформацiйних системах. У них деталiзуються сервисы, установлюванi на операцiйних системах, порядок створення облiкових записiв i т.д. Процедури документують процеси запиту й пiдтвердження доступу до певних сервiсiм, наприклад VPN.

Розглянемо особливостi пропонованого пiдходу IBM (рис. 7.3) на наступному прикладi:

проблемна ситуацiя спiвробiтники завантажують програмне забезпечення з мережi Iнтернет, що приводить до зараження вiрусами, а в остаточному пiдсумку до зменшення продуктивностi роботи спiвробiтникiв компанiї;

у полiтику безпеки додається рядок “iнформацiйнi ресурси компанiї можуть бути використанi тiльки для виконання службових обов’язкiв”. Полiтика безпеки доступна для ознайомлення всiм спiвробiтникам компанiї;

створюється стандарт безпеки, у якому описується, якi сервисы й програмне забезпечення дозволенi для використання спiвробiтниками; практика безпеки описує, як настроїти операцiйну систему вiдповiдно до вимог стандарту безпеки;

процедура безпеки описує процес запиту й одержання дозволу

Приклади побудови захищених iнформацiйних технологiй

271

на використання додаткових сервiсiв або установку додаткового програмного забезпечення спiвробiтниками;

установлюються додатковi сервисы для контролю виконання вимог полiтики безпеки.

Рис. 7.3. Пiдхiд IBM до розробки документiв безпеки

7.1.2Приклад стандарту безпеки для ОС сiмейства UNIX

Мета та область дiї стандарту: документ визначає вимоги по захисту комп’ютерiв, що працюють пiд управлiнням ОС сiмейства UNIX.

Аудиторiя: персонал служб iнформацiйних технологiй й iнформацiйної безпеки.

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

Термiн дiї: з 1 сiчня до 31 грудня ... року.

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

272

Роздiл 6

Пiдтримка: iз всiх питань, пов’язаним iз цим стандартом, звертатися у вiддiл iнформацiйної безпеки.

Перегляд стандарту: стандарт переглядається щорiчно. СТАНДАРТ БЕЗПЕКИ ОС СIМЕЙСТВА UNIX ОБЛIКОВI ЗАПИСИ КОРИСТУВАЧIВ I ГРУП

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

Адмiнiстрування облiкових записiв користувачiв i груп:

облiковi записи iз привiлеями, рiвними привiлеям облiкового запису root, забороненi;

всi iдентифiкатори груп i користувачiв повиннi бути змiненi таким чином, щоб не було однакових облiкових записiв i володiння облiковим записом могло бути вiдстежено;

видача привiлейованих облiкових записiв повинна вироблятися з дозволу власника системи;

кожен користувач системи повинен мати облiковий запис iз унiкальним iм’ям, iдентифiкатором користувача й паролем;

всi системнi адмiнiстратори повиннi мати свiй власний облiковий запис;

безпосереднiй доступ до облiкового запису root для виконання повсякденних адмiнiстраторських завдань заборонений;

тiльки облiковим записам адмiнiстраторiв надається право пiдвищення рiвня привiлеїв;

процес реєстрацiї в системi повинен вiдображати данi про попереднiй вхiд у систему;

неактивнi облiковi записи користувачiв повиннi бути вилученi;

всi користувальницькi shell повиннi бути в списку легальних shell операцiйної системи;

додавання нового shell здiйснюється системними адмiнiстраторами з дозволу власника системи.

Профiлi користувачiв. Всi глобальнi профiлi повиннi мати значення umask, рiвне 0 2 3, тобто повний доступ для власника, доступ на читання й виконання для членiв групи власникiв

Приклади побудови захищених iнформацiйних технологiй

273

i доступ на читання для всiх iнших користувачiв. Адмiнiстратори повиннi перевiряти iндивiдуальнi профiлi для забезпечення цiлiсностi системи. Заборонено використати поточну директорiю в змiнної shell PATH.

Полiтика використання паролiв. Паролi повиннi задовольняти вимогам, описаним в Iнструкцiї з використання паролiв.

Домашнi директорiї. Домашнi директорiї обов’язковi для будь-якого облiкового запису, якщо тiльки це не потрiбно для якого-небудь додатка.

Спiльно використовуванi директорiї. Директорiї можуть використатися спiльно декiлькома облiковими записами, що належать до однiєї групи або об’єднаними загальною функцiональною потребою. Членам такої групи дозволяється доступ на запис у директорiю. Група (її iдентифiкатор) є власником всiх файлiв i вкладених директорiй.

Спiльно використовуванi облiковi записи. Використання одного користувальницького облiкового запису для спiльної роботи декiлькома користувачами заборонено. Дозволяється спiльно використати тiльки спецiальнi адмiнiстраторськi облiковi записи або облiковi записи для операцiй вiдновлення, при цьому данi облiковi записи не повиннi мати права пiдвищувати свої привiлеї.

Привiлейованi облiковi записи. Цi облiковi записи мають право пiдвищувати свої привiлеї до рiвня root. Спiльне їхнє використання строго забороняється. Обов’язково журналирование таких облiкових записiв, i виданi вони можуть бути тiльки системним адмiнiстраторам й адмiнiстраторам додаткiв.

Привiтальне запрошення. При реєстрацiї користувача в системi повинне з’являтися привiтальне запрошення. Це повiдомлення повинне мати наступний змiст:

ця система призначена для використання тiльки авторизованими користувачами;

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

реєстрацiя дiй користувачiв у системi може здiйснюватися при неналежному використаннi ними системи або при проведеннi

274

Роздiл 6

регламентних робiт;

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

МЕРЕЖНИЙ ДОСТУП ВIДДАЛЕНИЙ ДОСТУП

Команди вiддаленого управлiння. Вилучений доступ до

системи з використанням г-команд сiмейства BSD для вилученого управлiння (rlogin, rexec) повинен бути вiдключений, якщо тiльки не iснує iншого способу управляти додатками й системою. Якщо такий доступ необхiдний для вивантаження/завантаження файлiв, то повинна бути створена спецiальний облiковий запис таким чином, щоб не можна було з її допомогою одержати shell. Використання г-команд для вилученого управлiння заборонено.

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

Вiддалений доступ пiд облiковим записом root. Безпосереднiй доступ у систему пiд облiковим записом root заборонений. Адмiнiстратори повиннi реєструватися в системi пiд своїм персональним облiковим записом i використати команду su для пiдвищення привiлеїв.

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

Ланцюжок довiри. Ланцюжка довiри мiж комп’ютерами не повиннi включати системи, якi не задовольняють вимогам цього стандарту.

Сервiс TFTP. Сервiс TFTP не повинен дозволяти вивантаження файлiв.

Сервiс FTP. Заборонено використання скриптов для автоматичної реєстрацiї в FTP. Для анонiмного доступу по FTP повинна бути використана непривiлейований облiковий запис. Дозволу на

Приклади побудови захищених iнформацiйних технологiй

275

доступ до дерева каталогу, використовуваного сервiсом FTP, повиннi гарантувати цiлiснiсть системи й забороняти неконтрольоване завантаження файлiв. Якщо сервiс доступний з Iнтернету, то для вивантаження файлiв необхiдно використати окрему файлову систему.

Сервiс HTTP. Перед установкою Web-сервера обов’язковим є одержання дозволу у власника системи. Web-додатки не повиннi мати потребу в адмiнiстративних привiлеях нi для адмiнiстрування, нi для функцiонування.

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

ДОДАТКИ

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

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

Спiльно використовуванi директорiї й файли. Якщо файлова пiдсистема використає семантику BSD, то файли й директорiї, спiльно використовуванi декiлькома додатками й/або групами користувачiв, повиннi належати до певної додаткової групи, до якої належать всi авторизованi UI. Варто використати настроювання, що попереджають неавторизоване видалення й крадiжку файлiв. Повиннi бути використанi списки контролю доступу, якщо система пропонує розширенi механiзми безпеки з POSI.

ЦIЛIСНIСТЬ СИСТЕМИ

Мережнi сервисы. Всi невикористовуванi сервисы повиннi бути вiдключенi навiть для локальних користувачiв. Для “демонiв”

276

Роздiл 6

мережних сервисов, якi не мають можливостi використати списки контролю доступу, необхiдно використати TCP-пакувальники (wrappers) або подiбнi iнструменти. Сервисы мережного тестування й налагодження, включаючи echo, charged, spray, повиннi бути вiдключенi.

Дозволи на доступ до файлiв:

мiнiмальнi дозволи на директорiї користувачiв повиннi бути: read, write, execute для власника; read, execute для групи, у яку входить користувач; “немає доступу” для всiх iнших користувачiв;

дозволу за замовчуванням не повиннi допускати доступу ззовнi; дозволу на спецiальнi файли (fifos, AF UNIX sockets, devices, memory) повиннi строго контролюватися;

можливiсть змiнювати конфiгурацiю системи повиннi мати тiльки адмiнiстратори;

будь-якi файли, якими володiє невiдомий користувач, повиннi бути вилученi пiсля проведення розслiдування.

Властивостi монтування файлової системи. Скрiзь, де це

можливо:

файловi системи, видiленi для зберiгання даних й iєрархiї користувачiв, повиннi бути змонтованi з опцiями, еквiвалентними nosuid й nodev;

файловi системи, видiленi для тимчасових областей тестуван-

ня, типу /tmp, де створення й запис файлiв наданi всiм, повиннi бути змонтованi з опцiями, еквiвалентними nosuid, nodev i поехес.

Файли управлiння завданнями. Доступ до механiзмiв управлiння завданнями, таким, як at або cron, повинен бути дозволений тiльки системним адмiнiстраторам або адмiнiстраторам додаткiв.

Пiдвищення користувальницьких привiлеїв:

заборонено використання SUI/SGiD-скриптовых shell;

заборонено використання cheap fork/exec SUiD-бинарников як пакувальникiв;

пiдвищення привiлеїв для пакувальникiв повинне використати механiзм SGI там, де це можливо;

заборонено будь-якi команди SUI/SGI, якi можуть закiнчуватися в shell escape;

Приклади побудови захищених iнформацiйних технологiй

277

адмiнiстратори систем i додаткiв, що володiють можливiстю пiдвищення привiлеїв до рiвня root, повиннi пiдвищувати їх тiльки з використанням пакувальникiв shell, таких, як sudo, calife, super. Цi пакувальники необхiдно встановлювати так, щоб тiльки адмiнiстратори могли виконувати набiр дозволених їм команд. Повинен бути органiзований ретельний аналiз аргументiв командного рядка.

Журналiзацiя. Журнали системної активностi повиннi збе-

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

Синхронiзацiя часу. Синхронiзацiя часу повинна походити з довiреного джерела.

КРИТИЧНI СИСТЕМИ Й СИСТЕМИ, ДОСТУПНI З IНТЕРНЕТУ ОБЛIКОВI ЗАПИСИ ГРУП I КОРИСТУВАЧIВ

Глобальнi профiлi користувачiв. Всi глобальнi профiлi користувачiв повиннi використати мiнiмальну umask 0 2 7, тобто повний доступ для власника, read й execute для власника групи, “немає доступу” для всiх iнших користувачiв.

Облiковi записи кiнцевих користувачiв. Облiковi записи кiнцевих користувачiв забороненi. Повиннi бути доступнi тiльки облiковi записи системних адмiнiстраторiв.

Вiдновлення паролiв. Всi паролi повиннi обновлятися вiдповiдно до полiтики використання паролiв.

Профiлi користувачiв. Пiсля виходу iз системи файли, що мiстять перелiк уведених команд, повиннi бути очищенi. Їхнiй змiст може бути перед ЦИМ скопiйовано в захищену вiд доступу область для подальшого аналiзу.

ВIДДАЛЕНИЙ ДОСТУП

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

ДОДАТКИ

Мережнi додатки. Мережнi додатки повиннi бути iнтегрованi й сконфiгурованi таким чином, щоб злом додатка не привiв до

278

Роздiл 6

злому самого сервера.

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

Уразливостi програмного забезпечення. Системнi адмiнiстратори й адмiнiстратори додаткiв вiдповiдають за установку останнiх вiдновлень вiд виробникiв використовуваного програмного забезпечення.

Iнструменти розробки. Установка будь-яких засобiв розробки й налагодження, включаючи компiлятори й налагоджувальники, заборонена.

ЦIЛIСНIСТЬ СИСТЕМИ

Зменшення поверхнi атак. Всi невикористовуванi сервисы повиннi бути вiдключенi.

Файли управлiння завданнями. Всi зовнiшнi команди в завданнях повиннi використати абсолютнi шляхи, а не вiдноснi.

Безпека критичних системних файлiв i файлiв даних:

всi критичнi системнi файли й критичнi файли додаткiв повиннi регулярно перевiрятися по базi сигнатур (власник, дозволи, дата останньої змiни, МБ5-сума);

поява файлiв дампiв ядра повинне бути негайно виявлено, i iз цього приводу необхiдно провести розслiдування;

пошук, журналiзацiя нових файлiв i директорiй, не представлених у базi даних, i створення звiтiв про них повиннi бути автоматизованими й аналiзуватися адмiнiстраторами;

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

Журналiзацiя. Журнали активностi додаткiв i системи повиннi зберiгатися як мiнiмум один мiсяць на локальних носiях iнформацiї i як мiнiмум шiсть мiсяцiв на зовнiшнi.

Журнали для систем типу серверiв автентифiкацiї вилучених користувачiв повиннi зберiгатися на зовнiшнiх носiях iнформацiї протягом одного року.

Синхронiзацiя часу. Системи повиннi використати як мiнiмум два надiйних джерела часу.

Приклади побудови захищених iнформацiйних технологiй

279

Властивостi монтування файлової системи. Файловi системи, використовуванi для /bin, /sbin, /usr, i будь-якi iншi каталоги, якi вважаються статичними, повиннi бути змонтованi в режимi “тiльки для читання”.

Сервисы каталогiв. Використання неперевiрених сервисов типу зовнiшнiх DNS-серверiв заборонено, якщо це може вплинути на системи або сервисы.

Уразливостi програмного забезпечення. Системнi адмiнiстратори вiдповiдають за установку останнiх вiдновлень вiд виробникiв використовуваного програмного забезпечення для пiдтримки необхiдного рiвня безпеки системи.

7.2Концепцiя розроблення захищених систем компанiї Microsoft

Компанiя Microsoft має складну корпоративну iнфраструктуру, що складається з 6 тис. серверiв Windows Server 2003 (з них 800 серверiв додаткiв). У штатi компанiї працює бiльше 55 тис. спiвробiтникiв. Спiвробiтники дуже добре готовi технiчно, i 95% з них мають адмiнiстраторськi права на своїх комп’ютерах. Бiльш нiж 300 тис. комп’ютерiв компанiї розташованi в 400 представництвах по усьому свiтi, використовується бiльше 1,6 тис. додаткiв.

У мережу компанiї щодня надходить приблизно 8 млн. поштових повiдомлень ззовнi, i приблизно 6,5 млн. поштових повiдомлень циркулює щодня в мережi самої компанiї. У мережу компанiї мають доступ 30 тис. партнерiв. Унiкальна iнфраструктура по розробцi продуктiв, тестуванню й пiдтримцi, вихiдний код продуктiв вимагають особливого захисту. Щомiсяця на мережу компанiї здiйснюється понад 100 тис. спроби вторгнення. У поштову систему щомiсяця надходить понад 125 тис. поштовi повiдомлення, заражених вiрусами (у день приблизно 800 нових вiрусiв), i 2,4 млн. поштових повiдомлень Зi спамом у день.

Обов’язок по забезпеченню iнформацiйної безпеки в компанiї Microsoft покладена на двi групи Corporate Security Group й Operations and Technology Group.

Компанiя Microsoft розробила стратегiю безпеки, що складає з 4 основних компонентiв:

280

Роздiл 6

мiсiя корпоративної безпеки,

принципи операцiйної безпеки,

модель прийняття рiшень, заснована на аналiзi ризикiв,

тактичне визначення прiоритетностi дiй по зменшенню ризикiв.

Фундаментом для дизайну, розробки й нормального функцiонування захищених систем є принципи безпеки, роздiленi на кiлька категорiй (див. табл. 7.1).

Табл. 7.1 Принципи безпеки захищених систем

Категорiя	Принцип безпеки
Органiзацiйна	Управлiння ризиками вiдповiдно до
Спрямована на отримання пiдтримки	завдань бiзнесу
керiвництва з управлiння ризиками	Визначення ролей i обов’язкiв
та ознайомлення з питаннями	Iнвестицiї в дизайн захищеностi
безпеки	Забезпечення безпеки операцiй
Користувачi i данi	Управлiння принципом найменших
Включає автентифiкацiю, захист	привiлеїв
даних користувачiв, авторизацiю	Класифiкацiя даних i користувачiв
	Впровадження захисту даних i
	користувача iдентичностi
	Захист iнформацiї
	Гарантiї цiлiсностi даних
	Монiторинг гарантiй iдентичностi
	Доступнiсть
Розробка додаткiв i систем	Убудовування безпеки в житєвий цикл
Видiлена для дизайну i розробки	Дизайн "багаторiвневого захисту"
захищених систем	Зменшення поверхнi атаки
	Збереження простоти користування
Операцiї i супроводження	План пiдтримки систем
Об’єднання людей, процесiв i	Впровадження захищених конфiгурацiй
технологiй для побудови. пiдтримки	Монiторинг i журналiзацiя
i використання захищених систем	Практика реагування на iнциденти
	Перевiрка процедур вiдновлення
	на випадок аварiї

Для забезпечення iнформацiйної безпеки Corporate Security Group використає пiдхiд по управлiнню iнформацiйними ризиками (рис. 7.4). Пiд управлiнням ризиками тут розумiється процес визначення, оцiнки й зменшення ризикiв на постiйнiй основi: управлiння ризиками безпеки дозволяє знайти розумний баланс мiж вартiстю засобiв i мер захисту й вимогами бiзнесу.

Модель управлiння ризиками Corporate Security Group являє

Приклади побудови захищених iнформацiйних технологiй

281

Рис. 7.4. Модель управлiння ризиками Corporate Security Group

собою комбiнацiю рiзних пiдходiв, таких, як кiлькiсний аналiз ризикiв, аналiз повернення iнвестицiй у безпеку, якiсний аналiз ризикiв, а також пiдходи кращих практик.

Iнвестування в процес управлiння ризиками iз цiльною структурою й певними ролями й обов’язками готовить органiзацiю до визначення прiоритетiв, плануванню зменшення загрози й переходу до вiдбивання або нейтралiзацiї наступної загрози або уразливостi. Для найкращого управлiння ризиками Corporate Security Group треба традицiйному пiдходу по управлiнню ризиками, що складається iз чотирьох етапiв:

оцiнка iнформацiйних ризикiв виконання методологiї оцiнки ризику для визначення його величини;

розробка полiтики безпеки розробка полiтики безпеки по зменшенню, вiдхиленню й попередженню ризикiв;

впровадження засобiв захисту об’єднання спiвробiтникiв, процесiв i технологiй для зменшення ризикiв, пов’язаних з аналiзом спiввiдношення “цiна якiсть”;

аудит безпеки й вимiр поточної захищеностi монiторинг, аудит безпеки й вимiр захищеностi iнформацiйних систем компанiї.

Як видно з рис. 7.5, розробка полiтики є одним з етапiв по

282

Роздiл 6

управлiнню iнформацiйними ризиками.

Методологiя, використовувана при розробцi полiтики, базується на стандартi ISO 17799:2005 (BS 7799).

Рис. 7.5. Етапи управлiння iнформацiйними ризиками

Рекомендована компанiєю Microsoft полiтика безпеки мiстить

усобi:

визначення цiлей безпеки;

важливiсть забезпечення безпеки;

визначення необхiдного рiвня безпеки;

стандарти безпеки, включаючи стратегiї їхнього монiторингу й аудита;

ролi й вiдповiдальнiсть по забезпеченню безпеки;

мети й завдання офiцера по безпецi;

визначення процесiв по захисту iндивiдуальних компонентiв архiтектури;

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

досягнення максимально можливого рiвня якостi, надiйностi й конфiденцiйностi iнформацiї;

збереження репутацiї компанiї;

недопущення ушкодження або втрати iнформацiї, процесiв,

Приклади побудови захищених iнформацiйних технологiй

283

власностi компанiї й забезпечення в такий спосiб безперервної роботи компанiї;

збереження цiнностi iнформацiї, iнтелектуальної власностi й технологiчних ресурсiв.

Для розробки цiлей безпеки створюється комiтет з iнформацiйнiй безпецi. Комiтет складається зi спiвробiтникiв з досвiдом роботи в областi безпеки, технiчних спiвробiтникiв i представникiв iнших пiдроздiлiв пiд керiвництвом офiцера по безпецi.

Комiтет вирiшує наступнi завдання:

розробка й управлiння життєвим циклом полiтики безпеки;

створення процесiв, що забезпечують досягнення цiлей безпеки;

створення процесiв i планiв по реалiзацiї стандартiв, описаних у полiтику;

допомога в органiзацiї програм ознайомлення з питаннями безпеки;

консультування персоналу з питань безпеки;

визначення бюджету й необхiдних ресурсiв по забезпеченню безпеки.

7.3Концепцiя розроблення захищених систем компанiї Sun Microsystems

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

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

284

Роздiл 6

управлiння бiзнесом,

технiчне управлiння,

вiддiл захисту iнформацiї,

департамент управлiння ризиками,

департамент системних операцiй,

департамент розробки додаткiв,

вiддiл мережного адмiнiстрування,

вiддiл системного адмiнiстрування,

служба внутрiшнього аудита i якостi,

юридичний вiддiл,

вiддiл кадрiв.

7.3.1 Структура полiтики безпеки

Структура документiв, що рекомендує, полiтики безпеки:

опис основних цiлей i завдань захисту iнформацiї,

визначення вiдносини керiвництва компанiї до полiтики безпеки,

обґрунтування шляхiв реалiзацiї полiтики безпеки,

визначення ролей й обов’язкiв вiдповiдальних за органiзацiю режиму iнформацiйної безпеки в компанiї,

визначення необхiдних правил i норм безпеки,

визначення вiдповiдальностi за порушення полiтики,

визначення порядку перегляду й контролю положень полiтики безпеки.

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

Зв’язок зi стандартами й процедурами безпеки. Полiтика безпеки мiстить очiкування посiбника iз забезпечення безпеки,

Приклади побудови захищених iнформацiйних технологiй

285

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

Основнi iдеї полiтики безпеки. До основних iдей полiтики безпеки вiдносяться:

визначення цiнностi iнформацiйних активiв;

Розробка полiтики безпеки компанiї заснована на необхiдностi

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

управлiння залишковими ризиками;

Для створення реалiстичної полiтики безпеки компанiї необхi-

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

R = HxP;

де H грошова оцiнка збитку в результатi iнциденту; P iмовiрнiсть iнциденту.

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

Тепер представимо персональний рахунок клiєнта, що захищений лише 4-значним PIN-кодом. Iмовiрнiсть пiдбора такого коду дорiвнює 0,001. Якщо представити, що середня сума на балансi становить 3 тис. доларiв, то ризик складе 30 центiв. Тобто ризик

286

Роздiл 6

злому банкiвського рахунку може бути в 30 разiв вище ризику втрати джерела харчування вартiстю 10 млн. доларiв.

Варто сказати, що завдання управлiння ризиками складається не в тiм, щоб визначати ризик винятково кiлькiсно з високою точнiстю й вiрогiднiстю. Тут досить просто розумiння природи ризику й визначення такої метрики ризику, що дозволяє вимiрювати, порiвнювати, спостерiгати й оптимизировать залишковi ризики компанiї й тим самим установлювати, наскiльки полiтика безпеки вiдповiдає вимогам бiзнесу.

управлiння iнформацiйною безпекою;

Необхiдно чiтко представляти, що тiльки один компонент кор-

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

обґрунтована довiра.

Довiра основа всiх декларацiй безпеки компанiї. Для довiри

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

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

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

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

етики забезпечення iнформацiйної безпеки компанiї повинне здiйснюватися у вiдповiдностi зi стандартами етики, застосов-

Приклади побудови захищених iнформацiйних технологiй

287

ними до дiяльностi компанiї;

комплексностi полiтики, стандарти, практики й процедури безпеки повиннi охоплювати всi рiвнi забезпечення безпеки: нормативно-методичний, економiчний, технологiчний, технiчний й органiзацiйно-управлiнський;

економiчної виправданостi забезпечення безпеки компанiї повинне бути економiчно виправданим;

iнтеграцiї полiтики, стандарти, практики й процедури безпеки повиннi бути скоординованi й iнтегрованi мiж собою;

своєчасностi забезпечення безпеки компанiї повинне дозволяти вчасно реагувати на загрози безпеки й парирувати їх;

перегляду регулюючi документи в областi безпеки компанiї повиннi перiодично переглядатися й доповнюватися;

демократичностi забезпечення безпеки iнформацiйних активiв компанiї повинне здiйснюватися вiдповiдно до прийнятих норм демократiї;

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

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

найменших привiлеїв спiвробiтникам компанiї повиннi бути наданi привiлеї, необхiднi для виконання службових обов’язкiв, i не бiльше того;

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

безперервностi повинна бути забезпечена необхiдна безперервнiсть бiзнесу компанiї у випадку надзвичайних ситуацiй;

простоти повинне бути вiддане перевага бiльше простим засобам i технологiям забезпечення безпеки.

288

Роздiл 6

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

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

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

Реалiзацiя в iнформацiйних системах. Пiсля створення полiтики безпеки, а також вiдповiдних процедур безпеки цi процедури можуть бути реалiзованi в iнформацiйних системах компанiї. Наприклад, у системах, заснованих на технологiї Java, деякi вимоги полiтики безпеки можуть обумовити необхiднiсть установки додаткових криптопровайдерiв стороннiх виробникiв, у той час як iншi вимоги полiтики безпеки можуть бути реалiзованi убудованої в Java бiблiотекою Security API. Варто пiдкреслити, що виконання вимог полiтики безпеки в системах обробки даних не є достатнiм для пiдтримки довiри клiєнтiв: не можна гарантувати безпека без правильної органiзацiї обробки даних.

Етапи розробки полiтики безпеки. Компанiя Sun рекомендує розробляти полiтику безпеки компанiї на основi кращих практик, описаних у вiдомих стандартах безпеки, наприклад ISO 17799:2005. При цьому рекомендуються наступнi етапи розробки полiтики безпеки:

визначення основних цiлей i завдань розвитку бiзнесу

Приклади побудови захищених iнформацiйних технологiй

289

компанiї;

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

опис основних принципiв безпеки;

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

класифiкацiя й категорирование iнформацiйних ресурсiв;

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

аналiз iнформацiйних потокiв;

Цiль аналiзу iнформацiйних потокiв визначити всi крити-

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

визначення основних загроз i моделi порушника; Розробка моделi загроз i моделi порушника дозволяє вирiшити,

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

290

Роздiл 6

визначення сервiсiв безпеки;

Визначення сiрвiсiв безпеки компанiї, наприклад журналiзацiя,

авторизацiї, iдентифiкацiї, автентифiкацiї й iн., дозволяє правильно виробити полiтику безпеки.

створення шаблона полiтики безпеки;

Структура полiтики безпеки може бути рiзна. Цей крок ви-

користовується для чiткого визначення роздiлiв полiтики безпеки компанiї.

визначення областi дiї полiтики безпеки.

Останнiй етап перед створенням перших чорнових варiантiв полiтики безпеки визначення всiх областей, на яких фокусируется полiтика безпеки. Наприклад, можуть бути визначенi полiтики безпеки:

категорування iнформацiйних ресурсiв,

доступу до iнформацiйних ресурсiв,

використання паролiв,

використання шифрування й управлiння ключами,

мережної безпеки,

фiзичної безпеки,

роботи з електронною поштою,

реагування на iнциденти в областi безпеки,

монiторингу й аудита безпеки,

межсетевого екранування,

антивiрусного захисту,

управлiння системами й мережами,

контролю дiй спiвробiтникiв,

резервного копiювання,

допуску стороннiх органiзацiй,

розробки й впровадження додаткiв,

управлiння конфiгурацiями,

виявлення вторгнень й iн.

Шаблон полiтики безпеки. Компанiя Sun рекомендує вико-

ристати наступний шаблон полiтики безпеки:

роздiли: робиться короткий огляд основних роздiлiв полiтики безпеки; заява про призначення: чому потрiбна полiтика безпеки;

область дiї: яка область дiї полiтики безпеки;

Приклади побудови захищених iнформацiйних технологiй

291

заява полiтики: якi специфiчнi особливостi полiтики безпеки;

обов’язки: хто й що повинен робити;

аудиторiя: на кого орiєнтована полiтика безпеки;

впровадження: хто вiдповiдає за впровадження полiтики безпеки; хто вiдповiдає за порушення полiтики безпеки;

виключення: опис можливих виключень;

iншi угоди: опис додаткових угод;

доведення: хто вiдповiдає за доведення полiтики безпеки до спiвробiтникiв; який процес доведення;

процес перегляду й вiдновлення: хто вiдповiдає за перегляд i вiдновлення полiтики безпеки; що являє собою процес перегляду; з яких причин це вiдбувається; перiодичнiсть перегляду полiтики безпеки (наприклад, щорiчно або при виникненнi проблеми);

здiйснення полiтики: хто вiдповiдає за здiйснення полiтики безпеки; як це виконується;

монiторинг вiдповiдностi: як виконується монiторинг вiдповiдностi полiтики безпеки вимогам бiзнесу.

7.3.2 Приклад полiтики безпеки

Введення

У введеннi повиннi бути описанi основнi цiлi й завдання полiтики безпеки.

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

Склад i структура iнформацiйних активiв компанiї;

Класифiкацiя й категорування iнформацiйних активiв;

Визначення власникiв iнформацiйних активiв;

Аналiз загроз й iнформацiйних ризикiв;

Вироблення вимог до захисту конфiденцiйної iнформацiї;

Визначення принципiв, пiдходiв i способiв органiзацiї необхiдного режиму iнформацiйної безпеки;

Створення необхiдного режиму iнформацiйної безпеки компанiї;

292

Роздiл 6

Пiдтримка режиму iнформацiйної безпеки компанiї.

Далi треба короткий виклад полiтики безпеки. Тут важливо показати пози-

цiю керiвництва компанiї по питанню органiзацiї режиму iнформацiйної безпеки.

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

Вступна частина полiтики безпеки може бути описана наступним твердженням: “Доступ до конфiденцiйної iнформацiї компанiї надається тiльки авторизованим спiвробiтникам i користувачам компанiї для виконання своїх службових обов’язкiв”.

Порушення полiтики й вiдповiдальнiсть

У цьому пунктi описується, що є порушенням полiтики безпеки, а також

ступiнь вiдповiдальностi за порушення полiтики безпеки.

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

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

Область дiї полiтики безпеки

Область дiї полiтики безпеки визначається керiвництвом компанiї й описує

границi її застосовностi.

Дiя дiйсної полiтики безпеки поширюється на:

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

вендорiв, що володiють правами доступу до конфiденцiйних ресурсiв компанiї;

клiєнтiв i партнерiв, що володiють правами доступу до конфiденцiйних ресурсiв компанiї.

Приклади побудови захищених iнформацiйних технологiй

293

Використання iнформацiї

Коротко описується порядок використання iнформацiї.

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

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

Передача iнформацiї

Коротко описується порядок передачi iнформацiї з мережi.

Передача даних по мережi компанiї здiйснюється вiдповiдно до вимог дiйсної полiтики безпеки.

Зберiгання iнформацiї

Описується пiдхiд до зберiгання iнформацiї.

Зберiгання даних у мережi компанiї здiйснюється вiдповiдно до вимог дiйсної полiтики безпеки.

Знищення носiїв iнформацiї

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

Затвердження полiтики безпеки

Цей пункт мiстить детальний опис основних положень полiтики iнформацiйної безпеки компанiї.

Цiлi

Цiлi описують адмiнiстративнi завдання полiтики безпеки й чому вона необхiдна.

Цiлi створення цiєї полiтики:

розробити й довести до спiвробiтникiв компанiї вимоги по захисту конфiденцiйної iнформацiї компанiї;

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

установити базовий рiвень захисту iнформацiї в компанiї.

Склад i структура структура iнформацiйної системи

Мiститься опис складу й структури iнформацiйної системи компанiї.

Обов’язки захисту iнформацiї

294

Роздiл 6

Визначення обов’язкiв компанiї по захисту iнформацiї є важливим завданням.

До названих обов’язкiв вiдносяться наступнi:

всi органiзацiйнi одиницi й структури компанiї повиннi гарантувати, що їхнi спiвробiтники дiють вiдповiдно до дiйсної полiтики безпеки;

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

вiддiли безпеки iнформацiї, мережних операцiй i системного адмiнiстрування повиннi гарантувати виконання всiх необхiдних механiзмiв забезпечення безпеки;

вiддiл управлiння ризиками вiдповiдає за коректну класифiкацiю iнформацiї для виконання вимог безпеки;

вiддiл внутрiшнього аудита вiдповiдає за регулярнi перевiрки правильностi класифiкацiї iнформацiї й захищеностi компонентiв iнформацiйної системи компанiї.

Iншi обов’язки

Важливо, щоб полiтика безпеки деталiзувала обов’язку окремих вiддiлiв й/або

груп спiвробiтникiв.

До iнших обов’язкiв вiдносяться наступнi:

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

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

Документування

Документування гарантує, що полiтика безпеки прийнята до дiї й дотриму-

ється на робочих мiсцях у компанiї.

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

Приклади побудови захищених iнформацiйних технологiй

295

журналiв додаткiв, ведення звiтностi по реагуванню на iнциденти й iн.

Перегляд полiтики

Перегляд полiтики безпеки повинен виконуватися як мiнiмум щорiчно для пiд-

тримки її актуальностi.

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

Змiст iнформацiї

Далi описуються типи iнформацiї i як вони можуть бути використанi.

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

Класифiкацiя iнформацiї

Класифiкацiя iнформацiї основа будь-якої полiтики безпеки компанiї.

Служба безпеки вiдповiдає за належну класифiкацiю iнформацiйних активiв компанiї.

Вся оброблювана iнформацiя компанiї пiдроздiляється на наступнi види:

iнформацiя вiдкритого доступу або публiчна iнформацiя;

Iнформацiя, що доступна як усерединi компанiї, так i за її ме-

жами. Розголошення, використання або знищення такої iнформацiї не нанесе збитку компанiї (приклад: новини про компанiї, вартiсть її акцiй).

економiчно коштовна iнформацiя або власнiсть компанiї;

Iнформацiя, що не пiдлягає розголошенню за межами компа-

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

296

Роздiл 6

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

конфiденцiйна iнформацiя;

Iнформацiя, що не повинна бути розголошена незалежно вiд її

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

конфiденцiйна iнформацiя клiєнтiв i партнерiв компанiї; Iнформацiя клiєнтiв i партнерiв, до якої має доступ тiльки

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

публiчна iнформацiя клiєнтiв i партнерiв компанiї. Iнформацiя клiєнтiв i партнерiв, до якої мають доступ як спiв-

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

Визначення власника iнформацiї

Є необхiдним кроком для коректної класифiкацiї iнформацiї компанiї.

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

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

Служба безпеки компанiї вiдповiдає за розробку, реалiзацiю й

Приклади побудови захищених iнформацiйних технологiй

297

пiдтримку процедури по визначенню коштовної iнформацiї компанiї i її власникiв.

Угода про нерозголошення конфiденцiйної iнформацiї

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

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

Декларацiя принципiв безпеки

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

Основнi принципи безпеки компанiї можуть бути описанi в термiнах звiтностi, авторизацiї й доступностi.

7.4Архiтектура безпеки SAFE компанiї Cisco Systems

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

7.4.1 Опис полiтики безпеки

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

Наступний крок створення полiтики припустимого використання для партнерiв, щоб проiнформувати партнерiв компанiї про

298

Роздiл 6

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

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

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

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

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

високий рiвень iнформацiйнi системи й данi, будучи скомпрометованими (доступнi для вивчення неавторизованими особами, ушкодженi або загубленi), приведуть до значного збитку або до серйозних проблем iз правоохоронними органами, або до фiнансових проблем, завданню збиткiв здоров’ю й безпецi спiвробiтникiв. Системи й iнформацiя вимагають iстотних зусиль

Приклади побудови захищених iнформацiйних технологiй

299

по вiдновленню.

Рекомендується визначити рiвень ризику для кожного з перерахованих пристроїв: мережнi пристрої, пристрої монiторингу мережi, сервери автентифiкацiї (TACACS+ й RADIUS), поштовi сервери, файловi сервери, сервери мережних додаткiв (DNS й DHCP), сервери баз даних (Oracle, MS SQL Server), персональнi комп’ютери й iншi пристрої.

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

Пiсля визначення рiвнiв ризику необхiдно визначити ролi користувачiв у цих системах. Рекомендується видiляти наступнi п’ять найбiльш загальних типiв користувачiв:

адмiнiстратори внутрiшнi користувачi, вiдповiдальнi за мережнi ресурси;

привiлейованi користувачi внутрiшнi користувачi з необхiднiстю бiльшого рiвня доступу;

рядовi користувачi внутрiшнi користувачi зi звичайним рiвнем доступу;

партнери зовнiшнi користувачi з необхiднiстю доступу до деяких ресурсiв;

iншi зовнiшнi користувачi або клiєнти.

Визначення рiвнiв ризику й типiв доступу, необхiдних для ко-

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

Визначення складу й структури групи мережної безпеки. Рекомендується створити групу мережної безпеки пiд керiвництвом менеджера по безпецi iз представниками з кожної значимої бiзнесу-одиницi компанiї (мiнiмум iз представникiв одиниць розвитку, виконання й виробництва й/або продажiв). Члени групи

300 Роздiл 6

Табл. 7.2 Матриця безпеки Cisco

Система	Опис	Рiвень	Типи
		ризику	користувачiв
ATM-комутатори	Основнi мережнi	Високий	Мережнi
	пристрої		адмiнiстратори
Мережнi	Мережнi пристрої	Високий	Мережнi
маршрутизатори	розподiлу		адмiнiстратори
Комутатори	Мережнi пристрої	Середнiй	Мережнi
доступу	доступу		адмiнiстратори
ISDNабо dial	Мережнi пристрої	Середнiй	Мережнi i системнi
up-серверы	доступу		адмiнiстратори
Мiжмережнi	Мережнi пристрої	Високий	Адмiнiстратори
екрани	доступу		безпеки
Сервери DNS i	Мережнi додатки	Середнiй	Мережнi i системнi
DHCP			адмiнiстратори
Зовнiшнi поштовi	Мережнi додатки	Низький	Адмiнiстратори
сервери			i користувачi
Внутрiшнi поштовi	Мережнi додатки	Середнiй	Адмiнiстратори
сервери			i користувачi
Сервери баз	Мережнi додатки	Середнiй	Адмiнiстратори баз
даних Oracle		або високий	даних i користувачi

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

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

Тому що порушення безпеки часто виявляються пiд час проведення монiторингу мережi, то члени групи мережної безпеки

Приклади побудови захищених iнформацiйних технологiй

301

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

Попередження. Пiд попередженням порушень компанiя Cisco розумiє пiдтвердження змiн у системах безпеки й монiторинг безпеки мережi.

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

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

у конфiгурацiї мiжмережних екранiв,

у списках контролю доступу,

у конфiгурацiї SNMP,

версiй програмного забезпечення.

Компанiя Cisco рекомендує додержуватися наступних правил:

регулярно змiнювати паролi на мережних пристроях;

обмежити доступ до мережних пристроїв вiдповiдно до затвер-

302

Роздiл 6

дженого списку спiвробiтникiв;

гарантувати, що поточна версiя програмного забезпечення мережного й серверного встаткування вiдповiдає вимогам безпеки.

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

Монiторинг мережної безпеки. Монiторинг мережної безпеки зосереджується на виявленнi змiн у мережi, що дозволяють визначити порушення безпеки. Вiдправною точкою монiторингу безпеки є визначення поняття “порушення безпеки”. Аналiз загроз

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

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

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

Важливо також визначити в полiтику безпеки порядок повiдомлення членiв групи мережної безпеки про порушення. Як пра-

Приклади побудови захищених iнформацiйних технологiй

303

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

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

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

Далi необхiдно чiтко визначити рiвень привiлеїв по внесенню змiн, а також порядок внесення змiн. Тут можливi наступнi коригувальнi дiї:

реалiзацiя змiн для попередження подальшого поширення порушення,

iзолювання ушкоджених систем,

взаємодiя iз провайдером для вiдстеження джерела атаки,

використання записуючих пристроїв для збору доказiв,

вiдключення ушкоджених систем або джерел атаки,

звернення до правоохоронних органiв або федеральних агентств,

вимикання ушкоджених систем,

вiдновлення систем у вiдповiдностi зi списком прiоритетностi,

повiдомлення керiвництва i юристiв компанiї.

Необхiдно деталiзувати будь-якi змiни в полiтику безпеки, якi

можуть бути зробленi без обов’язкового одержання дозволу вiд керiвництва.

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

304

Роздiл 6

на порушення безпеки.

Для визначення наслiдкiв порушення безпеки рекомендується здiйснити наступнi кроки:

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

обмежити подальшi порушення шляхом вiдключення облiкових записiв, вiд’єднання мережного встаткування вiд мережi й вiд Iнтернету;

провести резервне копiювання скомпрометованих систем для проведення детального аналiзу ушкоджень i методу атаки;

спробувати знайти iншi пiдтвердження компрометацiї. Часто при компрометацiї системи виявляються порушеними iншi системи й облiковi записи;

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

Якщо необхiдно зробити юридичнi дiї, варто повiдомити керiв-

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

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

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

Приклади побудови захищених iнформацiйних технологiй

305

вати в актуальному станi захищенiсть активiв мережi. Необхiдно регулярно звертатися на Web-сайти рiзних незалежних аналiтичних центрiв, наприклад CERT або SANS, за корисними радами й рекомендацiями iз забезпечення безпеки й ураховувати Їх у пiдтримуванiй полiтицi безпеки компанiї.

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

7.4.2 Приклад полiтики мережної безпеки

Область дiї полiтики. Як авторизований користувач корпоративної мережi кожен спiвробiтник компанiї має доступ до iнформацiї з рiзним рiвнем конфiденцiйностi. Ознайомлення й дотримання полiтики мережної безпеки компанiї (далi “полiтика”) є важливим обов’язком кожного спiвробiтника для забезпечення конфiденцiйностi, цiлiсностi й доступностi iнформацiйних активiв компанiї. При цьому компанiя треба принципу “знати тiльки те, що необхiдно знати для виконання своїх службових обов’язкiв”.

Цiльова аудиторiя. Полiтика обов’язкова для наступних спiвробiтникiв компанiї:

рядових користувачiв мережi, що виконують свої службовi обо- в’язки на робочих мiсцях;

фахiвцiв IТ-служби й служби безпеки, вiдповiдальних за експлуатацiю й супровiд iнформацiйної системи, а також за дотримання полiтики безпеки;

менеджерiв, вiдповiдальних за органiзацiю режиму iнформацiйної безпеки компанiї;

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

юристiв й аудиторiв компанiї, якi стурбованi збереженням репутацiї компанiї й вiдповiдальнiстю компанiї перед клiєнтами

306

Роздiл 6

й партнерами.

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

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

Зацiкавленi сторони. Наступний персонал з несе особисту вiдповiдальнiсть за створення, пiдтримку й впровадження полiтики мережної безпеки:

директор iз фiнансiв,

директор iз розвитку,

директор служби продаж i маркетингу,

виконавчий директор, СЕО

директор iнформацiйної служби, CIO,

директор служби iнформацiйної безпеки, CISO,

директор iз мереж i телекомунiкацiй,

головний менеджер по iнформацiйних системах,

директор служби якостi й внутрiшнього аудита,

головний юрист компанiї,

директор служби персоналу,

директор системної пiдтримки й супроводу,

директор служби розробки додаткiв.

Обов’язку системного адмiнiстратора. Системний адмiнiстратор мережного обладнання вiдповiдає за виконання наступних вимог;

призначення облiкового запису окремим спiвробiтникам (не групам);

забезпечення унiкальностi облiкових записiв спiвробiтникiв й устаткування усерединi компанiї;

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

Приклади побудови захищених iнформацiйних технологiй

307

здiйснення управлiння облiковими записами й паролями;

вiдключення облiкових записiв при звiльненнi спiвробiтникiв;

зберiгання файлiв конфiгурацiй мережних пристроїв на захищеному TFTP-серверi. Захист конфiгурацiй вiд розголошення. Використання керберизованого rcp мiж маршрутизаторами Cisco i сервером TFTP;

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

використання засобiв управлiння й контролю мережної безпеки для пошуку “слабких” паролiв, мережних уразливостей i засобiв перевiрки цiлiсностi файлiв i системних конфiгурацiй (таких, як Cisco IDS, Cisco Netsys, Crack, COPS, Tiger, Tripwire) на постiйнiй основi.

Процедура пiдтримки полiтики безпеки. Зацiкавленi сторони компанiї повиннi переглядати й обновляти полiтику не рiдше одного разу в рiк. Вiддiл iнформацiйних систем пiд керiвництвом вiддiлу iнформацiйної безпеки проводить аудит мережi на регулярнiй основi й документує результати перевiрок.

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

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

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

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

308

Роздiл 6

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

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

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

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

Полiтика iдентифiкацiї й автентифiкацiї. Полiтика iдентифiкацiї й автентифiкацiї визначає процедурнi й технiчнi методи, використовуванi для iдентифiкацiї й автентифiкацiї.

Керiвництво з управлiння паролями. Наступнi принципи визначають правила вибору пароля:

паролi, якщо можливо, повиннi використати рядковi й прописнi букви, роздiловi знаки й числа, повиннi мати довжину як мiнiмум вiсiм символiв;

змiнювати паролi треба щокварталу;

не можна записувати паролi;

не можна повiдомляти паролi кому б те не було.

Керiвництво з автентифiкацiї. Компанiя повинна вико-

ристати захищену базу облiкових записiв на основi протоколу TACACS+ для автентифiкацiї.

Полiтика доступу в Iнтернет. Компанiя усвiдомлює важливiсть доступу спiвробiтникiв в Iнтернет для ведення бiзнесу й при-

Приклади побудови захищених iнформацiйних технологiй

309

ймає можливi ризики, пов’язанi iз цими пiдключеннями. Полiтику доступу в Iнтернет визначає Керiвництво з доступу

в Iнтернет.

Припустиме використання. Вихiдний доступ в Iнтернет може бути вiльно використаний спiвробiтниками для виконання службових обов’язкiв. Повинне бути визначене й реалiзоване розумне обмеження на загальний час роботи в Iнтернетi.

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

Полiтика публiчних сервiсiв. Вхiдний доступ з Iнтернету у внутрiшню мережу компанiї буде заборонений, якщо тiльки не використається шифрування на мережному рiвнi. Вхiдний доступ повинен бути обмежений сервiсами захищеного хоста, такими, як SMTP, HTTP, FTP, DNS.

Полiтика доступу у внутрiшню мережу компанiї. Полiтика доступу у внутрiшню мережу компанiї визначає процес видачi прав доступу спiвробiтниковi до ресурсiв.

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

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

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

310

Роздiл 6

серверами використовується шифрування на мережному рiвнi.

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

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

Автентифiкацiя вiддаленого доступу повинна вiдбуватися з використанням TACACS+ або токенiв.

Мобiльнi комп’ютери. Спiвробiтники компанiї, що бiдують у вiддаленому доступi в мережу компанiї з мобiльних комп’ютерiв, одержують такий доступ через сервери мережного доступу, що перебувають пiд управлiнням вiддiлу iнформацiйних технологiй. Спiвробiтники повиннi використати комп’ютери з операцiйними системами Windows 95, Windows 98, Windows 2000 або Apple Macintosh iз програмним забезпеченням для органiзацiї вiддаленого доступу, затвердженим вiддiлом iнформацiйних технологiй.

Спiвробiтники компанiї й стороннi органiзацiї можуть використати телефоннi мережi загального доступу для одержання доступу у внутрiшню мережу компанiї, при цьому обов’язково повиннi використатися одноразовi (one-time) паролi.

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

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

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

Приклади побудови захищених iнформацiйних технологiй

311

повинен визначати їхня вiдповiдальнiсть за виконання всiх полiтик безпеки компанiї.

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

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

Полiтика шифрування. Для всiх видiв вiддаленого доступу необхiдно використати шифрування. Вибiр алгоритму шифрування ґрунтується на досягненнi балансу мiж конфiденцiйнiстю переданих даних i необхiдною швидкiстю передачi.

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

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

можливiстю монiторингу демiлiтаризованої зони й вiдповiдною продуктивнiстю для цього;

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

можливiстю вiддаленого адмiнiстрування системи виявлення вторгнень через iнтуїтивно зрозумiлий графiчний iнтерфейс,

312

Роздiл 6

iнтегрований у систему управлiння мережею. Це гарантує цiлiснiсть впровадження полiтики безпеки на рiвнi компанiї;

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

ки для наступного детального дослiдження.

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

пiдготовка й планування персонал вiддiлу iнформацiйних систем повинен мiнiмум 16 годин щорiчно навчатися виявленню й нейтралiзацiї iнцидентiв. Процедура визначає тип i тривалiсть тренiнгiв;

визначення iнцидентiв системнi адмiнiстратори повиннi проводити монiторинг системи виявлення вторгнень кiлька разiв у день. Системнi журнали варто переглядати один раз у годину й наприкiнцi робочого дня. Черговий старший системний адмiнiстратор вiдповiдає за виявлення й реагування на iнцидент. Процедура реагування на iнциденти повинна визначати рiвнi прiоритетiв iнцидентiв так, як пропонується в RFC 2196, “Site Security Handbook’;

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

визначення типу й прiоритету атаки;

визначення часу початку й закiнчення атаки;

визначення джерела атаки;

визначення порушених атакою комп’ютерiв i мережних пристроїв;

Приклади побудови захищених iнформацiйних технологiй

313

журналiзацiя атаки;

спроба зупинити атаку або зменшити її наслiдку;

iзолювання порушених систем;

повiдомлення вiдповiдних контактних осiб;

захист доказiв атаки (файлiв журналiв);

вiдновлення працездатностi сервiсiв;

документування пiд керiвництвом директора служби iнформацiйних технологiй повинен бути створений звiт про iнцидент, у якому необхiдно вiдбити наступнi питання:

iнвентаризацiя цiнностi порушених атакою систем;

опис атаки;

перегляд полiтики мережної безпеки (при необхiдностi);

пошук i покарання зловмисникiв.

Контактнi особи (табл. 7.3)

7.5Концепцiя розроблення захищених систем компанiї Symantec

Керiвнi документи в областi безпеки (полiтики, стандарти, процедури й метрики безпеки), як думають в Symatec, є основою будьякої успiшної програми забезпечення iнформацiйної безпеки компанiї (див. рис. 7.6).

Наочно прояву розходжень полiтик, стандартiв i процедур безпеки представленi на рис. 7.7.

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

7.5.1 Опис полiтики безпеки

Основнi етапи розробки полiтики безпеки. Компанiя Symantec видiляє наступнi основнi етапи розробки полiтики безпеки:

314	Роздiл 6
Табл. 7.3 Члени команди по реагуванню на iнциденти
Контактна особа	Роль
Черговий старший	Перша точка контакту з визначення i реакцiї
системний	на iнцидент
адмiнiстратор	Документування iнциденту у звiтi
Головний менеджер	Перша точка контакту ссеред керiвникiв
з iнформацiйних	Визначає, як реагувати на iнцидент
систем	Координацiя дiй системних
	адмiнiстраторiв на випадок серйозних iнцидентiв
	Повинен бути доступним 24 години на добу
	Контактує з наступною персоною по команднiй
	лiнiї
Начальник вiддiлу	Ескалацiя iнциденту командi з реагування
iнформацiйної	на iнциденти, такої, як CERT
безпеки	Пiдключення до роботи правоохоронних органiв
Вiце президент з	Працює з керiвництвом по взаємодiї
iнформацiйних	усерединi i за межами компанiї
систем i начальник	Тiльки вони мають повноваження на виступ перед
вiддiлу	представниками преси i зовнiшнiми органiзацiями
iнформацiйних	Гарантують, що реагування на iнцидент
систем	задокументовано i внесено вiдповiднi
	змiни в процедури для недопущення повторення
	подiбних iнцидентiв
Головний юрист	Координує судове переслiдування
	зловмисникiв
	Розглядає i пiдтримує дозвiл
	на спiлкування з пресою i зовнiшнiми
	органiзацiями

визначення й оцiнка iнформацiйних активiв якi активи необхiдно захищати i як їх захищати з урахуванням цiлей i завдань бiзнесу;

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

оцiнка iнформацiйних ризикiв являє собою один iз самих складних етапiв процесу розробки полiтики безпеки. На

Приклади побудови захищених iнформацiйних технологiй

315

Рис. 7.6. Життєвий цикл забезпечення iнформацiйної безпеки органiзацiї

Рис. 7.7. Розходження полiтики, стандартiв i процедур безпеки

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

316

Роздiл 6

стратегiчно важливими клiєнтами й партнерами;

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

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

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

-процедури вiдповiдностi для визначення вiдповiдальностi за виконання вимог полiтики безпеки;

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

-процедури видiлення необхiдних ресурсiв гарантує видiлення необхiдних ресурсiв для вiдповiдностi вимогам полiтики iнформацiйної безпеки;

-управлiння програмою безпеки визначає внутрiшнi процедури для реалiзацiї вимог полiтики.

Приклади побудови захищених iнформацiйних технологiй

317

Рекомендований склад полiтики безпеки. Ключовими аспектами полiтики iнформацiйної безпеки є:

область застосування,

необхiднiсть строгого дотримання полiтики,

основна частина полiтики,

вiдповiдальнiсть,

наслiдки за невiдповiднiсть до вимог полiтики. Iстотними твердженнями полiтики безпеки є наступнi:

компанiя є власником всiх даних i систем;

спiвробiтник зобов’язується не робити копiй даних i програмного забезпечення без одержання вiдповiдного дозволу;

спiвробiтник зобов’язується виконувати вимоги по парольному захистi;

спiвробiтник зобов’язується одержувати доступ до систем й iнформацiї тiльки легальним способом, пiсля авторизацiї;

спiвробiтник пiдтверджує право компанiї здiйснювати монiторинг його дiяльностi.

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

повинен перевищувати двох сторiнок.

Реалiзацiя полiтики досягається використанням стандартiв, процедур, руководств.

Що приймається до уваги? Для ефективностi полiтики безпеки необхiдно, щоб полiтика:

була простою для розумiння,

ґрунтувалася на вимогах бiзнесу,

була реалiзованої,

пiдтримувала баланс мiж безпекою й продуктивнiстю,

була доступна всiм спiвробiтникам для ознайомлення,

не суперечила iншим полiтикам компанiї,

не суперечила вимогам законодавства,

ясно визначала вiдповiдальнiсть спiвробiтникiв за її порушення,

регулярно обновлювалася. Стандарти. Вимоги до стандартiв:

кожен стандарт повинен пiдтримувати виконання мет компанiї, вiдповiдати вимогам iснуючого законодавства й дiючої в компанiї полiтикам;

318

Роздiл 6

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

стандарт не повинен суперечити вимогам полiтики iнформацiйної безпеки.

За основу при розробцi стандартiв компанiя Symantec рекомен-

дує використати стандарт ISO 17799:2005.

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

Елементами процедур безпеки, що рекомендуються, є:

цiль процедури:

-для вiдповiдностi якому стандарту вона розроблена;

-для чого потрiбна процедура;

область дiї процедури:

-до яких систем, мереж, додаткiв, категорiй персоналу, примiщень застосовується процедура;

-яка роль необхiдна для виконання процесу;

-що потрiбно знати для виконання процесу;

визначення процесу:

-введення в процес (опис);

-детальний опис процесу (як, коли, що, критерiї успiху, види звiтiв, взаємодiя з iншими процесами);

-контрольний список процесу;

-проблеми процесу (дiї при виникненнi проблем).

Приклади побудови захищених iнформацiйних технологiй

319

7.6Пiдхiд SANS

7.6.1Опис полiтики безпеки

Органiзацiя SANS виробила свiй пiдхiд у розумiннi полiтики iнформацiйної безпеки i її складових. У термiнологiї SANS полiтика iнформацiйної безпеки багаторiвневий документований план забезпечення iнформацiйної безпеки компанiї:

верхнiй рiвень полiтики;

середнiй рiвень стандарти й керiвництва;

нижчий рiвень процедури.

Далi документи розбиваються на наступнi основнi категорiї:

твердження керiвництва про пiдтримку полiтики iнформацiйної безпеки;

основнi полiтики компанiї;

функцiональнi полiтики;

обов’язковi стандарти (базовi);

рекомендованi керiвництва;

деталiзованi процедури.

Стандарти деталiзують розходження по настроюванню безпеки

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

в’язковi до виконання дiї по попередженню проблем, пов’язаних з рiзними аспектами iнформацiйної безпеки.

Процедури детальнi покроковi iнструкцiї, якi спiвробiтники зобов’язанi неухильно виконувати.

При розробцi полiтик дуже важливим є коректний розподiл ролей й обов’язкiв. Дуже важливо дотримувати принципу найменших привiлеїв, принцип “знати тiльки те, що необхiдно для виконання службових обов’язкiв” i використати подiл обов’язкiв на критичних системах.

Розрiзняють наступнi типи полiтик безпеки:

спрямованi на рiшення конкретної проблеми прикладами таких полiтик можуть служити полiтика по найманню персоналу, полiтика використання паролiв, полiтика використання Iнтернету;

програмнi полiтики високого рiвня, що визначають загаль-

320

Роздiл 6

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

застосовуванi до конкретного середовища наприклад, кожна операцiйна система вимагає окремого стандарту по її настроюванню.

Рекомендованi компоненти полiтики безпеки:

цiль,

область дiї,

твердження полiтики,

iсторiя документа,

необхiднiсть полiтики,

якi полiтики скасовує,

дiї по виконанню полiтики,

вiдповiдальнiсть,

виключення,

порядок i перiодичнiсть перегляду.

Органiзацiя SANS розробила ряд шаблонiв полiтик безпеки:

полiтика припустимого шифрування,

полiтика припустимого використання, посiбник з антивiрусного захисту,

полiтика аудита уразливостей,

полiтика зберiгання електронної пошти,

полiтика використання електронної пошти компанiї,

полiтика використання паролiв,

полiтика оцiнки ризикiв,

полiтика безпеки маршрутизатора ,

полiтика забезпечення безпеки серверiв,

полiтика вiртуальних приватних мереж,

полiтика бездротового доступу в мережу компанiї,

полiтика автоматичного перенаправлення електронної пошти компанiї,

полiтика класифiкацiї iнформацiї,

полiтика вiдносно паролiв для доступу до баз даних,

полiтика безпеки лабораторiї демiлiтаризованої зони,

полiтика безпеки внутрiшньої лабораторiї,

Приклади побудови захищених iнформацiйних технологiй

321

полiтика екстранет,

полiтика етики,

полiтика лабораторiї антивiрусного захисту.

7.6.2 Приклад полiтики аудита безпеки

Мета. Установити правила аудита безпеки iнформацiйних систем компанiї, виконуваного внутрiшнiми аудиторами. З повиннi використати затверджений перелiк засобiв пошуку уразливостей або сканерiв безпеки при виконаннi сканування клiєнтських мереж й/або мiжмережних екранiв або будь-яких iнших компонентiв iнформацiйних систем компанiї.

З може бути проведений для:

гарантiї цiлiсностi, конфiденцiйностi й доступностi iнформацiйних ресурсiв компанiї;

розслiдування можливих iнцидентiв в областi безпеки компанiї;

монiторингу дiяльностi спiвробiтникiв й активностi iнформацiйної системи в цiлому.

Область дiї. Полiтика охоплює все компоненти iнформацiй-

них систем компанiї. Аудитори не будуть проводити атаки класу “вiдмова в обслуговуваннi”.

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

Доступ до iнформацiйної системи включає:

доступ на рiвнi користувача або системний доступ до будьякого встаткування системи;

доступ до даних (в електронному видi, у виглядi паперових копiй i т.д.), якi створюються, передаються й зберiгаються в системi;

доступ у примiщення (лабораторiї, офiси, сервернi й т.д.);

доступ до мережного трафiку.

322

Роздiл 6

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

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

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

Перiод сканування. Компанiя й аудитори повиннi в письмовому видi зафiксувати дати й час проведення аудита безпеки.

Процес оцiнки ризикiв. Процес оцiнки ризикiв описаний у положеннi про оцiнювання й управлiння iнформацiйними ризиками компанiї.

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

Питання та практичнi завдання

1.Аналiз iнформацiйних потокiв та вiдображення їх на вiдповiдних схемах.

2.Визначення моделей загроз.

3.Визначення моделей порушника.

4.Використання методик аналiзу ризикiв.

Додаток А

Загальнi поняття про мережнi протоколи

Iлюстрацiї наведенi вiдповiдно до [58].

А.1 Простi мережнi конфiгурацiї

Для поєднання комп’ютерiв в мережi не завжди достатньо забезпечити їх фiзичне з’єднання та взаємодiю. I якщо успiшне функцiонування простих мережних конфiгурацiй (наприклад, див. рис. А.1) на основi примiтивних протоколiв можливе, для бiльш складних мереж (див. рис. А.2) це є майже неможливим за цiлим перелiком причин. Найбiльш важливими з яких є:

Рис. А.1. Найпростiша мережа – один сегмент (шина, зiрка, кiльце)

забезпечення сумiсностi програмних та апаратних засобiв рiзних виробникiв;

забезпечення масштабованостi та гнучкостi мереж;

створення належного пiдґрунтя для функцiонування комунiкацiйного програмного забезпечення;

323

324 Загальнi поняття про мережнi протоколиА.2. Модель взаємозв’язку вiдкрити

Рис. А.2. Сучасна мережа (розподiленiсть, багато протоколiв)

наявностi рiзних вимог до забезпечення взаємодiї;

рiзних можливостей середовищ передачi даних.

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

Розвиток моделей побудови мереж розвивався двома шляха-

ми:

1)формування та впровадження промислових, галузевих стандартiв;

2)розвиток мiжнародної нормативної бази.

А.2 Модель взаємозв’язку вiдкритих систем

Базова модель опису взаємодiї вiдкритих систем (ВВС). Видiляє 7 рiвнiв взаємодiї. Стислий опис рiвнiв моделi ВВС за [59] (див. рис. А.3, А.4):

Рiвень 1 фiзичний. Цей рiвень пов’язаний з роботою hardware. На ньому визначаються фiзичнi аспекти передавання iнформацiї такi як: напруга, частоти, природа передавального середовища, спосiб передавання двiйкової iнформацiї фiзичним носiєм, аж до розмiрiв та форми роз’ємiв. У комп’ютерах за пiдтримку фiзичного рiвня вiдповiдає мережний адаптер.

Загальнi поняття про мережнi протоколиА.2. Модель взаємозв’язку вiдкритих систем

Рис. А.3. Рiвнi моделi ВВС та зв’язки мiж ними

Рiвень 2 канальний. Цей рiвень вiдповiдає за передавання даних фiзичним рiвнем без спотворень мiж безпосередньо зв’язаними вузлами мережi. На ньому формуються фiзичнi пакети даних для реальної доставки фiзичним рiвнем. Протоколи канального рiвня реалiзуються разом мережними адаптерами та їх драйверами.

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

Рiвень 4 транспортний. Регламентує передавання даних мiж

326 Загальнi поняття про мережнi протоколиА.2. Модель взаємозв’язку вiдкрити

Рис. А.4. Iнформацiйнi потоки обмiну даними (активне мережне обладнання)

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

Рiвень 5 сеансовий. Координує взаємодiю зв’язаних процесiв. Основна задача надання засобiв синхронiзацiї взаємодiючих процесiв. Такi засоби синхронiзацiї дозволяють створювати контрольнi точки при передаваннi великих обсягiв iнформацiї. У випадку збою в роботi мережi передавання даних можна вiдновити

Загальнi поняття про мережнi протоколиА.3. Протокол TCP/IP

327

з останньої контрольної точки, а не розпочинати заново.

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

Рiвень 7 прикладний. Органiзовує iнтерфейс мiж користувачем i мережею. На цьому рiвнi реалiзуються такi сервiси, як вiддалене передавання даних, вiддалений термiнальний доступ. поштова служба в робота у всесвiтнiй паутинi (Web-браузери).

Iдея формування структур даних, якi передаються при функцiонуваннi мережних протоколiв наведена на рис. А.5.

Рис. А.5. Формування структур обмiну даними (кадри, пакети)

А.3 Протокол TCP/IP

Iсторiя створення:

328 Загальнi поняття про мережнi протоколиА.4. Службовi протоколи

мережа передачi даних з пiдвищеними вимогами до надiйностi;

мережа з комутацiєю пакетiв;

робоча, полегшена версiя стеку протоколiв (не всi рiвнi моделi ВВС);

стандарт де факто, Intranet мережi, Milnet.

Iлюстрацiї наведенi на рис. А.6, А.7, А.8, А.9, А.10, А.11, А.12,

А.13, А.14, А.15.

А.4 Службовi протоколи

протоколи канального рiвня (вилучення петель);

протоколи мережного рiвня (формування правил маршрутизацiї).

Рис. А.6. Сучасна структура мереж на основi TCP/IP (мiжмережна взаємодiя, мережна взаємодiя)

Загальнi поняття про мережнi протоколиА.4. Службовi протоколи 329

Рис. А.7. Взаємозв’язок мiж рiвнями ВВС та TCP/IP

330 Загальнi поняття про мережнi протоколиА.4. Службовi протоколи

Рис. А.8. Розмiщення стеку протоколiв TCP/IP за рiвнями моделi ВВС

Загальнi поняття про мережнi протоколиА.4. Службовi протоколи 331

Рис. А.9. Елементи iнформацiйних потокiв в мережi

332 Загальнi поняття про мережнi протоколиА.4. Службовi протоколи

Рис. А.10. Базовi елементи стеку протоколiв TCP/IP

Рис. А.11. Заголовок IP-пакету

Рис. А.12. Опцiї заголовку IP-пакету

Загальнi поняття про мережнi протоколиА.4. Службовi протоколи 333

Рис. А.13. Адресацiя вузлiв мережi

Рис. А.14. Спецiальнi адреси

Рис. А.15. Деталiзацiя пiдмереж

ПРЕДМЕТНИЙ ПОКАЖЧИК

АНАЛIЗ даних, 14

iнформацiї, 14

АРХIТЕКТУРА автоматизованої системи, 13

обчислювальної системи, 13

ВАЛIДАЦIЯ, 15

ВАРТIСТЬ

експлуатацiї системи захисту, 42 створення системи захисту, 42

ВЕРИФIКАЦIЯ, 15 ВИПРОБУВАННЯ, 8

ДОКУМЕНТ проектний, 14

ДОКУМЕНТАЦIЯ на систему, 14 приймальна, 15

ДОСЛIДЖЕННЯ спецiальнi, 15

ЗАСIБ

захисту iнформацiї, 27

КАНАЛ зв’язку, 12

КОМУТАТОР, 12

МАРШРУТИЗАТОР, 12

МАШИНА електронно-обчислювальна, 11

МЕРЕЖА комп’ютерна, 8

МIСЦЕ

робоче автоматизоване, 11

ОБРОБКА iнфомрацiї, 13

ПЕРЕВIРКА правильностi, 15

спецiальна, 15 ПIДТРИМКА

системи, 8 ПРИНЦИП

створення систем захисту, 42

ПРОЕКТУВАННЯ автоматизоване, 15

автоматичне, 15

системи, 8 концептуальне, 14 функцiйне, 14

РЕАЛIЗАЦIЯ системи, 8

РIШЕННЯ проектне, 14

типове, 14

РОЗРОБЛЕННЯ системи, 8

СЕРВЕР, 12

СИСТЕМА

захисту iнформацiї комплексна, 9

комп’ютерна, 8 СПЕЦИФIКАЦIЯ

формальна, 14

СТРУКТУРА автоматизованої системи, 13

ТЕХНОЛОГIЯ, 9

забезпечення iнформацiйної безпеки, 9

iнформацiйна, 13 типова, 11

Технологiя, 9

ФУНКЦIОНУВАННЯ системи, 8

ЦИКЛ життєвий, 8

автоматизованой системи, 8

ШЛЮЗ, 12

334

ЛIТЕРАТУРА

1.Теоретические основы компьютерной безопасности: Учеб. пособие для вузов / П. Н. Девянин, О. О. Михальский, Д. И. Правиков и др. М.: Радио и связь, 2000. 192 с.

2.Проскурин В. Г., Крутов С. В., Мацкевич И. В. Защита в операционных системах: Учеб. пособие для вузов. М.: Радио и связь, 2000. 168 с.

3.Тарасюк М. В. Защищенные информационные технологии. Проектирование и применение. М.: СОЛОН-Пресс, 2004. 192 с.

4.Петренко С. А., Курбатов В. А. Политики информационной безопасности. М.: Компания АйТи, 2006. 400 с.

5.Щербаков А. Ю. Введение в теорию и практику компьютерной безопасности. М.: издатель Молгачева С.В., 2001. 352 с.

6.Зима В. М., Молдовян А. А., Молдовян Н. А. Безопасность

глобальных сетевых	технологий. СПб.: БХВ-Петербург,
2000. 320 с.
7. Программирование	алгоритмов защиты информации /

А. В. Домашев, В. О. Попов, Д. И. Правиков и др. М.: Нолидж, 2000. 288 с.

8.Щеглов А. Ю. Защита компьютерной информации от несанкционированного доступа. СПб.: Наука и Техника, 2004. 384 с.

9.Зегжда Д.П., Ивашко А.П. Основы безопасности информационных систем. М.: Горячая линия – Телеком, 2000. 452 с.

335

336						Лiтература
10. Neumann	P.	G.	Practical Architectures		for	Survivable
Systems	and	Networks.		Techical Report.	SRI Interna-
tional: Computer			Science	Laboratory, 2001.		209 pp.
(http://www.csl.sri.com/neumann/survivability.dvi).

11.ДСТУ 2938-94 Системи оброблення нформацiї. Основнi поняття. Термiни та визначення. Чинний вiд 01.01.1996 р. К.: ДержСтандарт України, 1994. 32 с.

12.ДСТУ 2941-94 Системи оброблення нформацiї. Розроблення систем. Термiни та визначення. Чинний вiд 28.11.1994 р. К.: ДержСтандарт України, 1994. 19 с.

13.Ефремова Т. Ф. Большой современный толковый словарь русского языка. М.

14.ДСТУ 2296-93 Аатоматизованi системи. Термiни та визначення. Чинний вiд 01.07.1994 р. К.: ДержСтандарт України, 1994. 92 с.

15.НД ТЗI 3.7-003-05. Нормативний документ. Системи технiчно-

го захисту iнформацiї. Порядок проведення робiт iз створення комплексної системи захисту iнформацiї в iнформацiйнотелекомунiкацiйнiй системi. К.: ДСТСЗI СБ України, 2005. 10 с.

16.ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. Введ. 01.01.92. М.: Изд-во стандартов, 1992. 20 с.

17.ДСТУ 3396.0-96 Захист iнформацiї. Технiчний захист iнформацiї. Основнi положення. Чинний вiд 01.07.1997 р. К.: ДержСтандарт України, 1997. 7 с.

18.ДСТУ 3396.1-96 Захист iнформацiї. Технiчний захист iнформацiї. Порядок проведення робiт. Чинний вiд 01.07.1997 р. К.: ДержСтандарт України, 1997. 7 с.

19.НД ТЗИ 1.1-002-99. Нормативный документ. Системы технической защиты информации. Общие положения по защите ин-

Лiтература

337

формации в компьютерных системах от несанкционированного доступа. К.: ДСТСЗI СБ України, 1999. 18 с.

20.НД ТЗI 1.4-001-2000. Нормативний документ. Системи технiчного захисту iнформации. Типове положення про службу захисту iнформацiї в автоматизованiй системi. К.: ДСТСЗI СБ України, 1999. 26 с.

21.НД ТЗI 3.7-001-99. Нормативний документ. Системи технiчного захисту iнформацiї. Методичнi вказiвки щодо розробки технiчного завдання на створення комплексної системи захисту iнформацiї в автоматизованiй системi. К.: ДСТСЗI СБ України, 1999. 10 с.

22.НД ТЗИ 2.5-004-99. Нормативный документ. Системи технiчного захисту iнформации. Критерiї оцiнки захищенности iнформацiї в комп’ютерних системах вiд несанкцiонованого доступу. К.: Державний комiтет України з питань державної таємницi та технiчного захисту iнформацiї, 1999. 45 с.

23.НД ТЗИ 2.5-005-99. Нормативний документ. Системи технiчного захисту iнформацiї. Класифiкацiя автоматизованих систем i стандартнi функцiональнi профiлi захищеностi оброблюваної iнформацiї вiд несанкцiонованого доступу. К.: Державний комiтет України з питань державної таємницi та технiчного захисту iнформацiї, 1999. 16 с.

24.НД ТЗИ 3.6-001-2000. Нормативний документ. Системи технiчного захисту iнформацiї. Технiчний захист iнформацiї. Ком- п’ютернi системи. Порядок створення, впровадження, супроводження та модернiзацiї засобiв технiчного захисту iнформацiї вiд несанкцiонованого доступу. К.: ДСТСЗI СБ України, 2000. 5 с.

25.Защита информации в персональных ЭВМ / А. В. Спесивцев, В. А. Вегнер, А. Ю. Крутяков и др. М.: Радио и связь, МП ”Веста”, 1992. 192 с.

338	Лiтература

26.ISO IEC 15408-1 – Information technology – Security techniques

Evaluation criteria for IT security Part 1: Introduction and general model. Geneva: ISO, 2001. 48 pp.

27.ISO IEC 17799:2000. Information techniques – Security techniques

Code of practice for information security management. Geneva: ISO, 2002. 71 pp.

28.ISO IEC 21001:2007. Information techniques – Security techniques

Information security management systems – Requirements. Geneva: ISO, 2007. 43 pp.

29.BS7799-2:2002. British Standard. Information security management systems – Specification with guidance for use. UK.: BSI, 2000. 125 pp.

30.Орлов С. А. Технологии разработки програмного обеспечения. СПб.: Питер, 2002. 464 с.

31.ISO 15408. Common Criteria for Information Technology Security Evaluation. Version 2.1, August, 1999.

32.Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. 2-е, переработ. и доп. изд. М.: Финансы и статистика, 2006. 544 с.

33.Одинцов И. О. Профессиональное программирование. Системный подход. СПб.: БХВ-Петербург, 2002. 512 с.

34.Иванова Г. С. Технологии программирования. М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. 320 с.

35.Благодатских В. А., Волнин В. А., Поскакалов К. Ф. Cтандартизация разработки программных средств / Под ред. О. С. Разумова. М.: Финансы и статистика, 2005. 288 с.

36.Якобсон А., Буч Г., Рамво Д. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, 2002. 496 с.

Лiтература

339

37.Липаев В. В. Системное проектирование программных средств, обеспечивающих безопасность функционирования информационных систем // Информационные технологии. 2000. № 11. С. 49–55.

38.Дунаев С. Б. Технологии Интернет-программирования. СПб.: БХВ-Петербург, 2001. 480 с.

39.Курило А. П., Зефиров С. Л., Голованов В. Б. Аудит информационной безопасности. М.: Изд-кая група ”БДЦ-пресс”, 2006. 304 с.

40.Лукацкий А. В. Обнаружение атак. 8-e, перераб. и доп. изд. СПб.: БХВ-Петербург, 2003. 608 с.

41.Галицкий А. Ф., Рябко С. Д., Шаньгин В. Ф. Защита информации в сети – анализ технологий и синтез решений. М.: ДМК Пресс, 2004. 616 с.

42.Петренко С. А., Симонов С. В. Управление информационными рисками. М.: Компания АйТи, 2004. 384 с.

43.Информационная безопасность открытых систем: В 2 т. /

С. В. Запечников, Н. Г. Милославская, А. И. Толстой, Д. В. Ушаков. М.: Горячая линия – Телеком, 2006. Т. 1

– Угрозы, уязвимости, атаки и подходы к защите. 536 с.

44.Платонов В. В. Программно-аппаратные средства обеспечения информационной безопасности вычислительных сетей. М.: Изд-й центр ”Академия”, 2006. 240 с.

45.Петров М. И. Безопасность и персонал. М.: ООО Журанал ”Управление персоналом”, 2006. 227 с.

46.Медведовский И. Д., Семьянов П. В., Леонов Д. Г. Атака на Internet. М.:: ДМК, 1999.

47.Toward a secure system engineering methodology / C. Salter, O. Saydjari, B. Schneier, J. Wallner.

340	Лiтература

48.Симонов С. В. Анализ рисков в информационных системах. практические аспекты // Защита информации. Конфидент. 2001. № 2. С. 48–53.

49.Герасименко В. А. Защита информации в автоматизированных системах обработки данных. Книга 1. М.: Энегоатомиздат, 1994. 123 с.

50.Гайкович В., Першин А. Безопасность электронных банковских систем. М.: Единая Европа, 1994. 324 с.

51.Лукацкий А. В. Обнаружение атак. СПб.: БХВ-Петербург, 2001. 624 с.

52.Бармен С. Разработка правил информационной безопасности. М.: Изд-кий дом "Вильямс 2002. 208 с.

53.RFC 1244 Site Security Handbook.

54.ISO/IEC 7498-2. Information processing systems – Open Systems Interconnection – Basic Reference Model – Part 2: Security Architecture. Switzeland, 1989. 32 pp.

55.Домарев В. В. Безопасность информационных технологий. Методология создания систем защиты. К.: ООО ТИД ”Д- С”, 2001. 688 с.

56.Романец Ю. В., Тимофеев П. А., Шаньгин В. А. Защита информации в компьютерных системах и сетях / Под ред. В. Ф. Шаньгина. 2-е, перераб. и доп. изд. М.: Радио и связь, 2001. 376 с.

57.Биячуев Т. Безопасность корпоративных сетей / Под ред. Л. Г. Осовецкого. СПб.: СПб ГУ ИТМО, 2004. 161 с.

58.Tanenbaum A. S. Computer Networks. NY.: Prentice Hall, 1996.

59.Олифер В. Г., Олифер Н. А. Компьютерные сети. СПб.: Питер, 2001. 800 с.

НАВЧАЛЬНЕ ВИДАННЯ

Богуш Володимир Михайлович Довидьков Олексiй Анатолiйович

Проектування захищених комп’ютерних систем та мереж

Навчальний посiбник

Редактор А.М. Кудiн Технiчний редактор О.Ю. Найда Коректор О.А. Довидькова

Пiдписано до друку . .2008 р. Формат 60 90/16, папiр типограф. Друк офсетний. Ум. фарбовiдб. 8. Ум. друк. арк. 7,86.

Обл.-вид. арк. . Наклад 500 прим. Замовлення /–

Видавництво ДУIКТ 03110, Київ, вул. Солом’янська, 7.

Надруковано “Видавництво ДУIКТ” 03110, Київ, вул. Солом’янська, 7