Контрольні запитання
Які класи загроз розрізняються з погляду їх впливу на інформацію?
Що таке дестабілізуючий фактор?
Подайте класифікацію дестабілізуючих факторів за типами.
Подайте класифікацію дестабілізуючих факторів за джерелами.
Хто такий порушник?
Що таке модель порушника?
Лекція №13. Захист інформації від несанкціонованого доступу. Причини порушення безпеки
План
Основні причини порушення безпеки інформації.
Класифікація вірусів.
Авторі вірусів.
4.5. Причини порушення безпеки
Сформована практика дослідження випадків порушення безпеки, що приділяє основну увагу методу і засобам подолання захисту, має істотний недолік – відштовхуючись від дій ЗЛ, вона фактично являє собою лише аналіз технології подолання засобів захисту і не дозволяє виявити недоліки засобів забезпечення безпеки.
Крім того, подібний підхід відразу розділяє усі випадки порушення безпеки на навмисні, що класифікуються за способами подолання захисту, і ненавмисними, обумовленими помилками, закладеними в самій АС при її розробці та експлуатації. Однак здається цілком прийнятною і дуже прагматична точка зору – важливий сам факт порушення безпеки і ті заходи, які необхідно почати для запобігання подібних порушень, а їхня навмисність не має значення. З цього погляду можливість успішних дій зловмисника, як і передумови випадкових порушень, визначені властивостями самої АС – її архітектурою, реалізацією та адмініструванням.
Це означає, що в основі кожного факту порушення безпеки АС лежить відповідна вада засобів захисту, що обумовлює успішне здійснення атаки. Аналіз випадків порушення безпеки повинен ґрунтуватися не стільки на дослідженні методів, використовуваних порушником, скільки на виявленні властивостей АС, що дозволили йому здійснити свої дії. Інакше кажучи, що з'явилося причиною успішного здійснення порушення безпеки в тому чи іншому випадку?
Аналіз і статистка показують, що усі випадки порушення безпеки АС відбуваються за одною з наступних причин:
Вибір моделі безпеки, що не відповідає призначенню чи архітектурі АС. Модель безпеки повинна відповідати вимогам безпеки, запропонованим для АС. В даний момент спостерігається певна невідповідність між моделями безпеки та архітектурою АС. Фактично формальні моделі безпеки існують тільки у виді теорії, а розроблювачі АС змушені піддавати їх певної інтерпретації, щоб пристосувати до конкретної АС. При цьому приходиться йти на певні компроміси і може виявитися, що модель безпеки в ході реалізації піддалася істотним перекручуванням. Це означає, що при виборі моделі безпеки не можна не враховувати специфіку архітектури, у противному випадку, незважаючи на всі переваги моделі, гарантованого нею рівня безпеки досягти не удасться.
Неправильне впровадження моделі безпеки. Незважаючи на цілком адекватний вибір моделі безпеки, її реалізація і застосування до архітектури конкретної ОС у силу властивостей самої моделі чи ОС було проведено невдало. Це означає, що в ході реалізації були загублені всі теоретичні досягнення, отримані при формальному доказі безпеки моделі. Звичайно неправильне впровадження моделі безпеки в систему виражається в недостатньому обмеженні доступу до найбільш важливих для безпеки систем служб і об'єктів, а також у введенні різних виключень з передбачених моделлю правил розмежування доступу типу привілейованих процесів, утиліт і т.д.
Відсутність ідентифікації і/або автентифікації суб'єктів і об'єктів. У багатьох сучасних ОС ідентифікація та автентифікація суб'єктів і об'єктів взаємодії знаходяться на дуже примітивному рівні – суб'єкт (ЗЛ) може порівняно легко видати себе за іншого суб'єкта і скористатися його повноваженнями доступу до інформації.
Відсутність контролю цілісності засобів забезпечення безпеки. У багатьох ОС контролю цілісності самих механізмів, що реалізують функції захисту, приділяється слабка увага. Багато систем допускають прозору для служб безпеки підміну компонентів. З погляду безпеки таке положення є неприпустимим.
Помилки, які допущені в ході програмної реалізації засобів забезпечення безпеки. Ця група причин порушення безпеки буде існувати доти, поки не з'являться технології програмування, що гарантують виробництво безпомилкових програм. Оскільки, як відомо, програми завжди мають помилки, то, очевидно, такі технології не з'являться взагалі, і помилки такого роду будуть виникати завжди.
Наявність засобів налагодження і тестування в кінцевих продуктах. Багато розроблювачів залишають у комерційних продуктах так звані «люки», «діри», відладочні можливості і т.д. Причини, за якими це відбувається цілком зрозумілі – програмні продукти стають усе складніше, і налагодити їх у лабораторних умовах просто неможливо. Отже, для визначення причин збоїв і помилок вже в процесі ескплуатації розроблювачам приходиться залишати у своїх продуктах можливості для відладки і діагностики в ході експлуатації.
Помилки адміністрування. Наявність найсучасніших і розроблених засобів захисту не гарантує від можливих порушень безпеки, тому що в безпеці будь-якої системи завжди є присутнім людський фактор – адміністратор, що керує засобами забезпечення безпеки, може зробити помилку, і всі зусилля розроблювачів будуть зведені на ниц. Помилки адміністрування є досить розповсюдженою причиною порушень безпеки, але часто списуються на помилки розроблювачів засобів захисту.
Наведені причини порушення безпеки зручно представити у вигляді наcтупної схеми:
