7.3. Оцінка ризику

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

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

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

1. Визначення об'єкта захисту (цінностей).

2. Виявлення загроз.

3. Оцінка ймовірностей появи загроз.

4. Оцінка очікуваних розмірів втрат.

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

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

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

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

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

1. Обладнання: системні блоки, плани розширення, клавіатури, термінали, робочі станції, окремі персональні комп'ютери, принтери, дискові накопичувачі, комунікаційне обладнання, термінальні сервери, маршрутизатори.

2. Програмне забезпечення: вихідні тексти програм, об'єктні модулі, утиліти, діагностичні програми, операційні системи, комунікаційні системи.

3. Дані: під час виконання, збережені при оперативному використанні, архівовані, журнали дій, бази даних, при передачі по каналах зв'язку.

4. Люди: користувачі, обслуговуючий персонал, необхідний для забезпечення функціонування АС.

5. Документація: по програмах, по ЗОТ, по АС, по адміністративних заходах безпеки.

6. Видаткові матеріали: папір, фарбуючі стрічки, магнітні стрічки.

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

Несанкціонований доступ

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

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

Розкриття інформації

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

Відмова в обслуговуванні

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

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

Існує ряд проблем, які потрібно вирішити при розробці ПРД. Ось вони:

1. Що робити з конфіденційною інформацією?

2. Кому дозволено використовувати ресурси?

3. Що таке правильне використання ресурсів?

4. Хто відповідає за надання доступу і надійність надання послуг?

5. Хто може мати привілеї системного адміністратора?

6. Які права і обов'язки користувачів?

7. Які права і обов'язки системного адміністратора стосовно користувачів?

Ці проблеми розглядаються нижче. Крім того, можна включити в ПРД розділ, пов'язаний з етикою використання ЗОТ і АС.

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

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

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

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

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

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

• одержання доступу до інформації про користувачів

• розкриття чужих паролів;

• руйнування служб мережі;

• перегляд усіх доступних по читанню файлів на мережевих пристроях;

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

• використання того самого реєстраційного імені і пароля.

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

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

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

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

• фразу "Коли у вас виникли сумніви, НЕ КОПІЮЙТЕ".

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

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

Що варто відобразити в цій частині ПРД:

• чи можна це робити взагалі;

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

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

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

• процес отримання дозволу на проведення цих тестів.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• що може вважатися зловживанням з погляду продуктивності АС;

• чи дозволяється декільком користувачам використовувати одне реєстраційне ім'я чи дозволяти іншим використовувати їх імена;

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

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

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

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

• пункт про безпеку електронної пошти;

• політика стосовно електронних комунікацій.

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

Пропонується п'ять критеріїв для оцінки будь-якої політики:

1. Чи погоджується політика з законами і вимогами громадських організацій?

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

3. Чи діє політика в житті і чи вимагається її дотримання?

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

5. Чи була ця політика відома заздалегідь і погоджена з усіма зацікавленими особами?

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

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

• які при цьому його зобов'язання;

• чи мають право мережеві адміністратори переглядати графік мережі чи конкретної ЕОМ?