1. Листи можливостей: для кожного суб'єкта створюється лист (файл) усіх об'єктів, до яких має доступ даний суб'єкт;

2. Листи контролю доступу: для кожного об'єкта створюється список усіх суб'єктів, що мають доступи до цього об'єкта;

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

Наведемо найбільш суттєві вади ДПБ:

1. Один з найбільших недоліків цього классу політик ─ вони не витримують атак за допомогою «Троянського коня».

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

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

4. При використанні ДПБ виникає питання визначення правил поширення прав доступу й аналізу їх впливу на безпеку АС. У загальному випадку при використанні ДПБ органом, який її реалізує і який при санкціонуванні доступу суб'єкта до об'єкта керується певним набором правил, стоїть задача, яку алгоритмічно неможливо розв'язати: перевірити, призведуть його дії до порушень безпеки чи ні.

Мандатна політика

Основу мандатної (повноважної) політики безпеки (МПБ) становить мандатне управління доступом (Mandatory Access Control - МАС), яке передбачає, що:

─ всі суб'єкти й об'єкти повинні бути однозначно ідентифіковані;

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

─ кожному об'єкту системи надано мітку секретності, яка визначає цінність інформації, що міститься в ньому, ─ його рівень секретності в АС;

─ кожному суб'єкту системи надано мітку секретності, яка визначає рівень довіри до нього в АС,- максимальне значення мітки секретності об'єктів, до яких суб'єкт має доступ; мітка секретності суб'єкта називається його рівнем доступу.

Основна мета МПБ ─ запобігання витоку інформації від об'єктів з високим рівнем доступу до об'єктів з низьким рівнем доступу, тобто протидія виникненню в КС інформаційних каналів згори вниз.

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

Наведемо ряд переваг МПБ порівняно з ДПБ:

1. Для систем, де реалізовано МПБ, є характерним вищий ступінь надійності. Це пов'язано з тим, що за правилами МПБ відстежуються не тільки правила доступу суб'єктів системи до об'єктів, а й стан самої КС.

2. Правила МПБ ясніші і простіші для розуміння розробниками і користувачами АС, що також є фактором, який позитивно впливає на рівень безпеки системи;

3. МПБ стійка до атак типу «Троянський кінь»;

4. МПБ допускає можливість точного математичного доведення, що система в заданих умовах підтримує ПБ.

Однак МПБ має дуже серйозні вади – вона дуже складна для практичної реалізації і вимагає значних ресурсів КС. Це пов'язано з тим, що інформаційних потоків у системі величезна кількість і їх не завжди можна ідентифікувати. Сааме ці вади часто заважають її практичному використанню.

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

Рольова політика безпеки

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

У РПБ класичне поняття «суб'єкт» заміщується поняттями «користувач» і «роль».

Користувач ─ це людина, яка працює з системою і виконує певні службові обов'язки.

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

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

Тому цілком логічно здійснювати керування доступом і призначати повноваження не реальним користувачам, а абстрактним (не персоніфікованим) ролям, які представляють учасників певного процесу обробки інформації. Такий підхід до ПБ дозволяє врахувати розподіл обов' язків і повноважень між учасниками прикладного інформаційного процесу. Крім того, кількість ролей у системі може не відповідати кількості реальних користувачів ─ один користувач, якщо він має різні повноваження, може виконувати (водночас або послідовно) кілька ролей, а кілька користувачів можуть користуватися однією й тією ж роллю, якщо вони виконують однакову роботу. При використанні РПБ керування доступом здійснюється в дві стадії: по-перше, для кожної ролі вказується набір повноважень, що представляють набір прав доступу до об'єктів, і, по-друге, кожному користувачеві призначається список доступних йому ролей. Як критерій безпеки рольової моделі використовується правило: «система вважається безпечною, якщо будь-який користувач системи, що працює в певному сеансі, може здійснити дії, які вимагають певних повноважень тільки в тому випадку, коли ці повноваження належать сукупності повноважень усіх ролей, що беруть участь у цьому сеансі».

11. Як здійснюється керування доступом при рольовій політиці безпеки?

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

У РПБ класичне поняття «суб'єкт» заміщується поняттями «користувач» і «роль».

Користувач ─ це людина, яка працює з системою і виконує певні службові обов'язки.

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

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

Справді, по суті, користувачі, що працюють у системі, діють не від свого власного імені ─ вони завжди виконують певні службові обов'язки, тобто виконують деякі ролі, які аж ніяк не пов'язані з їх особистістю. Тому цілком логічно здійснювати керування доступом і призначати повноваження не реальним користувачам, а абстрактним (не персоніфікованим) ролям, які представляють учасників певного процесу обробки інформації. Такий підхід до ПБ дозволяє врахувати розподіл обов' язків і повноважень між учасниками прикладного інформаційного процесу, оскільки з точки зору РПБ має значення не особистість користувача, користувача, що здійснює доступ до інформації, а те, які повноваження йому необхідні для виконання його службових обов'язків.

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

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

16. Дати визначення та класифікацію інформаційних ресурсів. Властивості інформації. Інформаці́йні ресу́рси — документи і масиви документів в інформаційних системах (бібліотеках, архівах, фондах, банках даних, депозитаріях, музейних сховищах і т.і.). Розрізняють інформаційні ресурси державні та недержавні. Види інформаційних ресурсів:

-Новинні стрічки (online-новини).

-Підписки на електронні копії періодичних видань. Деякі газети і журнали випускають свої повні електронні копії і надають до них доступ.

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

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

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

---Інформаційні ресурси обмеженого використання, до яких відносяться, наприклад, програми класу shareware (Trumpet Winsock, Atis Mail, Netscape, і т.п.). В даний клас можуть входити ресурси обмеженого часу використання або обмеженого часу дії, тобто користувач може використовувати поточну версію на свій страх і ризик, але ніхто не буде надавати йому підтримку.

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

Об'єктивність - не залежить від чого-небудь думки

Достовірність - відбиває справжній стан справ

Повнота - Достатня для розуміння і прийняття рішення

Актуальність - важлива і істотна для теперішнього часу

Цінність (корисність, значущість) - забезпечує вирішення поставленого завдання, потрібна для того, щоб приймати правильні рішення

Зрозумілість (ясність) - виражена мовою, доступному одержувачу

17. Етапи функціонування системи управління інформаційною безпекою. Система управління інформаційною безпекою СУІБ— частина загальної системи управління, яка ґрунтується на підході, що враховує бізнес-ризики, призначена для розроблення, впровадження, функціонування, моніторингу, перегляду, підтримування та вдосконалення інформаційної безпеки. У відповідності з вимогами ISO/IEC 27001 система управління інформаційної безпеки повинна містити такі етапи [1,2] :

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

2 етап - дія - етап реалізації та впровадження відповідних заходів;

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

4 етап - удосконалення - виконання коригувальних дій по покращенню функціонуванню системи;

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

18. Основні функції та призначення системи управління інформаційною безпекою. Система управління інформаційною безпекою СУІБ — частина загальної системи управління, яка ґрунтується на підході, що враховує бізнес-ризики, призначена для розроблення, впровадження, функціонування, моніторингу, перегляду, підтримування та вдосконалення інформаційної безпеки. В загальному випадку система управління безпекою повинна включати :

- аутентифікацію (користувачів, даних, додатків, послуг, тощо);

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

- аудит інформаційних ресурсів та послуг. Система управління інформаційною безпекою на основі стандарту ISO 27001 дозволяє:

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

- виявляти основні загрози безпеки для існуючих бізнес-процесів;

- розраховувати ризики і приймати рішення на основі бізнес цілей компанії;

- забезпечити ефективне управління системою в критичних ситуаціях;

- проводити процес виконання політики безпеки (знаходити і виправляти слабкі місця в системі інформаційної безпеки);

- досягти зниження і оптимізації вартості підтримки системи безпеки;

- полегшити інтеграцію підсистеми безпеки в бізнес-процеси і інтеграцію з ISO 9001:2000;

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

- отримати міжнародне визнання і підвищення авторитету компанії, як на внутрішньому ринку, так і на зовнішніх ринках;

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

22. Назвіть ключові елементи управління інформаційною безпекою.

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

1. Інфраструктура безпеки інформації організації (Internal organization). Для забезпечення захисту інформації слід створити відповідну структуру управління в організації. Необхідно проводити регулярні наради керівництва, присвячені коригуванню політики безпеки інформації, розподілу обов'язків із забезпечення захисту та координації дій, спрямованих на підтримку режиму безпеки. За потреби для консультацій слід залучити фахівців відповідного рівня. З метою обміну досвідом необхідно встановлювати контакти з фахівцями інших організацій. Слід всебічно впроваджувати комплексний підхід до розв'язання проблем безпеки інформації.

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

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

В загальному випадку система управління безпекою повинна включати:

- аутентифікацію (користувачів, даних, додатків, послуг, тощо);

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

- аудит інформаційних ресурсів та послуг.

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

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

23. Розробка та впровадження системи управління інформаційною безпекою. У відповідності з вимогами стандарту система управління інформаційної безпеки повинна містити такі етапи:

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

2 етап - дія - етап реалізації та впровадження відповідних заходів;

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

4 етап - удосконалення - виконання коригувальних дій по покращенню функціонуванню системи;

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

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

24. Керування ризиками. Оцінка та мінімізація ризиків. Керування ризиками: Метою процесу керування ризиками ІБ є виявлення, контроль та мінімізація невизначеності впливу ЧД. Виділимо чотири основні етапи управління ризиками ІБ, яке здійснюється з метою забезпечення неперервності функціонування КМЗ, зокрема підсистеми СЗІ:

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

2. Оцінка ризику. Є процесом визначення рівня ризику. Ризик традиційно обчислюватимемо як функцію важливості активів, ймовірності виникнення загрози і наявності вразливостей, величини завданого збитку.

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

4. Оцінка вразливостей та контролів. Аналіз основних властивостей КМЗ та виявлення тих, які можна використати з метою реалізації загрози порушення властивості живучості, а також визначення ефективності та адекватності заходів ІБ та виявлення недоліків в її реалізації.

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

Мінімізація ризиків.

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

25. Основні етапи процесу керування ризиками.

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

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

Загальне оглядання керування ризиком

Керування ризиком складається з чотирьох різних дій:

— визначання загальної стратегії керування ризиком згідно з корпоративною методологією керування безпекою ІТ;

— вибирання засобів захисту для конкретної системи ІТ згідно з аналізуванням ризику або у відповідності з концепцією керування ризиком;

— розробляння методик захисту системи ІТ, виходячи з рекомендацій безпеки, і за потреби, модифікація корпоративних методологій захисту ІТ (і відповідних відомчих методик захисту ІТ);

— розробляння проектів безпеки ІТ щодо застосування засобів захисту на основі схвалених методик захисту системи ІТ.

25. Профілі захисту інформації, їх класифікація.

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