Адміністративний рівень інформаційної безпеки

Основні поняття

До адміністративного рівня інформаційної безпеки відносяться дії

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

Політика безпеки

З практичної точки зору політику безпеки доцільно розглядати на трьох

рівнях деталізації. До верхнього рівня відносять рішення, що відносяться до
всієї організації в цілому. Вони мають загальний характер і, як правило
виходять від керівництва організації. Приблизний список таких рішень може
містити такі елементи:
• рішення сформувати або переглянути комплексну програму забезпечення
інформаційної безпеки, призначення осіб, відповідальних за просування
програми;
 формулювання цілей, котрі ставить організація в галузі захисту інформації,
визначення загальних напрямів досягнення цих цілей;
 забезпечення бази для дотримання законів і правил;
 формулювання адміністративних рішень з тих питань реалізації програми
безпеки, які повинні розглядатись на рівні організації в цілому.
Для політики верхнього рівня цілі організації в галузі інформаційної безпеки
формулюються в термінах доступності, цілісності і конфіденційності. Якщо для
організації важливим є підтримання критично важливих баз даних, то на
першому плані може стояти зменшення кількості втрат, ушкоджень або
спотворення даних. Для організації, яка продає комп’ютерну техніку, ймовірно,
важливою є актуальність інформації про надавані послуги та ціни і її
доступність максимальному числу потенційних користувачів. Керівництво ж
режимного підприємства повинно в першу чергу дбати про захист від
несанкціонованого доступу, тобто про конфіденційність.
На верхній рівень виноситься управління захисними ресурсами та
координація використання цих ресурсів, виділення спеціального персоналу для
захисту критично важливих систем і взаємодія з іншими організаціями, що
забезпечують або контролюють режим безпеки.
Політика верхнього рівня повинна чітко окреслювати сферу свого впливу.
Це можуть бути всі комп’ютерні системи організації (або навіть більше, якщо
політика регламентує деякі аспекти використання співробітниками своїх
домашніх комп’ютерів). Можливою є така ситуація, коли в сферу впливу
залучаються лише найважливіші системи.
В політиці повинні бути визначені обов’язки посадових осіб з вироблення
програми безпеки і втілення її в життя. В цьому сенсі політика безпеки є
основою підзвітності персоналу.
Політика верхнього рівня має справу з трьома аспектами
законопослушності та виконавчої дисципліни. По-перше, організація повинна
дотримуватись існуючих законів. По-друге, слід контролювати дії осіб,
відповідальних за вироблення програми безпеки. По-третє, необхідно
забезпечити певний ступінь виконавчої дисципліни персоналу, а для цього
треба розробити систему заохочень та покарань.
Зазначимо, що на верхній рівень слід виносити мінімум питань. Таке
винесення є доцільним, коли воно обіцяє значну економію засобів або коли
інакше чинити просто неможливо.
До середнього рівня можна віднести питання, які стосуються окремих
питань інформаційної безпеки, що є важливими для різних систем, які
експлуатуються організацією. Приклади таких питань - ставлення до
передових (але, можливо, недостатньо перевірених) технологій, доступ до
Internet (як сумістити свободу доступу до інформації з захистом від зовнішніх
загроз?), використання домашніх комп’ютерів, застосування користувачами
неофіційного програмного забезпечення, тощо.
Політика середнього рівня повинна висвітлювати такі питання:
Опис аспекту. Наприклад, якщо розглядається застосування користувачами
неофіційного програмного забезпечення, його можна визначити як програмне
забезпечення, яке не було схвалено і/або закуплено на рівні організації.
Галузь застосування. Слід визначити, де, як, стосовно кого і чого
застосовується дана політика безпеки. Наприклад, чи стосується політика,
пов’язана з застосування користувачами неофіційного програмного
забезпечення, організацій-субпідрядників? Чи зачіпає вона співробітників, які
користуються портативними і домашніми комп’ютерами і переносять
інформацію на виробничі машини?
Позиція організації з даного аспекту. На прикладі застосування
користувачами неофіційного програмного забезпечення можна уявити собі
позиції повної заборони, вироблення процедури приймання такого програмного
забезпечення, тощо. Позиція може сформульована і в найзагальнішому вигляді,
як набір цілей, які переслідує організація в даному аспекті. Стиль документів,
що визначають політику безпеки і їх перелік в різних організаціях можуть
значно відрізнятись.
Ролі і обов’язки. До документу необхідно включити інформацію про
посадових осіб, відповідальних за реалізацію політики безпеки. Наприклад,
якщо для застосування неофіційного програмного забезпечення
співробітникам потрібно отримати дозвіл керівництва, повинно бути відомо, у
кого і як його можна отримати. Якщо ж неофіційне програмне забезпечення
застосовувати заборонено, необхідно знати, хто контролює дотримання даного
правила.
Законослухняність. Політика повинна містити загальний опис заборонених дій
і покарань за них.
Точки контакту. Повинно бути відомо, куди слід звертатись за роз’ясненнями,
допомогою і додатковою інформацією. Звичайно “точкою контакту” є певна
посадова особа, а не конкретна людина, що посідає в даний момент даний пост.
Політика безпеки нижнього рівня стосується окремих інформаційних
сервісів. Вона містить два аспекти – цілі і правила їх досягнення, через що її
буває важко відділити від питань реалізації. На відміну від двох верхніх рівнів
політика нижнього рівня повинна бути визначена детальніше. Багато питань,
що є специфічними для окремих видів послуг, не можна однаково
регламентувати в рамках всієї організації. Але ці питання є настільки
важливими для забезпечення режиму безпеки, що рішення з них повинні
прийматись на управлінському, а не технічному рівні. Наведемо приклади
питань, на які слід дати відповіді в політиці безпеки нижнього рівня:
• хто має право доступу до об’єктів, що підтримуються сервісом?
• за яких умов можна читати і модифікувати дані?
• як організовано віддалений доступ до сервісу?
При формулюванні цілей політики безпеки нижнього рівня можна
керуватись міркуваннями цілісності, доступності і конфіденційності. Але цього
недостатньо. Її цілі повинні бути конкретнішими. Наприклад, якщо мова йде
про систему розрахунку заробітної платні, можна поставити мету, щоб тільки
співробітникам відділів кадрів і бухгалтерії дозволялось вводити і
модифікувати інформацію. В загальному випадку цілі повинні зв’язувати між
собою об’єкти сервісу і дії з ними.
З цілей виводяться правила безпеки, які описують, хто, що і за яких умов
може робити. Чим детальнішими є правила, чим формальніше їх викладено,
тим простіше підтримувати їх виконання програмно-технічними засобами. З
іншого боку, надто жорсткі правила можуть заважати роботі користувачів, тому
ймовірно, їх доведеться часто переглядати. Керівництву належить знайти
розумний компроміс, коли за прийнятну ціну буде забезпечено прийнятний
рівень безпеки, а співробітники не виявляться занадто зв’язаними. Звичайно
через особливу важливість найбільш формально задаються права доступу до
об’єктів.
 Програма безпеки

Після формулювання політики безпеки можна приступати до складення

програми її реалізації і до власне реалізації.
Щоб реалізувати будь-яку програму, її потрібно структурувати за
рівнями, звичайно згідно структури організації. В найпростішому і
найпоширенішому випадку цілком достатньо двох рівнів – верхнього або
центрального, який охоплює всю організацію, і нижнього або службового, який
стосується окремих послуг або груп однорідних сервісів.
Програму верхнього рівня очолює особа, яка відповідає за інформаційну
безпеку організації. Ця програма має такі головні цілі:
 управління ризиками (оцінка ризиків, вибір ефективних засобів захисту);
 координація діяльності в галузі інформаційної безпеки, поповнення і
розподіл ресурсів;
 стратегічне планування;
 контроль діяльності в галузі інформаційної безпеки .
В рамках програми верхнього рівня приймаються стратегічні рішення з
забезпечення безпеки, оцінюються технологічні новинки. Інформаційні
технології розвиваються дуже швидко, тому необхідно мати чітку політику
відслідковування і впровадження нових засобів.
Контроль діяльності в галузі безпеки має двобічну направленість. По-
перше, необхідно гарантувати, що дії організації не суперечать законам. При
цьому треба підтримувати контакти з зовнішніми контролюючими
організаціями. По-друге, потрібно постійно відслідковувавти стан безпеки
всередині організації, реагувати на випадки порушень і допрацьовувати захисні
заходи з врахуванням змін обстановки.
Зазначимо що, програма верхнього рівня повинна займати чітко
визначене місце в діяльності організації, вона повинна офіційно прийматись і
підтримуватись керівництвом, мати певний штат і бюджет.
Метою програми нижнього рівня є забезпечення надійного і
економічного захисту конкретного сервісу або групи однорідних сервісів. На
цьому рівні вирішують, які механізми захисту слід використовувати,
закуповують і встановлюють технічні засоби, виконують повсякденне
адміністрування, відслідковують стан слабкі місця, тощо. Звичайно за програму
нижнього рівня відповідають адміністратори сервісів.

