Побудова захищених AC
У розділі розглянуто основні принципи та методи побудови СЗІ, деякі аспекти захисту на різних стадіях створення АС та аналізу захищеності СЗІ.
Нагадаємо найбільш загальні якісні риси проблеми захисту інформації, які були наведені вище. Отже, вона характеризується:
невизначеністю, яка, в свою чергу, зумовлена наявністю «людського фактора», оскільки невідомо, хто, коли, де і яким чином може порушити безпеку об'єкта захисту;
неможливістю створення ідеальної системи захисту (СЗ), тобто може йтися тільки про той або інший ступінь забезпечення безпеки об'єктів захисту;
використанням при організації захисту вимог мінімальності ризику та мінімальності можливих витрат;
необхідністю організації захисту від усіх і всього.
Аналіз цих рис, а також широкого спектру можливих загроз інформації дає можливість сформулювати найбільш загальні принципи створення захищених АС, тобто принципи, якими доцільно керуватися при розробці і втіленні в життя СЗІ для певного класу АС. їх зручно подавати у вигляді двох груп: організаційні принципи та принципи реалізації СЗІ.
7.1. Організаційні принципи побудови СЗІ
Серед організаційних принципів відзначимо такі:
Принцип законності, тобто додержання всіх законодавчих та нормативних актів, які мають відношення до забезпечення інформаційної безпеки. Важко переоцінити важливість цього принципу, хоча додержуватися його дуже непросто, особливо зважаючи на недосконалість та відставання від життя нашого відповідного законодавства.
Принцип персональної відповідальності, відповідно до якого кожен співробітник підприємства, фірми або їхній партнер несе персональну відповідальність за збереження режиму безпеки в рамках своїх повноважень. СЗІ має будуватися таким чином, щоб при будь-яких порушеннях було чітко відоме або хоча б мінімізоване коло осіб, що мають відношення до порушень. Це не тільки полегшує процес розслідування порушень, а також є ефективним засобом
сумлінного виконання службових обов'язків і утримання потенційних ЗЛ від несанкціонованих дій.
Принцип обмеження повноважень, який має відношення як до персоналу, так і до засобів захисту та обробки інформації; відповідно до нього, по-перше, ніхто не повинен знайомитись із конфіденційною інформацією, якщо це не потрібно для виконання його службових обов'язків; по-друге, повинна бути реалізована заборона на фізичний доступ до вразливих об'єктів для осіб, яким це не потрібно за родом їхньої діяльності; по-третє, для виконання функціональних обов'язків персоналу слід надавати мінімум будь-яких засобів.
Принцип взаємодії та співпраці усіх служб АС, спрямований на створення в АС сприятливої внутрішньої та зовнішньої атмосфери безпеки. Внутрішня атмосфера безпеки досягається довірчими відносинами між співробітниками СБ та персоналом, допоміжними заходами та стимулюванням, у тому числі і матеріальним. Діюча служба безпеки не повинна перетворюватися в засіб тотального стеження за персоналом з боку керівництва. В довірчій атмосфері набагато складніше подолати СЗІ. Створення зовнішньої атмосфери полягає в необхідності налагоджування співробітництва із зацікавленими особами та організаціями. Тобто йдеться про робочі контакти з місцевими органами влади, міліції, пожежної служби й іншими контролюючими організаціями, а також із службами безпеки сусідніх організацій - так створюються елементи колективної безпеки, що набагато підвищує її ефективність.
7.2. Принципи реалізації СЗІ
Реалізація СЗІ базується на принципах:
системності та комплексності;
централізованого управління СЗ;
неможливості обминути захисні засоби;
рівноміцності і рівнопотужності рубежів захисту;
ешелонованості оборони;
неможливості переходу до безпечного стану;
мінімальних привілеїв;
розподілу обов'язків;
простоти, гнучкості та керованості;
захисту засобів СЗ;
неперервності захисту;
розумної достатності;
відкритості алгоритмів та засобів захисту;
економічної ефективності СЗ.
Коротко пояснимо зміст наведених принципів.
Системність та комплексність включають необхідність урахування усіх елементів, умов і чинників, які є взаємозалежні, взаємодіють і змінюються в часі, а також є істотно значимі для розуміння і
вирішення проблеми забезпечення безпеки АС. При створенні системи захисту необхідно враховувати всі слабкі, найбільш вразливі місця системи обробки інформації, а також характер, можливі об'єкти і на- прямки атак на систему з боку порушників (особливо висококваліфікованих зловмисників), шляхи проникнення в АС і НСД до інформації. У розпорядженні фахівців з комп'ютерної безпеки є широкий спектр заходів, методів і засобів захисту комп'ютерних систем. їх комплексне і використання передбачає узгоджене застосування різнорідних засобів при побудові цілісної системи захисту, що перекриває всі відомі канали реалізації загроз і не містить слабких місць на стиках окремих її компонентів.
Централізоване управління СЗ необхідно планувати внаслідок наявності в будь-якій АС цілого комплексу різнорідних технічних і нетехнічних заходів і засобів захисту АС. Крім того, централізоване управління дозволяє відстежувати виконання прийнятої ПБ.
Неможливість обминути захисні засоби полягає в тому, що внаслі- док якісного та надійного інформаційного обстеження АС повинна бути впевненість у відсутності різного роду «обхідних шляхів» захис- них засобів.
Рівноміцність і рівнопотужність рубежів захисту передбачають виявлення в рубежах захисту незахищених (або слабозахищених) ділянок і планування посилення найслабкішої ланки, а також однако- вого відносного рівня захищеності кожного рубежу захисту - більш потужний захист там, де більша загроза, і менш потужний у протилежному випадку. Крім того, рівноміцність передбачає найбільш ефек- тивний розподіл захисних ресурсів по рубежах.
Ешелонованість оборони означає, що не слід покладатися на один захисний рубіж, яким би надійним він не здавався. За засобами фізичного захисту повинні слідувати програмно-технічні засоби, за ідентифікацією та автентифікацією - управління доступом і т. п. Засоби захисту на рівні ОС повинні забезпечувати одну з найбільш укріплених ліній оборони, оскільки ОС - це саме та частина КС, яка керує використанням усіх її ресурсів. Зовнішній захист повинен
Забезпечуватися фізичними, організаційними і правовими засобами. Неможливість переходу до безпечного стану передбачає, що за будь-яких обставин, в тому числі і нештатних, захисний засіб або виконує свої функції, або повністю блокує доступ. Образно кажучи,
такий стан має бути подібним до наступного: якщо в фортеці механізм під'ємного мосту ламається, то міст має залишатися в піднятому стані. Принцип мінімальних привілеїв наказує виділяти персоналу тільки ті права доступу, які необхідні йому для виконання службових обов'язків, зменшуючи тим самим збитки від випадкових або навми- сних некоректних дій персоналу.
Принцип розподілу обов'язків передбачає такий розподіл ролей і відповідальності, щоб лише одна людина не могла порушити
і
критично важливий для організації процес або створити пролом у захисті на замовлення зловмисника. Зокрема, його реалізація може попередити зловмисні або некваліфіковані дії персоналу.
Простота означає, що механізми захисту повинні бути інтуїтивно зрозумілі і прості у використанні. Застосування засобів захисту не повинно бути пов'язане зі знанням спеціальних мов або виконанням дій, що вимагають значних додаткових трудовитрат при звичній роботі законних користувачів, а також не повинно вимагати від користувача виконання рутинних малозрозумілих йому операцій (наприклад, запровадження декількох паролів та імен і т. п.). Крім того, простота дає можливість формально або неформально доводити коректність захисту.
Майже завжди вжиті заходи і встановлені засоби захисту, особливо в початковий період їхньої експлуатації, можуть забезпечувати як надмірний, так і недостатній рівень захисту. Природно, що для забезпечення можливості варіювання рівня захищеності засоби захисту повинні мати певну гнучкість. Особливо важливою ця властивість є в тих випадках, коли встановлення засобів захисту необхідно здійсню вати на працюючій системі, не порушуючи процесу її нормальногс функціонування. Крім того, зовнішні умови і вимоги з часом змінюють ся. В таких ситуаціях властивість гнучкості може врятувати власники АС від необхідності вжиття кардинальних заходів для повної заміни за собів захисту на нові. Керованість дозволяє перевіряти узгодженісті конфігурацій різних компонентів і здійснювати централізоване адмініс трування.
Принцип захисту засобів СЗ вимагає, щоб будь-який захисний захід або засіб був, у свою чергу, забезпечений захистом. При цьом; в основі принципу повинні лежати правила: «захист від усіх», «все що незрозуміле - небезпечне», «довіряй, але перевіряй».
Неперервність захисту означає, що захист інформації - це не разовий захід і навіть не певна сукупність проведених заходів і вста новленого засобу захисту, а безперервний цілеспрямований процес що передбачає вжиття відповідних заходів на всіх етапах життєвого циклу АС, починаючи з ранніх стадій проектування, а не тільки на етапі її експлуатації. Розробка СЗ повинна вестися паралельно з розроб кою самої АС. Це дозволить врахувати вимоги безпеки при проектуван ні архітектури і, у кінцевому рахунку, дозволить створити більш ефек тивну (як за затратами ресурсів, так і за невразливістю) захищену систему. Більшості фізичних і технічних засобів захисту для ефективно го виконання своїх функцій необхідна постійна організаційна (адмініст-ративна) підтримка (своєчасна зміна і забезпечення правильного збере ження і застосування імен, паролів, ключів шифрування, перевизначен ня повноважень і т. ін.). Перерви в роботі засобів захисту можуть бути використані ЗЛ для аналізу застосованих методів і засобів захисту; для впровадження спеціальних програмних і апаратних «закладок» і інших засобів подолання СЗ після відновлення її функціонування.
Розумна достатність передбачає, що створити абсолютно непереборну СЗ принципово неможливо - при достатній кількості часу і засобів можна перебороти будь-який захист. Однак високоефективна СЗ коштує дорого, використовує при роботі суттєву частину потужності і ресурсів КС і може створювати істотні додаткові незручності користувачам. Отже, СЗ має бути організована ефективно, тобто обсяг застосованих заходів повинен бути розумним і відповідати існуючим загрозам. Відкритість алгоритмів та засобів захисту полягає в тому, що застосовані для організації захисту методи, алгоритми та інші засоби не обов'язково мають бути засекреченими. Наприклад, відкритість алгоритму роботи СЗ не повинна давати можливість подолати її (навіть його автору). Як показує досвід, засекреченість розробок із захисту аж ніяк не підвищує рівень захищеності системи, а іноді навіть провокує підвищену увагу до неї, фактично підвищуючи ризик подолання СЗ.
Економічна ефективність СЗ означає, що слід вести мову тільки про деякий прийнятний рівень безпеки. Він має досягатися мінімумом витрат, тобто важливо правильно обрати той достатній рівень захисту, при якому поточні економічні витрати, ризик і розмір можливих майбутніх витрат були б прийнятними.
7.3. Методи побудови захищених АС
Методи побудови захищених АС умовно можна розділи-
Іти на дві групи [6]:
1) що стосуються довільного ПЗ АС: ієрархічний метод розробки; дослідження коректності і верифікація.
2) специфічні тільки для систем захисту (теорія безпечних систем). Спочатку розглянемо ієрархічний метод розробки ПЗ АС. Відповідно до принципу абстракції при проектуванні АС розробники можуть іти щонайменше двома шляхами: від апаратури «вгору» - до віртуальної машини, яку являє собою АС, чи від віртуальної машини «униз» - до реального устаткування. Це і є два основні методи проектування - метод знизу вгору і метод зверху вниз. Інші методи по своїй суті зводяться до цих двох чи є їх комбінацією. Метод знизу вгору передбачає початок проектування з основного апаратного устаткування системи. При проектуванні модулі розби-ваються на ряд шарів, причому нульовий шар віртуальної системи утворює апаратура. Шари, що реалізують одну чи кілька необхідних властивостей, додаються послідовно, поки не буде отримана бажана віртуальна машина.
До недоліків методу проектування знизу вгору відносять: • необхідність із самого початку приймати рішення про вибір способу реалізації компонентів АС - за допомогою апаратури, мікропрограм чи програм,- який зробити дуже важко; • можливість проектування АС тільки після розробки апаратури;
• розбіжність між реальною АС і визначеною в ТЗ.
При використанні методу зверху вниз (ієрархічний метод) виходять від віртуальної машини, що представляє АС, з необхідними властивостями і послідовно розробляють шари віртуальної системи апаратури. У цьому випадку проектування відбувається в такій послідовності. Визначається рівень абстракції опису компонентів АС вищого шару. Далі систематично проводиться аналіз того, чи достатньо визначені компоненти, щоб можна було їх реалізувати, використовуючи деякі примітивні поняття. Якщо ні, то кожна функція кожного компонента представляється функціями компонентів наступного шару, якому відповідає більш низький рівень абстракції, і знову проводиться аналіз на можливість їхньої реалізації. В ієрархічному методі доцільно використовувати структурний принцип і принцип модульного проектування.
Структурний принцип має фундаментальне значення і є основою більшості реалізацій. Відповідно до цього принципу, для побудови ПЗ вимагаються тільки три основні конструкції:
функціональний блок;
конструкція узагальненого циклу;
• конструкція ухвалення двоїчного рішення. Функціональний блок можна представити як окремий обчислювальний оператор чи як будь-яку іншу реальну послідовність обчислень з єдиним входом і єдиним виходом, як у підпрограмі. Організація циклу в літературі часто згадується як елемент DO-WHILE. Конструкція ухвалення двоїчного рішення називається IF-THEN-ELSE.
Зауважимо, що ці конструкції можуть самі розглядатися як функціональні блоки, оскільки вони мають тільки один вхід і однн вихід. Таким чином, можна ввести перетворення операції циклу у функціональний блок і в подальшому розглядати всякий такий оператор циклу еквівалентом (трохи більш складного) функціонального блоку. Аналогічно можна ввести перетворення конструкції ухвалення рішення до функціонального блоку. Нарешті, можна привести будь-яку послідовність функціональних елементів до одного функціонального елемента. У той же час зворотна послідовність перетворень може бути використана в процесі проектування програми за спадною схемою, тобто виходячи з єдиного функціонального блоку, що поступово розкладається в складну структуру основних елементів.
Принцип модульного проектування полягає в поділі програм на функціонально самостійні частини (модулі), що забезпечують замінність, кодифікацію, видалення і доповнення складових.
Переваги використання модульного принципу такі:
• спрощується налагодження програм, тому що обмежений доступ до модуля й однозначність його зовнішнього прояву виключають вплив помилок в інших, зв'язаних з ним, модулях найого функціонування;
забезпечується можливість організації спільної роботи великих колективів розробників, тому що кожен програміст має справу з незалежною від інших частиною програми;
підвищується якість програми, тому що відносно малий розмір модулів і, як наслідок, невелика складність їх дають змогу провести більш повну перевірку програми.
Іншою проблемою є дослідження коректності реалізації і верифікація АС. Під поняттям коректності чи правильності розуміється відповідність об'єкта, що перевіряється, певному еталонному об'єкту чи сукупності формалізованих еталонних характеристик і правил. Коректність ПЗ при розробці найбільш повно визначається ступенем відповідності висунутим до неї формалізованим вимогам програмної специфікації. У специфікаціях відбивається сукупність еталонних характеристик, властивостей і умов, яким повинна відповідати програма. Основну частину специфікації складають функціональні критерії і характерис- тики. Вихідною програмною специфікацією, якій повинна відповідати програма, є ТЗ. У разі відсутності такої цілком формалізованої специфікації вимог, як ТЗ, якому повинна відповідати АС і результати її функціонування, іноді використовуються неформалізовані представлення роз- робника чи користувача-замовника програм. Однак поняття корект- ності програм стосовно запитів користувача чи замовника пов'язане з невизначеністю самого еталона, якому повинна відповідати АС. Для складних програм завжди існує ризик знайти їхню некоректність (на думку користувача чи замовника) при формальній коректності щодо специфікацій унаслідок неточності самих специфікацій. Традиційний погляд на специфікацію вимог полягає в тому, що І вона являє собою документ, написаний природною мовою, що є ін- терфейсом між замовником і виготовлювачем. Хоча підготовці доку- мента може передувати деяка взаємодія, саме цей документ значною мірою виступає як «точка відліку» для виготовлювача програм. Таким чином, можна зробити висновок про те, що створення су-купності взаємопов'язаних несуперечливих специфікацій є необхідною базою для забезпечення коректності проектованої програми. При цьому специфікації повинні: • бути формальними;
• дозволяти перевіряти несуперечність і повноту вимог замовника; • бути основою для подальшого формалізованого проектування ОС. Існує кілька підходів до визначення специфікацій вимог.
Специфікація як опис. Замовник видає специфікацію, щоб виробники могли постачити його тим виробом, що він бажає, тому замов-ник бачить цей документ головним чином як опис системи, яку він
бажав би мати. У принципі, в описі має бути зазначено, що повинна і Що не повинна робити система. На практиці звичайно по умовчанню передбачається, що система повинна робити те, що уточнюється в
специфікації, і не повинна робити нічого іншого. У цьому полягає головна проблема з описовою стороною специфікації. Передбачається, що замовник завжди точно знає все, що система повинна і не повинна робити. Більше того, надалі передбачається, що замовник цілком переніс це знання у специфікований документ.
Специфікація як розпорядження. Виробник дивиться на специфікований документ як на набір складових, що підлягають збиранню, щоб розв'язати проблему замовника. Такий директивний підхід обумовлюється не тільки труднощами створення описового документа (як зазначалося вище), а й відомостями, що навмисно чи ненавмисно розширюють чи обмежують волю виробника.
Договірна методологія. У рамках «опис замовника - розпорядження виробнику» специфікація розглядається як формальний поділ між сторонами. Що стосується замовника, то він обумовлює мінімально прийнятне, тоді як виготовлювач - максимально необхідне. Договір пропонується і приймається при зародженні системи і закінчується після завершення системи, коли замовник приймає систему, яка відповідає його мінімальним вимогам. Під час виготовлення системи в принципі не передбачається ніяких взаємодій, навіть якщо виробник підозрює, що наказуване не зовсім відповідає тому, що замовник бажає бачити насправді.
Специфікація як модель. Сучасні більш строгі уявлення про специфікацію трактують її як модель системи. За умови, що покладена в основу моделі семантика достатньою мірою обґрунтована, така специфікація забезпечує чітке формулювання вимог.
Відповідні моделі підходять також для автоматизованого контролю цілісності й іншого прогнозного аналізу, що, зокрема, забезпечить припинення розробки системи, у принципі не здатної задовольнити вимоги.
Моделі як опис системи мають такі відмітні риси порівняно з іншими способами формального опису:
добре сполучення спадного і висхідного підходів до їхньої розробки з можливістю вибору абстрактного опису;
можливість опису рівнобіжної, розподіленої і циклічної роботи;
можливість вибору різних формалізованих апаратів для опису систем.
Основна перевага використання формальної моделі полягає в можливості дослідження з її допомогою особливостей системи, що моделюється. Покладаючи в основу формального методу розробки математичну модель і потім досліджуючи модель, можна виявити такі грані поводження системи, що в іншому разі не були б очевидні до більш пізніх стадій.
Оскільки цільовим об'єктом проектування є АС, то модель може описувати або саму АС, або її поводження, тобто зовнішні прояви функціонування АС. Модель, що описує поводження АС у порівнянні з моделлю АС, має одну важливу перевагу - вона може бути перевірена й
оцінена як виконавцями, так і замовниками, оскільки замовники не знають, як повинна працювати АС, але зате вони уявляють, що вона повинна робити. У результаті такого моделювання може бути перевірена коректність специфікацій щодо вихідної постановки задачі, тобто ТЗ. Крім того, критерії правильності вважаються достатніми за умови, що специфікація являє собою вичерпний опис «зовнішнього» поводження об'єкта в усіх можливих (чи запланованих) ситуаціях його використання.
Як було відзначено вище, при розробці АС, особливо її компонентів, що представляють СЗІ, для забезпечення високих гарантій відсутності несправностей і наступного доказу того, що система функціонує відповідно до вимог ТЗ, використовуються формальні підходи до її проектування.
Формальне проектування алгоритмів базується, в основному, на мовах алгоритмічних логік, що включають висловлення виду
Q{S}R,
що читається в такий спосіб: «якщо до виконання оператора S була виконана умова Q, то після нього буде R». Тут Q називається перед-
: умовою, a R - постумовою. Ці мови були винайдені практично одно-
часно Р. У. Флойдом (1967 p.), С. А. Р. Хоаром (1969 р.) і вченими
польської логічної школи (А. Сальвіцький та ін., 1970 p.). Як переду-
мова, так і постумова є предикатами.
Розгляд програм як деяких «перетворювачів предикатів» дає змо-
гу прямо визначити зв'язок між початковими і кінцевими станами без яких-небудь посилань на проміжні стани, що можуть виникнути під
час виконання програми.
Перевага представлення алгоритму у вигляді перетворювача пре-
дикатів полягає в тому, що воно дає можливість:
• аналізувати алгоритми як математичні об'єкти;
• дати формальний опис алгоритму, що дозволяє інтелектуально
охопити алгоритм;
• синтезувати алгоритми за представленими специфікаціями;
• провести формальне верифікування алгоритму, тобто довести коректність його реалізації.
Методологія формальної розробки і доведення коректності в да-
ний час добре розроблена і викладена в цілому ряді робіт. Коротко
викладемо суть цих методів:
• розробка алгоритму проводиться методом послідовної деком-позиції, з розбивкою загальної задачі, розв'язуваної алгоритмом, на ряд дрібніших підзадач;
• критерієм деталізації підзадач є можливість їхньої реалізації за допомогою однієї конструкції чи розгалуження циклу;
• розбивка загальної задачі на підзадачі передбачає формулю-вання перед-і постумов для кожної підзадачі з метою їхньогокоректного проектування і подальшої верифікації.
Для доведення коректності алгоритму (верифікація) формулюється математична теорема Q{S}R, що потім доводиться. Доведення теореми про коректність прийнято розбивати на дві частини. Одна частина служить для доведення того, що розглянутий алгоритм може завершити роботу (проводиться аналіз усіх циклів). В іншій частині доводиться коректність постумови в припущенні, що алгоритм завершує роботу.
Дуже важливим напрямком є теорія довірених безпечних систем (ТСВ). Поняття «довірене обчислювальне середовище» (trusted computing base - ТСВ) з'явилося у закордонній практиці забезпечення інформаційної безпеки досить давно. Зміст характеристики «довірена» можна пояснити в такий спосіб.
Дискретна природа характеристики «безпечний» (у тому сенсі, що або щось є безпечним, цілком задовольняючи ряд пропонованих вимог, або не є, якщо одна чи кілька вимог не виконані) у сполученні з твердженням «ніщо не буває безпечним на сто відсотків» підштовхують до того, щоб увести більш гнучкий термін, який дає можливість оцінювати те, наскільки розроблена захищена АС відповідає очікуванням замовників. У цьому відношенні характеристика «довірений» більш адекватно відбиває ситуацію, де оцінка, виражена цією характеристикою (безпечний чи довірений), грунтується не на думці розробників, а на сукупності факторів, включаючи думку незалежної експертизи, досвід попереднього співробітництва з розробниками, і, в остаточному підсумку, є прерогативою замовника, а не розробника.
Довірене обчислювальне середовище (ТСВ) включає сукупність усіх компонентів і механізмів захищеної АС, що відповідають за реалізацію політики безпеки. Всі інші частини АС, а також її замовник покладаються на те, що ТСВ коректно реалізує задану політику безпеки навіть у тому випадку, якщо окремі модулі чи підсистеми АС розроблені висококваліфікованими ЗЛ для того, щоб втрутитися у функціонування ТСВ і порушити підтримувану нею політику безпеки.
Мінімальний набір компонентів, що утворюють довірене обчислювальне середовище, забезпечує такі функціональні можливості:
взаємодію з апаратним забезпеченням АС;
захист пам'яті;
функції файлового виведення-введення-висновку;
керування процесами.
Доповнення і модернізація існуючих компонентів АС з урахуванням вимог безпеки можуть призвести до ускладнення процесів супроводу і документування. З іншого боку, реалізація всіх перелічених функціональних можливостей у рамках централізованого довіреного обчислювального середовища в повному обсязі може викликати розростання розмірів ТСВ і, як наслідок, ускладнення доведення коректності реалізації політики безпеки. Так, операції з файлами можуть бути реалізовані в ТСВ у деякому обмеженому обсязі, достатньому для підтримки політики безпеки, а розширене введення-виведення у
такому випадку реалізується в тій частині АС, що перебуває за межами ТСВ. Крім того, необхідність упровадження пов'язаних з безпекою функцій у багато компонентів АС, які реалізовані в різних модулях АС, призводить до того, що захисні функції розподіляються по всій АС, викликаючи аналогічну проблему.
7.4. Передпроектні аспекти створення СЗІ
У процесі проектування захищеної АС необхідно проектувати і СЗІ, причому потрібно враховувати два основні параметри: стан АС і рівень витрат на створення АС. Щодо стану АС, то слід зазначити, що під станами АС маються на увазі такі ситуації: АС уже функціонує, є готовий проект, система тільки проектується. Витрати ж можна задавати або поки що вважати їх необмеженими. Таким чином, глобальне завдання створення СЗІ - це створення оптимальних механізмів захисту і управління ними. Цю загальну мету можна ви- разити у вигляді послідовності наступних дій або концепції захисту:
аналіз цілей і умов проектування;
обґрунтування вимог до ЗІ; • вибір варіанта проекту;
• реалізація варіанта проекту.
Як обґрунтувати вимоги до ЗІ? Тут слід зазначити, що формаль- них методів розв'язання цієї задачі не існує і її доводиться розв'язу- вати неформально, у вигляді деяких рекомендацій, пропозицій і т. п., ; які формуються на основі наведених вище принципів. Складно, користуючись лише інженерною інтуїцією, одержати оптимальні проектні рішення. Часто доводиться залучати досить і складні наукові методи, що вимагають розробки і застосування комп'ютерних систем.
Нижче розглядається приклад можливої послідовності дій щодо створення захищеної АС [27].
Отже, загальні цілі і задачі для даного об'єкта звичайно визначаються в процесі діалогу замовника і проектанта. У ході розробки проекту вони постійно будуть уточнюватися, тобто в процесі спільної роботи підвищується взаєморозуміння замовника і проектанта і шукається розумний компроміс.
На передпроектних стадіях робіт зі створення АС повинні бути вирішені два такі основні завдання:
• сформульовано вимоги до забезпечення режиму ІБ при реалізації функцій і задач проектованої АС;
• розроблено концепцію політики ІБ.
Важливо відзначити те, що вимоги формулюються щодо задач і функцій у термінах:
• доступності (період недоступності, час доступу, інші показни- ки, обумовлені предметною областю);
цілісності (показники надійності збереження, доставки);
конфіденційності (градації конфіденційності чи грифів таємності). Розробка концепції політики ІБ відбувається на етапі «Розробка варіантів концепції АС і вибір варіанта концепції АС» після вибору варіанта концепції створюваної АС і здійснюється на основі аналізу таких груп факторів:
правові і договірні вимоги;
вимоги до забезпечення режиму ГБ щодо функцій і задач АС;
загрози (класи ризиків), яким піддаються інформаційні ресурси. У результаті аналізу формулюються загальні положення ІБ, що стосуються організації в цілому:
цілі і пріоритети, які має організація в області ІБ;
загальні напрямки в досягненні цих цілей;
• аспекти програми ІБ, що повинні зважуватися на рівні організації в цілому;
• посадові особи, відповідальні за реалізацію програми ІБ.Розробку самої політики ІБ варто здійснювати на стадії «Технічне завдання» і при цьому виконати такі етапи:
аналіз ризиків;
визначення вимог до засобів захисту;
вибір основних рішень щодо забезпечення режиму ІБ;
розробка планів забезпечення безперебійної роботи організації;
документальне оформлення політики ІБ. Розглянемо один за одним зазначені етапи.
Аналіз ризиків передбачає вивчення і систематизацію загроз ІБ, визначення вимог до засобів забезпечення ІБ. Вивчення і систематизація загроз ІБ передбачає такі етапи:
Вибір елементів АС і інформаційні ресурси, для яких буде застосовано аналіз. Повинні бути обрані критичні елементи АС і критичні інформаційні ресурси, що можуть бути об'єктами атаки чи самі є потенційним джерелом порушення режиму ІБ.
Ідентифікація загроз і формування їх списку. Формується детальний список загроз, складається матриця загрози/елементи АС чи інформаційні ресурси. До кожного елемента матриці потрібно скласти опис можливого впливу загрози на відповідний елемент АС чи інформаційний ресурс. У процесі складання матриці уточнюється список загроз і виділених елементів.
Розробка методології оцінки ризику. Повинні бути отримані оцінки гранично припустимого й існуючого ризику здійснення загрози протягом деякого часу. В ідеалі для кожної із загроз має бути отримане значення ймовірності її здійснення протягом деякого часу. Це допоможе співвіднести оцінку можливого збитку з витратами на захист. На практиці для більшості загроз неможливо одержати достовірні дані про ймовірність реалізації загрози і доводиться обмежуватися якісними оцінками.
Оцінка збитку, пов'язаного з реалізацією загроз. Здійснюється оцінка збитку, що може завдати діяльності організації реалізація загроз безпеки, з урахуванням можливих наслідків порушення конфіденційності, цілісності і доступності інформації.
Оцінка витрат на заходи, пов'язані із захистом і залишковим ризиком. Здійснюється попередня оцінка прямих витрат по кожному заходу без урахування витрат на заходи комплексного характеру.
Аналіз вартість/ефективність. Витрати на систему захисту інформації необхідно співвіднести з цінністю інформації, що захищається, й інших інформаційних ресурсів, що піддаються ризику, а також зі збитком, який може бути завдано організації внаслідок реалізації загроз. У результаті аналізу уточнюються припустимі залишкові ризики і витрати на заходи, пов'язані із захистом інформації.
Підсумковий документ. За результатами проведеної роботи складається документ, що містить:
переліки загроз ІБ, оцінки ризиків і рекомендації для зниження ймовірності їхнього виникнення;
захисні заходи, що необхідні для нейтралізації загроз;
аналіз вартість/ефективність, на підставі якого робляться висновки про припустимі рівні залишкового ризику і доцільність застосування конкретних варіантів захисту.
При визначенні вимог до засобів захисту вихідними даними є:
аналіз функцій і задач АС;
аналіз ризиків.
На основі цих даних обирається профіль захисту (клас захищеності АС від НСД) і у разі потреби в технічному завданні формулюються додаткові вимоги, специфічні (пов'язані, наприклад, зі специфікою ІБ у сучасних розподілених АС) для даної АС.
Для всіх функцій і задач АС потрібно дати визначення відповідних функцій безпеки. Функції безпеки з однаковими назвами можуть мати різні визначення для різних функцій і задач АС.
Потім визначаються механізми безпеки, що реалізують ці функції. Як відомо, основні механізми ІБ такі:
керування доступом до інформації;
ідентифікація й автентифікація;
криптографія;
екранування;
забезпечення цілісності і доступності даних;
підтримка працездатності АС при збоях, аваріях, НП;
відстеження подій, що становлять загрозу ІБ;
керування доступом в АС;
протоколювання дій і подій.
Вибір основних рішень щодо забезпечення режиму ІБ повинен бути розглянутий на трьох рівнях:
адміністративному (система підтримки керівництвом організації робіт із забезпечення ІБ);
організаційному (конкретні організаційні заходи щодо забезпечення режиму ІБ);
технічному (реалізація механізмів захисту програмно-технічними засобами).
7.5. Забезпечення режиму ІБ на подальших стадіях створення АС
Подальшими стадіями створення АС є «Ескізний проект» і «Технічний проект». На цих стадіях повинні бути розроблені проектні рішення, що реалізують механізми ІБ. Проектні рішення мають включати розділи:
основні технічні рішення по системі в цілому;
опис автоматизованих функцій і задач;
основні технічні рішення за видами забезпечення;
заходи щодо підготовки об'єкта автоматизації до введення системи в дію.
У процесі підготовки до експлуатації АС повинні бути вирішені питання навчання користувачів і персоналу, організації фізичного захисту і контролю за дотриманням режиму ІБ, організації доступу користувачів до роботи в АС.
Користувачів і персонал мають навчити дотриманню режиму ІБ, правильному поводженню з інформаційними ресурсами. Вони повинні знати про загрози порушення режиму ІБ і мати необхідні навички для роботи в АС. Рекомендується затвердити права й обмеження на доступ користувачам у письмовій формі.
Для організації фізичного захисту і контролю за дотриманням режиму ІБ повинні бути розглянуті такі питання.
Контроль доступу в приміщення. Контроль доступу в приміщення і загальні заходи для захисту устаткування є складовою заходів для забезпечення ІБ. Устаткування, критично важливі чи вразливі елементи системи, повинні бути розміщені в захищених ділянках, обмежених периметром безпеки, з належним контролем доступу в приміщення. Для зменшення ризику НСД чи ушкодження документації і носіїв інформації рекомендується задати правила використання робочого столу.
Забезпечення конфіденційності. Користувачі інформаційних ресурсів організації повинні підписати зобов'язання про збереження конфіденційності (нерозголошення). Особливу увагу варто приділити процедурі надання доступу до інформаційних ресурсів користувачам зі сторонніх організацій. Для цього повинні бути розроблені спеціальні правила.
Журнали реєстрації подій. Необхідно підготувати журнал реєстрації виконуваних завдань, що будуть вести оператори АС.
4. Забезпечення захисту документації по АС. Документація по АС може містити опис прикладних процесів, структур даних і процесів підтвердження повноважень. У цьому випадку вона повинна бути захищена від НСД. Рекомендується застосовувати такі засоби контролю:
список осіб із правом доступу до документації повинен бути максимально обмежений, а дозвіл на її використання має видаватися власником додатка;
друковані матеріали, створювані в процесі роботи АС, які стосуються документації, варто зберігати окремо від інших матеріалів і поширювати на них правила обмеження доступу.
5. Доступ до носіїв інформації і їхній захист. Необхідно організувати контроль доступу до носіїв інформації і забезпечити їхній фізичний захист. Для доступу до носіїв інформації з конфіденційноюінформацією необхідно мати затверджені правила. При організації системи доступу слід враховувати таке:
система ідентифікації носіїв повинна бути така, щоб за мітками, використовуваними для ідентифікації носіїв, не можна було визначити, яка саме інформація зберігається;
необхідно вчасно стирати вміст повторно використовуваних носіїв інформації, якщо вони більше не потрібні;
винесення носіїв інформації зі сховища необхідно фіксувати в контрольному журналі;
збереження всіх носіїв інформації в надійному, захищеному місці відповідно до інструкцій.
На етапі підготовчої роботи з організації доступу в АС рекомендується розглянути такі питання.
1. Реєстрація користувачів. Повинні існувати документи з описом доступних користувачу сервісів, допустимих правил роботи в АС і правил забезпечення режиму ІБ. Сервіси АС не повинні надаватидоступ, поки не будуть закінчені процедури визначення повноважень.Для керування доступом до багатокористувацьких сервісів має бути розроблена процедура реєстрації користувачів. Ця процедура повинна:
перевіряти, чи надано користувачеві дозвіл на використання сервісу відповідальним за його використання;
вести облік усіх зареєстрованих осіб, що використовують АС;
перевіряти, чи достатній рівень доступу користувача до системи і чи не суперечить він політиці безпеки, прийнятій в організації, наприклад, чи не компрометує він принцип поділу обов'язків;
вчасно вилучати права доступу в користувачів, що залишили організацію;
періодично перевіряти і видаляти застарілі ідентифікатори й облікові записи, що більше не потрібні.
2. Керування привілеями. Використання спеціальних привілеїв варто обмежити і контролювати, оскільки це один з основних факторів, Що сприяють порушенню режиму ІБ. У багатокористувацьких АС повинна існувати система контролю надання привілеїв. При організації такої системи рекомендується:
ідентифікувати привілеї, пов'язані з кожним програмним продуктом чи сервісом, підтримуваним системою, а також категорії співробітників, яким їх необхідно надати;
надавати привілеї окремим особам тільки у випадку крайньої необхідності і залежно від ситуації, тобто тільки коли вони потрібні для виконання ними своїх функцій;
реалізувати автоматичний процес визначення повноважень і вести облік усіх наданих привілеїв;
по можливості використовувати системні програми, для яких немає необхідності надавати спеціальні привілеї користувачам;
користувачі, що мають великі привілеї для спеціальних цілей, повинні використовувати інший ідентифікатор користувача для звичайної роботи.
3. Керування паролями користувачів. Надання паролів необхідно контролювати. Зразкові вимоги до системи контролю повинні бути такими:
зобов'язати користувачів зберігати персональні паролі і паролі робочих груп у секреті;
коли користувачі повинні самі вибирати свої паролі, видати їм надійні тимчасові паролі, що вони зобов'язані негайно замінити. Тимчасові паролі також видаються у випадку, коли користувачі забувають свої паролі;
передавати тимчасові паролі користувачам надійним способом. Варто уникати передачі паролів через посередників чи за допомогою незахищених (незашифрованих) повідомлень електронної пошти. Користувачі повинні підтвердити одержання паролів.
4. Перегляд прав доступу користувачів. Для забезпечення ефективного контролю за дотриманням режиму ІБ необхідно організувати процес перегляду прав доступу користувачів через регулярні проміжкичасу. Такий процес має забезпечувати:
перегляд повноважень доступу користувачів через регулярні проміжки часу (наприклад, 6 місяців);
перегляд дозволу на надання спеціальних привілейованих прав доступу через більш короткі проміжки часу (наприклад, 3 місяці).
Підтримка режиму ІБ при експлуатації АС вимагає постійного контролю за реалізацією політики ІБ. Основними напрямками є контроль за роботою користувачів, захист цілісності даних і програм, керування доступом до додатків.
Контроль за роботою користувачів включає такі аспекти:
керування доступом до робочих місць в АС;
контроль за використанням паролів;
контроль за устаткуванням, залишеним без нагляду;
відстеження часу простою терміналів;
обмеження доступу до сервісів.
Користувачі повинні знати свої обов'язки щодо забезпечення контролю доступу, особливо що стосується використання паролів. Доступ користувача до ресурсів АС повинен надаватися відповідно до політики керування доступом. Зокрема, рекомендується надати користувачам тільки прямий доступ до сервісів, використання яких їм дозволено. Особливу увагу адміністраторам безпеки слід приділяти контролю мережних підключень до конфіденційних чи критично важливих додатків, а також контролю за роботою користувачів у зонах підвищеного ризику, наприклад, у загальнодоступних місцях, що знаходяться поза організацією. Слід контролювати такі аспекти.
1. Керування доступом до робочих місць в АС. Доступ до робочих місць в АС слід надавати тільки зареєстрованим користувачам.Системи керування доступом повинні забезпечувати:
ідентифікацію й автентифікацію користувачів, а також при необхідності термінала і місцезнаходження кожного зареєстрованого користувача;
ведення журналу обліку спроб доступу (успішних і невдалих) до АС;
у разі потреби обмежувати підключення користувачів у неви-значений час.
2. Використання паролів. Користувачі повинні слідувати встановленим процедурам підтримки режиму ІБ при виборі і використанні паролів. Пропонуються такі рекомендації з вибору і використання паролів:
рекомендується вибирати паролі, що містять не менше як шість символів;
при виборі паролів не слід використовувати: місяці року, дні тижня і т. п., прізвища, ініціали, реєстраційні номери автомобілів; назви й ідентифікатори організацій; номери телефонів чи групи символів, що складаються з одних цифр; більш як два однакових символи, що слідують один за одним; групи символів, що складаються з одних цифр чи одних букв;
змінювати паролі через регулярні проміжки часу (приблизно через місяць) і уникати повторного чи «циклічного» використання старих паролів;
частіше змінювати паролі для привілейованих системних ресурсів, наприклад, паролі доступу до певних системних утиліт;
змінювати тимчасові паролі при першому вході в системи;
не включати паролі в процедури автоматичного входу в системи, наприклад у макроси чи функціональні клавіші;
не допускати використання одного пароля кількома користувачами;
забезпечувати збереження паролів у секреті;
змінювати паролі кожного разу, коли є ознаки можливої компрометації паролів;
• якщо користувачам необхідний доступ до кількох сервісів, захищених паролями, то їм рекомендується використовувати одиннадійний пароль.
3. Користувацьке устаткування, залишене без нагляду. Користувачі повинні забезпечити належний захист устаткування, залишеного без нагляду. Устаткування, встановлене на робочих місцях користувачів(наприклад, робочі станції чи файлові сервери), може потребувати організації захисту від НСД. Користувачі повинні знати процедури захисту устаткування, залишеного без нагляду, а також свої обов'язки із забезпечення такого захисту.
Пропонуються такі рекомендації:
завершувати сеанси зв'язку по закінченні роботи, якщо їх не можна захистити за допомогою відповідного блокування;
використовувати логічне відключення від серверів по закінченні сеансу зв'язку, не обмежуватися тільки вимиканням ПК чи термінала;
захищати невикористовувані ПК чи термінали шляхом блокування ключем чи іншим засобом контролю доступу.
Відстеження часу простою терміналів. Для недіючих терміналів у зонах з підвищеним ризиком порушення ІБ (у загальнодоступних місцях чи місцях, що знаходяться поза межами досяжності адміністраторів безпеки організації) необхідно встановити допустимий час простою для запобігання доступу незареєстрованих користувачів. Після закінчення цього часу екран термінала має очищатися, а сеанси зв'язку з додатками і мережними сервісами завершуватися. Допустимий час простою повинен задаватися виходячи з аналізу ризику НСД до користувацького термінала.
Обмеження періоду підключення. Додатковий захист сервісів від НСД можна забезпечити за допомогою обмеження допустимого періоду підключення. Обмеження дозволеного періоду підключення термінала до АС дає змогу зменшити імовірність НСД до ресурсів АС. Можливість застосування такого засобу контролю варто розглянути для АС з терміналами, встановленими в зонах підвищеного ризику порушення ІБ (у загальнодоступних місцях чи місцях, що знаходяться поза межами досяжності адміністраторів безпеки). Прикладами таких обмежень є:
використання визначених інтервалів часу дозволеного доступу, наприклад, для пакетної передачі файлів, регулярних чи інтерактивних сеансів зв'язку невеликої тривалості;
обмеження часу підключення звичайних годин роботи організації і одержання спеціального дозволу для роботи в понаднормовий час.
6. Обмеження доступу до сервісів. Користувачам і обслуговуючому персоналу АС слід надавати доступ до сервісів відповідно до прийнятої політики керування доступом до інформації. Рекомендується розглянути можливість використання таких засобів контролю:
доступ до додатків (сервісів) через систему меню, що забезпечує контроль повноважень доступу користувачів;
обмеження доступу користувачів до інформації про структури даних і функції АС, доступ до яких їм не дозволено, за допомогою відповідного редагування документації користувачів;
контроль за вихідною інформацією додатків на предмет наявності в них конфіденційної інформації. Така інформація повинна надсилатися тільки на визначені термінали і комп'ютери. Повинен проводитися періодичний аналіз вихідної інформації і за потреби зайва інформація повинна вилучатися.
Адміністратори АС і користувачі повинні бути завжди готові до можливості проникнення шкідливого ПЗ в АС і вживати заходів для виявлення його впровадження та ліквідації наслідків його атак.
В основі захисту від вірусів повинні лежати знання і розуміння правил безпеки, належні засоби керування доступом до систем. Зокрема:
організація повинна проводити політику, що вимагає установки тільки ліцензованого ПЗ;
противірусні програмні засоби повинні регулярно обновлятися і використовуватися для профілактичних перевірок (бажано щоденних);
необхідно проводити регулярну перевірку цілісності критично важливих програм і даних. Наявність зайвих файлів і слідів несанкціонованого внесення змін повинні бути зареєстровані в журналі і розслідувані;
дискети невідомого походження слід перевіряти на наявність вірусів до їхнього використання;
необхідно суворо дотримуватися встановлених процедур повідомлення про випадки ураження АС комп'ютерними вірусами і вживання заходів з ліквідації наслідків їхньвго проникнення;
слід мати плани забезпечення безперебійної роботи організації для випадків вірусного зараження, у тому числі плани резервного копіювання всіх необхідних даних і програм і їхнього відновлення. Ці заходи особливо важливі для мережних файлових серверів, що підтримують велику кількість робочих станцій.
Крім того, розглянемо особливості керування доступом до сервісів.
1. Електронна пошта. В організації повинні бути задані чіткі правила, що стосуються статусу і використання електронної пошти. Для зменшення ризику порушення ІБ, пов'язаного із застосуванням
електронної пошти, рекомендується: • враховувати вразливість електронних повідомлень стосовно
несанкціонованого перехоплення і модифікації;
• враховувати можливість неправильної адресації чи направлен-
ня повідомлень не за призначенням, а також надійність і
. доступність сервісу в цілому.
2. Системи електронного документообігу. При використанні систем електронного документообігу слід взяти до уваги виконання вимог ІБ:
необхідність виключення деяких категорій конфіденційної інформації у випадку, якщо в даній системі не забезпечується належний рівень захисту;
необхідність визначення правил і засобів контролю для адміністрування колективно використовуваної інформації, наприклад використання електронних дощок оголошень;
використання засобів обмеження доступу до інформації, що належить різним робочим групам;
визначити категорії персоналу і представників сторонніх організацій, яким дозволено використовувати систему, і місця, з яких можна одержати доступ до неї.
3. Керування доступом до додатків. Для запобігання несанкціонованому доступу до інформації в АС необхідно використовувати логічні засоби контролю доступу. Логічний доступ до додатків варто надавати тільки зареєстрованим користувачам. Додатки повинні:
контролювати доступ користувачів до даних і додатків відповідно до політики керування доступом, прийнятої в організації;
забезпечувати захист від НСД до системних програм, що здатні обійти засоби контролю і забезпечують можливість НСД;
не порушувати захисту інших систем, з якими вони розділяють інформаційні ресурси.
4. Використання системних програм. В АС можуть використовуватися системні програми, здатні обійти засоби контролю ОС і додатків. Необхідно обмежити і ретельно контролювати використання таких системних утиліт. Рекомендується використовувати такізасоби контролю (по можливості):
захист системних утиліт за допомогою паролів;
ізоляція системних утиліт від прикладного ПЗ;
надання доступу до системних утиліт мінімальному числу користувачів;
надання спеціального дозволу на використання системних утиліт;
обмеження доступності системних утиліт, наприклад, часом внесення санкціонованої зміни;
реєстрація усіх випадків використання системних утиліт;
визначення і документування рівнів повноважень доступу до системних утиліт;
видалення всіх непотрібних утиліт і системних програм.
5. Керування доступом до бібліотек вихідних текстів програм.Для зведення ризику ушкодження ПЗ до мінімуму необхідно здійснювати суворий контроль за доступом до бібліотек вихідних текстів програм. Рекомендується дотримуватися таких правил:
• не зберігати бібліотеки вихідних текстів програм в АС;
призначити відповідального за збереження бібліотеки вихідних текстів програм;
роздруківки програм слід зберігати в бібліотеках вихідних текстів;
обмежити доступ до бібліотек вихідних текстів програм;
не зберігати розроблювані програми в бібліотеках вихідних текстів робочих програм;
відновлення бібліотек вихідних текстів програм і видача текстів програм програмістам повинні виконуватися тільки призначеним відповідальним співробітником після одержання дозволу на доступ до додатка у встановленій формі;
необхідно фіксувати всі випадки доступу до бібліотек вихідних текстів програм у контрольному журналі;
застарілі версії вихідних текстів програм слід архівувати із зазначенням дати закінчення їхнього використання разом із усім допоміжним програмним забезпеченням і інформацією про організацію виконання завдань для цієї версії ПЗ;
супровід і копіювання бібліотек вихідних текстів програм необхідно здійснювати відповідно до процедур керування процесом внесення змін.
6. Ізоляція вразливих місць у захисті АС. При наявності вразливих місць у захисті АС може знадобитися організація виділеного (ізольованого) обчислювального середовища. Можливе застосуванняінших спеціальних заходів: запуск додатка на виділеному комп'ютері чи поділ ресурсів тільки з надійними прикладними системами. У загаль ному випадку рекомендується дотримуватись таких правил:
вразливі місця в АС повинні бути явно визначені і задокументовані;
коли вразливий додаток запускається в колективно використовуваному середовищі, необхідно явно вказати прикладні процеси, з якими він може працювати одночасно.
7. Відстеження подій, що становлять загрозу ІБ. Для виявлення несанкціонованих дій і забезпечення відповідності політиці керування доступом рекомендується дотримуватись встановлених правил.
8. Реєстрація подій. Усі надзвичайні ситуації і події, що пов'язані з порушенням режиму ІБ, необхідно реєструвати в журналі. Журнал слід зберігати протягом заданого проміжку часу. Крім невдалих спроб входу в систему, доцільно також реєструвати випадки успіш- ного доступу. Контрольний журнал повинен включати таке:
ідентифікатори користувачів;
дата і час входу і виходу із системи;
• ідентифікатор чи місцезнаходження термінала (по можливості).9. Спостереження за використанням сервісів. Необхідно встановити процедури спостереження за використанням сервісів АС.Користувачі повинні використовувати тільки явно дозволені сервіси.
Рівень контролю слід визначити за допомогою оцінки ризиків. Рекомендується стежити за такими подіями:
невдалі спроби доступу в АС;
спроби несанкціонованого використання відновлених користувацьких ідентифікаторів;
використання ресурсів із привілейованим доступом;
окремі дії, потенційно небезпечні з погляду порушення режиму ІБ;
використання конфіденційних ресурсів.
Усі дії, що пов'язані зі спостереженням і реєстрацією, повинні бути формально дозволені керівництвом.
10. Синхронізація системних годинників. Для забезпечення точності контрольних журналів важливо правильно встановити системний годинник і вчасно коригувати його у випадку значного відхилення.
7.6. Аналіз захищеності інформації в СЗІ
При створенні більшості АС виникає необхідність розв'язувати задачу розробки АС з мінімальною вартістю. Вартість створення подібних систем практично найчастіше пропорційна ступеню використання колективних ресурсів. Це означає, що з метою мінімізації вартості АС доцільно створювати колективний ресурс для всіх її користувачів - юридичних і фізичних осіб, включаючи засоби зберігання інформації, програмні та апаратні засоби її обробки і доступу до інших засобів і систем. Вдало вибрані організація і можливість колективного ресурсу значно знижують вартість створення й експлуатації АС при реалізації заданих вимог до її функціонування [1,2].
Проте зберігання і обробка інформації з використанням можливостей колективного ресурсу не означає, що кожному користувачу АС доступні ці можливості. Доступність визначається правилами, що формулюються при створенні АС.
Однак першим все ж є питання: потрібен захист інформації в системі взагалі чи ні. Тільки потім виникає друга задача - визначити величину витрат на захист. Звичайно, для вирішення цих питань розроблено чимало методів, методик і навіть програмних продуктів. Нижче розглядається один з можливих підходів.
Отже, рішення про необхідність захисту приймається на основі оцінок за двома напрямками:
наявність конфіденційної інформації і небезпека її витоку;
економічна необхідність (доцільність) захисту конфіденційної інформації.
Розглянемо метод, призначений для проведення загальної і часткової оцінок, що дозволяють керівникові організації (фірми) прийняти обґрунтоване рішення про необхідність захисту конфіденційної інформації, що циркулює усередині організації (фірми), від конкурентів з
оцінкою майбутніх витрат на захист. Цей підхід допомагає швидко і досить об'єктивно провести експрес-оцінку необхідності захисту конфіденційної інформації і на її основі оперативно прийняти відповідне рішення, тобто він дозволяє керівнику уникнути великих комерційних невдач і втрат прибутку через доступність інформації конкурентам без тривалого шляху навчання на власних помилках і втратах.
Рішення про необхідність захисту конфіденційної інформації, що циркулює усередині фірми, повинно прийматися керівництвом організації (фірми), й у першу чергу її засновником. Ніхто не зацікавлений такою мірою в захисті секретів фірми і ніхто так не знає усієї сукупності циркулюючої на фірмі інформації, її ступеня таємності, внутрішньої і зовнішньої обстановки, як її засновник.
Отже, перша частина методу дає змогу на основі обробки результатів анкетного опитування принципово відповісти на запитання, потрібно чи не потрібно захищати інформацію, що циркулює на фірмі, а друга частина, у випадку позитивного вирішення першого питання, допомагає приблизно оцінити витрати на майбутній ЗІ.
З огляду на зацікавленість, компетентність і кругозір засновника фірми, запропонований метод максимально враховує знання, досвід і думку самого засновника фірми. В основу першої частини методу покладено анкетне опитування з наступною обробкою його результатів.
Для реалізації даного методу розроблено перелік анкетних питань для засновника фірми, що охоплює всі сторони діяльності фірми, пов'язані з циркулюючої на ній інформацією.
Питання анкети сформульовано таким чином, що вони не вимагають великих відповідей, а зводяться до односкладових відповідей «так», «ні». Заповнення анкети не вимагає спеціальної підготовки у сфері ЗІ і не викликає труднощів та великих часових витрат. Спеціальні знання щодо ЗІ враховані при розробці анкетних питань і при наступній обробці результатів опитування за участю фахівців із ЗІ.
Кількісна оцінка про стан і необхідність додаткового захисту отримується шляхом математичної обробки відповідей на анкетні питання. З цією метою кожному питанню анкети поставлена у відповідність вагова величина, що чисельно виражає частковий внесок змісту питання в загальну систему захисту конфіденційної інформації. Значення вагових коефіцієнтів отримані експертним методом заздалегідь.
При обробці результатів анкетного опитування можна одержати як загальну оцінку стану захисту на фірмі, так і ряд часткових оцінок за напрямками захисту. Сукупність усіх оцінок допомагає керівнику в кінцевому рахунку прийняти рішення про необхідність організації захисту шляхом проведення режимних, організаційних і технічних заходів.
На основі аналізу оцінок кожної складової захисту виявляються ті її ланки, де ЗІ не забезпечений й імовірність її перехоплення конкурентом (витік) неприпустимо висока. Провівши такий аналіз, керівник
фірми може цілеспрямовано проводити роботи з усунення витоку інформації за виявленими напрямками.
Як приклад розглянемо анкету, що використовувалася для вирішення питання необхідності захисту інформації у вищих навчальних закладах.
Порядок проведення оцінок першої частини методики є таким. На першому етапі зацікавлена в ЗІ сторона в особі засновника (керівника) фірми заповнює анкету, відповідаючи на її питання, наведені в табл. 5. Відповіді на питання анкети у формі «так» чи «ні» заносяться у графу 3 проти відповідних питань.
Таблиця 5
На другому етапі із залученням консультанта проводиться аналіз результатів опитування. Якщо відповідь на питання відповідає збільшенню небезпеки витоку інформації, то в графі 4 табл. 5 проставляється знак «+», в іншому разі проставляється знак «-».
На третьому етапі проводиться підсумовування часткових коефіцієнтів графи 5, що відповідають знаку «+», із усіх питань анкети. Результат підсумовування є загальною оцінкою (G) для ухвалення рішення про необхідність захисту конфіденційної інформації на фірмі в цілому. При цьому, якщо загальна оцінка G дорівнює чи більша 50 (G > 50), то захист необхідно проводити в усіх напрямках.
Якщо загальна оцінка G більша 20, але менша 50 (50 > G > 20), то ймовірність витоку інформації досить велика, необхідно провести часткові оцінки, захист необхідний за окремими напрямками. Якщо загальна оцінка менша 20 (G < 20), то ймовірність витоку інформації мала і додатковий захист інформації можна не проводити. На четвертому етапі проводиться аналіз за допомогою часткових оцінок по всіх 5 пунктах опитувальної анкети. Для одержання часткових оцінок проводять підсумовування часткових коефіцієнтів графи 6 табл. 5, позначених знаком «+», для кожного пункту окремо. При цьому вийде п'ять часткових оцінок:
по пункту 1 - оцінка конкурентоспроможності продукції (послуг)- G,;
по пункту 2 - оцінка ступеня конфіденційності інформації - G2;
по пункту 3 - оцінка тимчасових характеристик конфіденційності інформації - G3;
по пункту 4 - оцінка ЗІ режимними й організаційними методами - G4;
по пункту 5 - оцінка можливості витоку інформації через технічні засоби- Gs.
Якщо часткова оцінка по кожному з пунктів 1-3 дорівнює чи більша 20 (G1,G2,G3 > 20), то це підтверджує необхідність ЗІ.
Якщо часткова оцінка по кожному з пунктів 4,5 дорівнює чи більша 20 (G4 , G5 > 20), то це вказує на необхідність проведення ЗІ режимними й організаційними методами або за допомогою технічних засобів захисту відповідно. У тому випадку, якщо часткова оцінка по одному з пунктів 1-3 менша 20 ( G1, G2, G3 < 20), то ЗІ можна не проводити.
Таким чином, на основі проведених оцінок, керівник фірми приймає рішення про необхідність робіт з організації ЗІ.
Цілком природно, що перед керівником фірми постає інше дуже важливе питання про майбутні витрати на організацію ЗІ. Це питання вирішується за допомогою другої частини методу.
Друга частина методу призначається для визначення орієнтовної оцінки очікуваних витрат, пов'язаних із захистом конфіденційної інформації. У загальному випадку витрати на ЗІ складаються з витрат на проведення організаційно-режимних і технічних заходів. У свою чергу, витрати на технічний захист складаються з витрат на проведення захисту мовної інформації і на захист інших видів інформації, зокрема, дискретної, оброблюваної на ЕОМ, телеграфного, факсимільного й інших видів, використовуваних у діяльності фірми.
Витрати на режимні й організаційні заходи ЗІ визначаються головним чином заробітною платою працівників режимних підрозділів (груп), що забезпечують організацію і контроль режимних заходів, які підвищують безпеку інформації. Розрахунок цих витрат цілком перебуває у віданні керівника фірми й труднощів не викликає. Витрати на
технічну ЗІ складаються з витрат на проведення досліджень, що дають змогу виявити канали витоку інформації, визначити способи її захисту, і з очікуваних витрат на реалізацію технічних рішень захисту.
Розрахунок вартості захисних заходів кожного з видів інформації має деякі особливості, але на етапі орієнтовних розрахунків можна використовувати методику захисту мовної інформації як найбільш просту і загальну. Така методика, що є другою складовою загальної методики оцінки, розроблена і представлена нижче. З огляду на те, що методика призначена для проведення експрес-оцінки вартості ЗІ, що дає змогу керівнику фірми грубо оцінити майбутні витрати, вона максимально спрощена і передбачає проведення елементарних розрахунків. З цією метою все технічне устаткування, що може бути встановлене на об'єкті (фірмі) і через яке можливий витік інформації, умовно розділено на три групи. Критерієм такого розподілу обрана частка (відсоток) витрат на захист устаткування від вартості самого устаткування (техніки). Часткові коефіцієнти (К1, К2, К3), визначені експертним шляхом, та перелік технічного устаткування по групах із зазначенням значень часткових коефіцієнтів витрат на захисні заходи наведено в табл. 6.
У таблиці позначено: С1, С2, С3 - сумарна вартість технічного устаткування відповідної групи, встановленого на об'єкті (фірмі). Значення вартості зразків техніки, які знаходяться в приміщеннях фірми, визначаються за каталогами діючих цін виробника даної
Таблиця 6
техніки. Вартість технічного захисту всього устаткування (Стз), що складається з техніки різних груп, визначається за формулою:
Стз = С1К1 + С2К2 + С3К3.
Зазначимо, що у табл. 6 подано вартість захисту устаткування, не призначеного для передачі, обробки і збереження конфіденційної інформації. Вартість захисту устаткування, призначеного для обробки конфіденційної інформації, визначається індивідуально і може істотно перевищувати зазначену в табл. 6.
Вартість щорічного профілактичного контролю визначається за формулою:
С проф =Кпроф Стз
де С проф =(0,03-0,1) - коефіцієнт витрат на щорічний профілактичний контроль ефективності ЗІ, визначений дослідним шляхом.
Таким чином, знаючи перелік і кількість встановленого на фірмі технічного устаткування і його вартість, можна легко розрахувати очікувані витрати на ЗІ технічними засобами. Додавши витрати на режимні й організаційні заходи ( Сроз) і на профілактичний контроль
у перший рік функціонування, одержимо загальні витрати на ЗІ ( Сзаг ): Сзаг =Стз +С роз +Спроф.
Отже, на основі отриманої величини, а також маючи на увазі прибуткові можливості організації, керівництво приймає рішення щодо певних заходів із захисту інформації в організації.
Не менш важливою є проблема оцінки рівня захищеності уже створеної і навіть функціонуючої СЗІ.
З урахуванням моделей порушника для систем різного призначення і різних вимог повинні існувати різні критерії оцінки достатності захисних заходів. Порушник-професіонал може перебувати поза об'єктом захисту, і йому спочатку необхідно подолати контрольовану межу об'єкта. Порушник-користувач уже має певні повноваження щодо санкціонованого доступу до інформації відповідно до своїх функціональних обов'язків і завдань.
Аналіз об'єктів АС починається з визначення можливих каналів НСД (МКНСД). Найбільш об'єктивним процесом оцінки доцільно розглянути МКНСД, що очікуються від кваліфікованого порушника-професіонала, який знаходиться на початковій позиції поза об'єктом захисту. У такому разі оцінка буде відрізнятися меншою кількістю МКНСД, ніж у порушника більш низького класу, а також імовірністю подолання порушником захисних бар'єрів, кількістю шляхів, імовірностями їх обходу.
Після того як для обраної моделі порушника визначено всі МКНСД і на них встановлено засоби захисту, вважається, що віртуальний контур
захисту замкнуто. Тоді для контрольованого МКНСД визначається його вразливість, величина якої буде дорівнювати вразливості найбільш слабкої ланки захисного контуру, для чого використовуємо формулу
(7.1)
де РВбл - імовірність виявлення і блокування несанкціонованих дій порушника, Рвідм - імовірність відмови системи, Робхj- імовірність обходу порушником j-i перешкоди. Ця формула виражає вразливість захисту К-і ланки захисту шляхом порівняння імовірностей і вибору однієї з них. При цьому для МКНСД, які закриті двома або більше засобами захисту, розрахунок вразливості ланки здійснює за формулою
(7.2)
де т - кількість дублюючих перешкод, Pt - вразливість і-ї перешкоди. Для неконтрольованих МКНСД розрахунок здійснюється за формулою
(7.3)
де j - кількість шляхів обходу.
Оцінка вразливості системи ідентифікації та автентифікації (СІА) здійснюється за формулою (7.1) з урахуванням таких параметрів.
Імовірність подолання перешкоди порушником з боку законного введення в систему.
Імовірність виявлення і блокування НСД в системі СІА. Вона визначається можливістю відповідної програми до відпрацювання даної функції у випадку розбіжності.
Оцінка вразливості системи розмежування і контролю доступу у приміщення об'єкта захисту Рпр, визначається виходячи з технічних даних вхідного замка на дверях приміщення, режиму роботи КСА, наявності охоронної сигналізації і значення її параметрів. При цілодобовому режимі роботи, як правило, обмежуються кодовим замком на дверях. При перервах у роботі, коли у приміщенні нікого не повинно бути, апаратура вимикається, приміщення ставиться на дистанційний централізований контроль охоронної сигналізації (про оцінку її вразливості йтиметься нижче).
Імовірність обходу перешкоди порушником Робх слід оцінювати безпосередньо на місці, тобто шляхом огляду приміщення на предмет вразливості стін і відсутності сторонніх люків, пошкоджень стін, стелі, вікон. Особливу увагу необхідно звернути на розміщення вікон і конструкцію їх рам, кватирок, замків, поверховість приміщення, вентиляцію. Якщо приміщення знаходиться на першому поверсі, на вікнах необхідно перевірити установку датчиків охоронної сигналізації.
• При оцінці вразливості системи контролю виведення апаратури з робочого контуру обміну інформацією під час ремонту і профілактики технічних засобів вважається, що спроба порушника, який знаходиться в зоні об'єктів АС, що відрізняється від зони робочого місця функціонального контролю (РМФК), ввести його знову в робочий контур АС малоймовірна. Значить, можна прийняти Рпр = 0. Але можливість обходу цього заходу в порушника існує.
Як показує практика, найбільш вразливим місцем для НСД є носії ПЗ і носії інформації. Цьому сприяє уніфікована конструкція носіїв, відносно невеликі габаритні розміри і маса, великі обсяги інформації, яка зберігається на них, збереження і транспортування на них ОС і прикладних програм.
Особливістю засобів захисту інформації на носіях є необхідність враховувати (залежно від технічного завдання) імовірність потрапляння носія з інформацією за межі об'єкта захисту, в зону, де відсутні засоби виявлення і блокування НСД. Вразливість захисту в таких випадках повинна збільшуватись і досягати такої величини, коли час подолання захисту порушником буде більшим, ніж час життя інформації, яка розміщена на носіях. Тому оцінка повинна проводитися за окремим показником.
Для захисту інформації і ПЗ на носіях використовуються організаційні, апаратні, програмні і криптографічні засоби.
Вразливість засобів захисту від ПЕВМН оцінюється ймовірністю перехоплення інформації порушником, який знаходиться за межами території об'єкта захисту, оскільки критерієм можливого перехоплення є відношення «сигнал-шум» на межі об'єкта захисту. Величини ймовірності визначають досвідчені спеціалісти шляхом аналізу засобів захисту, вимірювання сигналу і спеціальних досліджень.
Засоби реєстрації звертань до інформації, яку необхідно захищати, є достатньо ефективним заходом, який також потребує оцінки якості: виконання програми реєстрації (чи всі звертання реєструються, з якими атрибутами), імовірності її обходу користувачем-порушником, можливості прихованого відключення, часу роботи, безвідмовності.
Однак реєстрація подій з відкладеним виявленням більше служить для профілактичних цілей і подальшого аналізу конкретної ситуації, у зв'язку з чим цей захід слід вважати хоча й обов'язковим, але все ж резервним, тобто тим, що дублює інші заходи захисту.
Засоби управління захистом інформації в АС виконують функції захисту і є важливою складовою засобів захисту. Управління забезпечує функції контролю, виявлення і блокування НСД, а також безперебійне функціонування апаратних, програмних і організаційних засобів захисту, ведення статистики і прогнозування подій. Усі ці параметри враховуються при оцінці вразливості окремих засобів захисту АС. У результаті оцінка ефективності засобів управління
захистом може проводитися лише з якісного боку на предмет реалізації захисту як єдиного механізму - СЗІ в технічному сенсі розв'язання задачі: технології управління, складу апаратних і програмних засобів управління і організаційних заходів, наявності централізації контролю і управління захистом.
Така оцінка необхідна для визначення ступеня наближення отриманих значень вразливості захисту до дійсних. Чим більше автоматизованих засобів захисту, тим менше експертних оцінок, достовірніші оцінки і вищі гарантії ефективності захисту.
Складність і масштаби сучасних систем захисту не дають змоги проводити експерименти з ними, а експерименти з окремими елементами не дозволяють отримати уявлення про цілісні властивості систем. Розв'язання задач оцінки ефективності захисту ускладнюється тим, що в будь-якій системі захисту основною ланкою є людина. Крім того, великі проблеми при створенні точних аналітичних методів розрахунку й оцінки ефективності роботи систем захисту полягають у визначенні складних залежностей між середовищем функціонування АС, станом джерел інформації та системою захисту.
Залежно від співвідношення ресурсів, що виділяються на захист, та очікуваних результатів від її розв'язання задача синтезу оптимальних СЗІ може формулюватися в таких формах:
При фіксованому рівні витрат ресурсів забезпечити максимально можливий рівень захищеності.
При фіксованому рівні захищеності мінімізувати витрати на захист.
Однак сьогодні техніко-економічна оптимізація систем захисту -дуже складна і далека від вирішення проблема. Незважаючи на це, вона все ж має переваги, а саме:
можливість отримання коректного математичного розв'язку задачі за обраним критерієм якості;
можливість за допомогою сформульованих обмежень зрозуміти суть реальних процесів захисту;
виявити в процесі оптимізації протиріччя у вимогах до системи захисту;
можливість давати прогнозні оцінки у разі зміни умов функціонування;
• підвищити ефективність управління системою захисту.До недоліків оптимізації систем захисту слід віднести:
складність математичної постановки задач проектування оптимальної системи захисту;
суттєву залежність якості оптимальної системи захисту від точності вихідних припущень та характеру змін в об'єктах АС.