Призначення і загальна класифікація засобів захисту інформації від НСД.

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

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

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

Деякі (далеко не повний список) недоліки механізмів захисту ОС Windows:

1. Реалізований дискреційний принцип контролю доступу до файлових об'єктів, що припускає, що

користувач, що створив файловий об'єкт(стає його " власником") може надати доступ до цього об'єкту іншим користувачам.

2. Ряд файлових об'єктів не розділяється ОС(наприклад, тека All Users) і додатками між користувачами.

3. Буфер обміну не розділяється ОС між користувачами у разі запуску програми з правами іншого користувача(після його аутентифікації) з провідника(утиліта runas.exe).

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

5. Відсутність розмежувань прав доступу для суб'єкта " процес"(доступ розмежовується тільки для користувачів), що не дозволяє локалізувати середовище виконання для окремих додатків.

6. І так далі

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

Проілюструємо сказане. Один і той же користувач повинен обробляти відкриту і конфіденційну інформацію на комп'ютері. Наприклад, працювати з мережею Інтернет, зберігати відкриті дані на мобільні накопичувачі і так далі. Обробка конфіденційної інформації повинна жорстко регламентуватися (наприклад, зберігатися тільки на файл-сервері), повинна запобігати будь-яка можливість її винесення. Оскільки в ОС Windows існує можливість розмежувати права доступу тільки між користувачами (немає розмежувань для процесів), то це завдання можна спробувати вирішити тільки одним способом - створити два облікових записи, один для обробки відкритих даних, інший для обробки конфіденційних даних, і відповідним чином розмежувати права доступу для цих облікових записів до ресурів. Завдання може бути вирішене коректно тільки у разі, якщо з правами користувача, допущеного до обробки відкритих даних, неможливо отримати доступ до конфіденційної інформації. Це засобами ОС Windows не вирішити (див. недоліки п.1 - п.4). Неможливо і запобігти розкраданню даних з використанням мобільних накопичувачів (див. недолік п.5).