Синхронізація програми безпеки

з життєвим циклом систем

Можна добитися більшого ефекту з меншими затратами якщо синхронізувати

програму безпеки нижнього рівня з життєвим циклом сервісу, що захищається.
Звичайно додати нову можливість до вже готової системи на порядок
складніше, ніж початково спроектувати і реалізувати її. Це стосується і
інформаційної безпеки.
 В життєвому циклі інформаційного сервісу можна виділити такі етапи:
Ініціація. На цьому етапі виявляється необхідність придбання нового сервісу,
документується його передбачуване призначення.
Закупівля. На цьому етапі складаються специфікації, проробляються
варіанти придбання, здійснюється власне закупівля.
Встановлення. Сервіс встановлюється, конфігурується, тестується і
вводиться в експлуатацію.
Експлуатація. На цьому етапі сервіс не тільки працює і адмініструється, але
й піддається модифікаціям.
Виведення з експлуатації. Відбувається перехід на новий сервіс.
Розглянемо детальніше дії, що виконуються на кожному з етапів.
На етапі ініціації оформляється розуміння того, що необхідно придбати
новий або значно модернізувати існуючий сервіс; визначаться, які
характеристики і яку функціональність він повинен мати; оцінюються
фінансові та інші обмеження.
З точки зору безпеки найважливішою дією тут є оцінка критичності як
самого сервісу, так і інформації, яка буде оброблятися з його допомогою.
Необхідно сформулювати відповіді на такі питання:
 якого роду інформація призначається для обробки новим сервісом?
 якими є можливі наслідки порушення цілісності, доступності і
конфіденційності інформації?
 якими є загрози стосовно яких сервіс і інформація будуть найвразливішими?
 чи є які-небудь особливості нового сервісу (наприклад, територіальна
розподіленість компонентів), що вимагають вжиття спеціальних
процедурних заходів?
 якими є характеристики персоналу, які мають відношення до безпеки
(кваліфікація, благонадійність)?
 якими є законодавчі положення і внутрішні правила, яким повинен
