Інформаційною основою якої-небудь великої організації є мережа, тому в число апаратних активів варто включити комп'ютери (сервери, робочі станції, ПК), периферійні пристрої, зовнішні інтерфейси, кабельне господарство, активне мережеве устаткування (мости, маршрутизатори й т.п.). До програмних активів, імовірно, будуть віднесені операційні системи (мережева, сервери! й клієнтські), прикладне програмне забезпечення, інструментальні засоби, де (у яких вузлах мережі) зберігається програмне забезпечення, і з яких вузлів воно використовується. Третім видом інформаційних активів є дані, які зберігаються, обробляються й передаються по мережі. Варто класифікувати дані по типах і ступеню конфіденційності, виявити місця їхнього зберігання й обробки, способи доступу до них. Все це важливо для оцінки наслідків порушень інформаційної безпеки.
Керування ризиками - процес далеко не лінійний. Практично всі його етапи пов'язані між собою, і по завершенню майже кожного з них може виникнути необхідність повернення до попереднього. Так, при ідентифікації активів може виявитися, що обрані межі аналізу варто розширити, а ступінь деталізації - збільшити. Особливо складний первинний аналіз, коли багаторазові повернення до початку неминучі.
5.3. Основні етапи керування ризиками
Етапи, що передують аналізу загроз, можна вважати підготовчими, оскільки прямого зв'язку з ризиками вони не мають. Ризик з'являється там, де є загрози.
Короткий перелік найпоширеніших загроз був розглянутий нами раніше. На жаль, на практиці загроз набагато більше, причому далеко не всі вони носять комп'ютерний характер. Так, цілком реальною загрозою є наявність мишей і тарганів у займаних організацією приміщеннях. Перші можуть зашкодити кабелю, другі викликати коротке замикання. Як правило, наявність тієї або іншої загрози є наслідком недоліків у захисті інформаційної системи, які, у свою чергу, характеризуються відсутністю деяких сервісів безпеки або недоліками в реалізуючих їх захисних механізмах. Небезпека прогризання кабелів виникає не просто там, де с миші, вона пов'язана з відсутністю або недостатньою міцністю захисної оболонки.
Перший крок в аналізі загроз - їхня ідентифікація. Розглянуті види загроз варто вибирати виходячи з міркувань здорового глузду (відкинувши, наприклад, землетрус, однак не забуваючи про можливості захоплення організації терористами), але в межах обраних видів провести максимально докладний аналіз.
Доцільно виявляти не тільки самі загрози, але й джерела їхнього виникнення - це допоможе у виборі додаткових засобів захисту. Наприклад, нелегальний вхід у систему може стати наслідком відтворення початкового діалогу, підбору паролю або підключення до мережі неавторизованого устаткування. Очевидно, для протидії кожному з перерахованих способів нелегального входу потрібні свої механізми безпеки.
Після ідентифікації загрози необхідно оцінити ймовірність її здійснення, Можливе використання при цьому трибальної шкали (низька (1), середня (2) і висока (3) ймовірність).
Крім ймовірності здійснення, важливим є розмір потенційного збитку. Наприклад, пожежі бувають нечасто, але збиток від кожної з них, як правило, великий. Розмір збитку також можна оцінити за трибальною шкалою.
Оцінюючи розмір збитку, необхідно мати на увазі не тільки безпосередні витрати на заміну устаткування або відновлення інформації, але й більш віддалені, такі як підрив репутації, ослаблення позицій на ринку й т.п. Нехай, наприклад, у результаті дефектів у керуванні доступом до бухгалтерської інформації співробітники одержали можливість корегувати дані про власну заробітну платню. Наслідком такого стану справ може стати не тільки перевитрата бюджетних або корпоративних засобів, але й повне розкладання колективу, що може призвести до розвалу організації.
Уразливі місця мають властивість притягати до себе не тільки зловмисників, але й порівняно чесних людей. Не кожен тримається перед спокусою дещо збільшити свою зарплатню, якщо є впевненість, що це тобі минеться. Тому, оцінюючи ймовірність здійснення загроз, доцільно виходити не тільки із середньостатистичних даних, але враховувати також специфіку конкретних інформаційних систем. Якщо в підвалі будинку, займаного організацією, розташовується сауна, а сам будинок має дерев'яні перекриття, то ймовірність пожеж, на жаль, виявиться істотно вище середнього.
Після того, як накопичені вихідні дані й оцінений ступінь невизначеності, можна переходити до обробки інформації, тобто власне до оцінки ризиків. Цілком припустимо застосовувати такий простий метод, як множення ймовірності здійснення загрози на передбачуваний збиток. Якщо для ймовірності й збитку використовувати трибальну шкалу, то можливих добутків буде шість: 1, 2, 3, 4, 6 й 9. Перші два результати можна віднести до низького ризику, третій і четвертий - до середнього, два останні - до високого, після чого з'являється можливість знову привести їх до трибальної шкали. По цій шкалі й варто оцінювати прийнятність ризиків. Щоправда, граничні випадки, коли обчислювальна величина збіглася із прийнятною, доцільно розглядати більш ретельно через наближений характер результату.
Якщо які-небудь ризики виявилися неприпустимо високими, необхідно їх нейтралізувати, реалізувавши додаткові заходи захисту. Як правило, для ліквідації або нейтралізації уразливого місця, що зробило загрозу реальною, існує кілька механізмів безпеки, різних за ефективністю й вартістю. Наприклад, якщо велика ймовірність нелегального входу в систему, можна зажадати, щоб користувачі обирали довгі паролі (скажемо, не менше восьми символів), задіяти програму генерації паролів або закупити інтегровану систему аутентифікації на основі інтелектуальних карт. Якщо є ймовірність навмисного ушкодження сервера баз даних, що може мати серйозні наслідки, можна урізати замок у двері серверної кімнати або поставити біля кожного сервера по охоронцю.
Оцінюючи вартість засобів захисту, доводиться, зрозуміло, ураховувати не тільки прямі витрати на закупівлю устаткування й/або програм, але й витрати на впровадження новинки й, зокрема, навчання й перепідготовку персоналу. Цю вартість також можна оцінити по трибальній шкалі й потім зіставити її з різницею між обчисленим і припустимим ризиком. Якщо за цього показника новий засіб виявляється економічно вигідним, його можна взяти на замітку (підходящих засобів, імовірно, буде декілька). Однак якщо засіб виявиться дорогим, його не слід відразу відкидати, пам'ятаючи про наближення розрахунку.
Вибираючи підходящий спосіб захисту, доцільно враховувати можливість екранування одним механізмом забезпечення безпеки відразу декількох прикладних сервісів. Так зробили в Масачусетському технологічному інституті, захистивши кілька тисяч комп'ютерів сервером аутентифікації КегЬегоз.
Важливою обставиною є сумісність нового засобу зі сформованою організаційною й апаратно-програмною структурою, із традиціями організації. Заходи безпеки, як правило, носять недружній характер, що може негативно позначитися на ентузіазмі співробітників. Часом збереження духу відкритості важливіше мінімізації матеріальних втрат. Втім, такого роду орієнтири повинні бути розставлені в політиці безпеки верхнього рівня.
Можна уявити собі ситуацію, коли для нейтралізації ризику не існує ефективних і прийнятних за ціною заходів. Наприклад, компанія, що базується в сейсмічно небезпечній зоні, не завжди може дозволити собі будівництво захищеної штаб-квартири. У такому випадку доводиться піднімати межу прийнятного ризику й переносити центр ваги на пом'якшення наслідків і вироблення планів відновлення після аварій, стихійних лих та інших подій. Продовжуючи приклад із сейсмобезпекою, можна рекомендувати регулярне тиражування даних в інше місто й володіння засобами відновлення первинної бази даних.
Як і будь-яку іншу діяльність, реалізацію й перевірку нових регуляторів безпеки варто попередньо планувати. У плані необхідно врахувати наявність фінансових засобів і строки навчання персоналу. Якщо мова йде про програмно-технічний механізм захисту, потрібно скласти план тестування (автономного й комплексного).
Коли заплановані заходи впроваджені, необхідно перевірити їхню дієвість, тобто переконатися, що залишкові ризики стали прийнятними. Якщо це насправді так, виходить, можна спокійно намічати дату найближчої переоцінки. У іншому випадку доведеться проаналізувати допущені помилки й провести повторний сеанс керування ризиками негайно.
Розділ 6. Процедурний рівень інформаційної безпеки
6.1. Основні класи заходів процедурного рівня
Ми приступаємо до розгляду заходів безпеки, які орієнтовані на людей, а не на технічні засоби. Саме люди формують режим інформаційної безпеки, і вони ж виявляються головною загрозою, тому "людський чинник" заслуговує на особливу увагу.
В українських компаніях накопичений багатий досвід регламентування й реалізації процедурних (організаційних) заходів, однак справа в тому, що вони прийшли з "докомп'ютерного" минулого, тому вимагають переоцінки.
Варто усвідомити той ступінь залежності від комп'ютерної обробки даних, у яку потрапило сучасне суспільство. Без усякого перебільшення можна сказати про необхідність інформаційної цивільної оборони. Спокійно, без перебільшення, потрібно пояснювати суспільству не тільки переваги, але й небезпеки, пов'язані з використанням інформаційних технологій. Акцент варто робити не на військовій або кримінальній стороні справи, а на цивільних аспектах, пов'язаних з підтримкою нормального функціонування апаратного й програмного забезпечення, тобто концентруватися на питаннях доступності й цілісності даних.
На процедурному рівні можна виділити наступні класи заходів:
керування персоналом;
фізичний захист;
підтримка працездатності;
реагування на порушення режиму безпеки; » планування відновлювальних робіт.
6.2. Керування персоналом
Керування персоналом починається із прийому нового співробітника на роботу й навіть раніше - зі складання посадових інструкцій. Уже на даному етапі бажано підключити до роботи фахівця з інформаційної безпеки для визначення комп'ютерних привілеїв, асоційованих з посадою. Існує два загальних принципи, як: варто мати на увазі:
розподіл обов'язків;
мінімізація привілеїв.
Принцип розподілу обов'язків пропонує так розподіляти ролі й відповідальність, щоб одна людина не могла порушити критично важливий для організації процес. Наприклад, небажана ситуація, коли великі платежі від імені організації виконує одна людина. Надійніше доручити одному співробітникові оформлення заявок на подібні платежі, а іншому - завіряти ці заявки. Інший приклад - процедурні обмеження дій суперкористувача. Можна штучно "відокремити" пароль суперкористувача, повідомивши першу його частину одному співробітникові, а другу - іншому. Тоді критично важливі дії з адміністрування ІС вони зможуть виконати тільки вдвох, що знижує ймовірність помилок і зловживань.
Принцип мінімізації привілеїв пропонує виділяти користувачам тільки ті права доступу, які необхідні їм для виконання службових обов'язків. Призначення цього принципу очевидно - зменшити збиток від випадкових або навмисних некоректних дій.
Попереднє складання опису посади дозволяє оцінити її критичність і спланувати процедуру перевірки й відбору кандидатів. Що відповідальніше посада, тим ретельніше потрібно перевіряти кандидатів: навести про них довідки, можливо, поговорити з колишніми товаришами по службі й т.д. Подібна процедура може бути тривалою й дорогою, тому немає сенсу додатково ускладнювати її. У той же час, нерозумно й зовсім відмовлятися від попередньої перевірки, щоб випадково не прийняти на роботу людину з карним минулим або психічним захворюванням.
Коли кандидат визначений, він, імовірно, повинен пройти навчання; принаймні, його варто докладно ознайомити зі службовими обов'язками, а також з нормами й процедурами інформаційної безпеки. Бажано, щоб заходи безпеки були ним засвоєні до вступу на посаду й до введення його системного рахунку із вхідним ім'ям, паролем та привілеями.
З моменту введення системного рахунку починається його адміністрування, а також протоколювання й аналіз дій користувача. Поступово змінюється оточення, у якому працює користувач, його службові обов'язки й т.п. Все це вимагає відповідної зміни привілеїв. Технічну складність представляють тимчасові переміщення користувача, виконання ним обов'язків замість співробітника, що пішов у відпустку, і інші обставини, коли спочатку потрібно надати повноваження, а через деякий час обмежити. У такі періоди профіль активності користувача різко змінюється, що створює труднощі при виявленні підозрілих ситуацій. Певної акуратності варто дотримуватися й при видачі нових постійних повноважень, не забуваючи ліквідувати старі права доступу.
Ліквідація системного рахунку користувача, особливо у випадку конфлікту між співробітником та організацією, повинна вироблятися максимально оперативно (в ідеалі - одночасно з повідомленням про покарання або звільнення). Можливе й фізичне обмеження доступу до робочого місця. Зрозуміло, якщо співробітник звільняється, у нього потрібно прийняти все його комп'ютерне господарство й, зокрема, криптографічні ключ?, якщо використовувалися засоби шифрування.
До керівництва співробітниками додається адміністрування осіб, що працюють за контрактом (наприклад, фахівців фірми-постачальника, що допомагають запустити нову систему). Відповідно до принципу мінімізації привілеїв, їм потрібно виділити рівно стільки прав, скільки необхідно, і забрати ці права відразу по закінченні контракту. Проблема, однак, полягає в тому, що на початковому етапі впровадження "зовнішні" співробітники будуть адмініструвати "місцевих", а не навпаки. Тут на перший план виходить кваліфікація персоналу організації, його здатність швидко навчатися, а також оперативне проведення навчальних курсів. Важливі й принципи вибору ділових партнерів.
Іноді зовнішні організації приймають на обслуговування й адміністрування відповідальні компоненти комп'ютерної системи, наприклад, мережеве устаткування. Нерідко адміністрування виконується у вилученому режимі. Загалом кажучи, це створює в системі додаткові уразливі місця, які необхідно компенсувати посиленим контролем засобів вилученого доступу або навчанням власних співробітників.
Ми бачимо, що проблема навчання - одна з основних з погляду інформаційної безпеки. Якщо співробітник не знайомий з політикою безпеки своєї організації, він не може прагнути до досягнення сформульованих у ній цілей. Не знаючи заходів безпеки, він не зможе їх дотримуватися. Навпаки, якщо співробітник знає, що його дії протоколюються, він, можливо, утримається від порушень.
5.2. Підготовчі етапи керування ризиками
У цьому розділі будуть описані перші три етапи процесу керування ризиками.
Вибір аналізованих об'єктів і рівня деталізації їхнього розгляду - перший крок в оцінці ризиків. Для невеликої організації припустимо розглядати всю інформаційну інфраструктуру; однак якщо організація велика, всеохоплююча оцінка може вимагати неприйнятних витрат часу й сил. У такому випадку варто зосередитися на найбільш важливих сервісах, заздалегідь погоджуючись із наближеністю підсумкової оцінки. Якщо важливих сервісів усе ще багато, вибираються ті з них, ризики для яких свідомо великі або невідомі.
Ми вже вказували на доцільність створення карти інформаційної системи організації. Для керування ризиками подібна карта особливо важлива, оскільки вона наочно показує, які сервіси обрані для аналізу, а якими довелося знехтувати. Якщо ІС змінюється, а карта підтримується в актуальному стані, то при переоцінці ризиків відразу стане ясно, які нові або істотно змінені сервіси мають потребу в розгляді.
Загалом кажучи, уразливим є кожен компонент інформаційної системи -від мережевого кабелю, який можуть прогризти миші, до бази даних, що може бути зруйнована через невмілі дії адміністратора. Як правило, у сферу аналізу неможливо включити кожен гвинтик і кожен байт. Доводиться зупинятися на деякому рівні деталізації, усвідомлюючи наближеність оцінки. Для нових систем кращий детальний аналіз; стара система, яка піддається незначним модифікаціям, може бути проаналізована більш поверхнево.
Дуже важливо вибрати розумну методологію оцінки ризиків. Метою оцінки є одержання відповіді на два питання: чи прийнятні існуючі ризики, і якщо ні, то які захисні засоби варто використовувати. Виходить, оцінка повинна бути кількісною, що допускає зіставлення із заздалегідь обраними межами допустимості й витратами на реалізацію нових регуляторів безпеки. Керування ризиками - типова оптимізація завдання, й існує досить багато програмних продуктів, здатних допомогти в її вирішенні (іноді подібні продукти просто додаються до книг з інформаційної безпеки). Принципові труднощі, однак, складаються в неточності вихідних даних. Можна, звичайно, спробувати одержати для всіх аналізованих величин грошовий вираз, вирахувати все з точністю до копійки, але особливого сенсу в цьому немає. Практичніше користуватися умовними одиницями. У найпростішому й цілком припустимому випадку можна користуватися трибальною шкалою. Далі ми продемонструємо, як це робиться.
При ідентифікації активів, тобто тих ресурсів і цінностей, які організація намагається захистити, треба, звичайно, ураховувати не тільки компоненти інформаційної системи, але й підтримуючу інфраструктуру, персонал, а також нематеріальні цінності, такі як репутація організації. Відправною крапкою тут є уявлення про місію організації, у будь-якому випадку напрямки діяльності, які бажано (або необхідно) зберегти в кожному разі. Висловлюючись об'єктно-орієнтованою мовою, треба в першу чергу описати зовнішній інтерфейс організації, розглянутої як абстрактний об'єкт.
Одним з головних результатів процесу ідентифікації активів є одержання детальної інформаційної структури організації й способів її (структури) використання. Ці відомості доцільно нанести на карту ІС як межі відповідних об'єктів.
|