У частині протидії зовнішнім ИТ-угрозам. Призначення механізмів захисту: протидіяти запуску несанкціонованих(сторонніх) програм(у тому числі, трояны, черв'яки, шпигунські програми), протидіяти атакам на критичні процеси(передусім, мережеві служби, найбільш схильні до атак), протидіяти атакам на скомпрометовані процеси(процеси, в яких виявлена помилка до моменту її виправлення розробником ОС, що може зажадати місяці, а то і роки), протидіяти атакам на сервіси уособлення, атакам на системні ресурси і так далі.

Деякі (далеко не повний список) недоліки механізмів захисту. ОС Windows:

1. Реалізований дискреційний принцип контролю доступу до файлових об'єктів, що припускає, що користувач, що створив файловий об'єкт(стає його " власником") може надати доступ до цього об'єкту іншим користувачам.

2. Ряд файлових об'єктів не розділяється ОС(наприклад, тека All Users) і додатками між користувачами.

3. Буфер обміну не розділяється ОС між користувачами у разі запуску програми з правами іншого користувача(після його аутентифікації) з провідника(утиліта runas.exe).

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

5. Відсутність розмежувань прав доступу для суб'єкта " процес" (доступ розмежовується тільки для користувачів), що не дозволяє локалізувати середовище виконання для окремих застосувань.

6. І так далі

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

Проілюструємо сказане. Один і той же користувач повинен обробляти відкриту і конфіденційну інформацію на комп'ютері. Наприклад, працювати з мережею Інтернет, зберігати відкриті дані на мобільні накопичувачі і так далі. Обробка конфіденційної інформації повинна жорстко регламентуватися(наприклад, зберігатися тільки на файл-сервере), повинна запобігати будь-яка можливість її винесення. Оскільки в ОС Windows існує можливість розмежувати права доступу тільки між користувачами(немає розмежувань для процесів), то це завдання можна спробувати вирішити тільки одним способом - створити два облікові записи, одну для обробки відкритих даних, іншу для обробки конфіденційних даних, і відповідним чином розмежувати права доступу для цих облікових записів до ресурсів. Завдання може бути вирішене коректно тільки у разі, якщо з правами користувача, допущеного до обробки відкритих даних, неможливо отримати доступ до конфіденційної інформації. Це засобами ОС Windows не вирішити(див. недоліки п.1 - п.4). Неможливо і запобігти розкраданню даних з використанням мобільних накопичувачів(див. недолік п.5).

У частині протидії зовнішнім ИТ-угрозам. Призначення механізмів захисту: протидіяти запуску несанкціонованих (сторонніх) програм(у тому числі, трояни, черв'яки, шпигунські програми), протидіяти атакам на критичні процеси(передусім, мережеві служби, найбільш схильні до атак), протидіяти атакам на скомпрометовані процеси(процеси, в яких виявлена помилка до моменту її виправлення розробником ОС, що може зажадати місяці, а то і роки), протидіяти атакам на сервіси

уособлення, атакам на системні ресурси і так далі

Деякі (далеко не повний список) недоліки механізмів захисту ОС Windows:

1. Неможливість розмежувати в повному об'ємі права доступу для користувача System. При цьому ОС надає сервіс запуску додатків(як правило, клієнт-серверних) з системними правами. Помилка в подібному застосуванні призводить до отримання зловмисником прав System, тобто можливості повного управління комп'ютером, що захищається.

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

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

4. І так далі.

З урахуванням сказаного можемо зробити висновок, що і в частині протидії зовнішнім ІТ-загрозам механізми захисту ОС Windows практично даремні, оскільки система не забезпечує (або забезпечує лише частково) захист сервісів, що надаються нею.

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

Питання оцінки ефективності засобу захисту інформації. Ефективність СЗІ від НСД(як, втім, практично будь-якої складної технічної системи) можна оцінити, дослідивши питання коректності реалізації механізмів захисту і достатності (повнота) набору механізмів захисту, стосовно практичних умов її використання.

Оцінка коректності реалізації механізмів захисту. На перший погляд, здавалося б, оцінку коректності реалізації механізмів захисту СЗІ від НСД провести не складно.

У NTFS файловий об'єкт може бути ідентифікований різними способами:

- Файлові об'єкти, що задаються довгими іменами, характеризуються тією відмітною особливістю, що до них можна звертатися, як по довгому, так і по короткому імені, наприклад до каталогу "\Program files\" можна звернутися по короткому імені "\Progra~1\";

- Файлові об'єкти, що задаються російськими (або в іншому кодуванні) буквами, також мають коротке ім'я, яке формується з використанням кодування Unicode(зовні вони можуть істотно розрізнятися), наприклад, коротке ім'я для каталогу "C:\Documents and Settings\USER1\Головне меню" виглядає як "C:\Docume~1\USER1\5D29~1\". До цих об'єктів також можна звернутися, як по довгому, так і по короткому імені;

- Файловий об'єкт ідентифікується не лише ім'ям, але і своїм ідентифікатором(ID) - індекс об'єкту в таблиці MFT причому деякі програми звертаються до файлових об'єктів не по імені, а саме по ID. Нехай встановлена у Вашій інформаційній системі засіб захисту інформації не перехоплює і не аналізує лише один подібний спосіб звернення до файлового об'єкту, і, за великим рахунком, вона стає повністю даремною(рано чи пізно, зловмисник виявить цей недолік засобу захисту і скористається ним). Звідси отримуємо вимогу до коректності реалізації СЗІ від НСД - повинен контролювати доступ до ресурсу при будь-якому способі звернення до ресурсу(ідентифікації ресурсу).

Декілька інших прикладів.

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

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

Вимога до коректності реалізації - СЗІ від НСД повинна розділяти буфер обміну (між користувачами, процесами, категоріями (залежно від розмежувань). А ось приклад абсолютно іншого характеру, що стосується питань коректності реалізації механізму гарантованого видалення залишкової інформації (яка, помітимо, повинна здійснюватися не лише при видаленні, але і при модифікації - зменшенні довжини, файлу, що вже реалізується далеко не усіма СЗІ від НСД, а це робить цей механізм захисту даремним). У NTFS усі дані, що зберігаються на томі, містяться у файлах. Головна таблиця файлів (MFT) займає центральне місце в структурі NTFS- тому. MFT реалізована, як масив записів про файли, де кожен запис є сукупністю пар атрибутів і їх значень. Розмір кожного запису фіксований і дорівнює 1 Кб. Якщо розмір файлу досить малий, щоб поміститися в тілі запису, то дані такого файлу зберігаються безпосередньо в MFT. В процесі роботи системи, NTFS веде запис у файл метаданих - файл журналу з ім'ям $LogFile. NTFS використовує його для реєстрації усіх операцій, що впливають на структуру тому NTFS, як те: створення файлу, видалення файлу, розширення файлу, урізування файлу, установка файлової інформації, перейменування файлу і зміна прав доступу до файлу. Інформація, що описує подібні транзакції, включає копії записів з MFT і надалі використовується для повтору або відміни змін. Відповідно, якщо дані файлу містяться в записі MFT, то при кожній зміні, дані файлу будуть(у числі іншого) скопійовані у файл журналу

Вимога до

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

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

Виникає питання, чи відбиті ці вимоги в нормативних документах і в якому виді? Чи досить їх для оцінки коректності реалізації механізмів захисту в СЗІ від НСД?

З усією упевненістю можемо стверджувати, що ці вимоги в нормативних документах багато в чому є присутніми. Для ілюстрації сказаного приведемо лише деякі з них, і дамо до них відповідні коментарі: "Контроль доступу має бути застосований до кожного об'єкту і кожного суб'єкта(індивідові або групі рівноправних індивідів) " (це питання файлових об'єктів, що не розділяються, заборони доступу користувачеві System до системного диску на запис і так далі), "КСЗ повинен вимагати від користувачів ідентифікувати себе при запитах на доступ. КСЗ повинен піддавати перевірці достовірність ідентифікації - здійснювати аутентифікацію"(це питання контролю сервісів уособлення) і так далі. Зверніть увагу на наші коментарі в дужках, вони абсолютно не очевидні і виходять з архітектурних особливостей побудови сучасних універсальних ОС. Що ж ми маємо? Вимоги є, вони коректні, але сформульовані в загальному вигляді(а як інакше, інакше потрібно було б створювати свій нормативний документ під кожне сімейство ОС, а можливо, і під кожну реалізацію ОС одного сімейства). При цьому вимоги носять настільки загальний характер, що для виконання однієї вимоги може знадобитися реалізація декількох механізмів захисту. Як наслідок, неоднозначність тлумачення цих вимог(у частині підходів до їх реалізації), і можливість принципової відмінності підходів до реалізації механізмів захисту в СЗІ від НСД різними колективами розробників. Результат - різна ефективність засобів захисту інформації різних виробників, що реалізовують одні і ті ж формалізовані вимоги. Адже це вимоги до коректності реалізації механізмів захисту, не виконання будь-якого з них може звести нанівець усі зусилля із забезпечення інформаційної безпеки.

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-11-14