відповідати новий сервіс?
Результати оцінки критичності є точкою відліку при складенні
специфікацій. Крім того, вони визначають міру уваги, яку служба безпеки
організації повинна приділяти новому сервісу на наступних етапах його
життєвого циклу.
Етап закупівлі є одним з найскладніших. Потрібно остаточно
сформулювати вимоги до захисних засобів нового сервісу, до компанії, яка
може претендувати на роль постачальника, і до кваліфікації, яку повинен мати
персонал, що використовує або обслуговує закуповуваний продукт. Всі ці
відомості оформляються у вигляді специфікації, куди входять не лише
апаратура і програми, але й документація, обслуговування, навчання персоналу.
Особливу увагу слід приділити питанням сумісності нового сервісу з існуючою
конфігурацією. Зазначимо, що засоби безпеки часто не є необов’язковими
компонентами комерційних продуктів, і тому треба прослідкувати, щоб
відповідні пункти не випали з специфікації. .
Встановлення є дуже відповідальним етапом. Коли продукт закуплено, його
необхідно встановити.
По-перше, новий продукт необхідно сконфігурувати. Як правило,
комерційні продукти поставляються з відключеними засобами безпеки, їх
необхідно включити і належно налаштувати. Для великих організацій, де є
багато користувачів і даних, початкове налаштування може бути досить
трудомісткою і відповідальною справою.
По-друге, новий сервіс потребує процедурних регуляторів. Слід подбати
про чистоту і охорону приміщення, про документи, що регламентують
використання сервісу, про підготовку планів на випадок екстрених ситуацій,
про організацію навчання користувачів, тощо.
Після вжиття перелічених заходів необхідно здійснити тестування. Його
повнота і комплексність можуть служити гарантією безпеки експлуатації в
штатному режимі.
Етап експлуатації є найтривалішим і найскладнішим. З психологічної
точки зору найбільшу небезпеку становлять незначні зміни в конфігурації
сервісу, в поведінці користувачів і адміністраторів. Якщо безпеку не
підтримувати, вона слабне. Користувачі не так ретельно виконують посадові
інструкції, адміністратори менш старанно аналізують реєстраційну інформацію.
То той то інший користувач отримують додаткові привілеї. Ніби нічого не
змінилось, але насправді від колишньої безпеки не залишилось і сліду. Для
боротьби з ефектом повільних змін доводиться застосовувати періодичні
перевірки безпеки сервісу. Очевидно, після значних модифікацій такі перевірки
є обов’язковими.
Виведення з експлуатації стосується апаратно-програмних компонент
сервісу і оброблюваних ним даних. Апаратура продається, утилізується або
викидається. Тільки в специфічних випадках необхідно потурбуватись про
фізичне руйнування апаратних компонент, які зберігають конфіденційну
інформацію. Програми просто стираються, якщо ліцензійна угода не
передбачає іншого варіанту. При виведенні даних з експлуатації їх звичайно
переносять на іншу систему, архівують, викидають або просто знищують. Якщо
архівування здійснюється з наміром в подальшому прочитати дані в іншому
місці, необхідно потурбуватись про апаратно-програмну сумісність засобів
читання і записування. Інформаційні технології розвиваються дуже швидко, і
через кілька років пристроїв, здатних прочитати старий носій, може просто не
виявитись. Якщо дані архівуються в зашифрованому вигляді, необхідно
зберегти ключ і засоби розшифрування. При архівуванні і зберіганні архівної
інформації не можна забувати про підтримання конфіденційності даних.
 Контрольні питання
1. Які дії відносяться до адміністративного рівня інформаційної безпеки ?
2. Якою є головна мета адміністративного рівня інформаційної безпеки ?
3. На підставі чого будується політика безпеки?
4. На скількох рівнях деталізації доцільно розглядати політику безпеки?
5. Які рішення відносяться до верхнього рівня політика безпеки?
7. З якими аспектами законослухняності та виконавчої дисципліни має справу.
політика верхнього рівня інформаційної безпеки?
8. Які питання відносяться до середнього рівня політика безпеки?
9. Чим відрізняється політика безпеки нижнього рівня від вищих рівнів?
10. Які аспекти містить політика безпеки нижнього рівня ?
11. На які питання слід дати відповіді в політиці безпеки нижнього рівня?
12. На скількох рівнях деталізації доцільно розглядати програму безпеки?
13. Якими є головні цілі програми безпеки верхнього рівня?
14. Що є метою програми безпеки нижнього рівня ?
15. Навіщо потрібно синхронізувати програму безпеки нижнього рівня з
життєвим циклом сервісу?
16. Якими є етапи життєвого циклу інформаційного сервісу?
17. На які питання треба сформулювати відповіді на етапі ініціації?
18. Особливості етапу закупівлі.
19. Особливості етапу встановлення.
20. Особливості етапу експлуатації.
21. Особливості етапу виведення з експлуатації.
22. Що таке «точки контакту» в політиці безпеки середнього рівня?