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

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

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

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

Головна мета заходів адміністративного рівня – сформувати програму робіт в області інформаційної безпеки і забезпечити її виконання, виділяючи необхідні ресурси і контролюючи стан справ.

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

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

Термін “політика безпеки” є не зовсім точним перекладом англійського словосполучення “security роlicy”, проте в даному випадку калька краще відображає значення цього поняття, ніж лінгвістично більш вірні “правила безпеки”. Ми матимемо на увазі не окремі правила або їх набори (такого роду рішення виносяться на процедурний рівень, про який йтиметься далі), а стратегію організації в області інформаційної безпеки. Для вироблення стратегії і проведення її в життя потрібні, поза сумнівом, політичні рішення, що приймаються на найвищому рівні адміністративному рівні.

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

Таке трактування, звичайно, набагато ширше, ніж набір правил розмежування доступу (саме це означав термін “security роlicy” в “Оранжевій книзі” і в побудованих на її основі нормативних документах інших країн).

ІС організації і пов’язані з нею інтереси суб’єктів – це складна система, для розгляду якої необхідно застосовувати об’єктно-орієнтований підхід і поняття рівня деталізації. Доцільно виділити, принаймні, три такі рівні, що ми вже робили в прикладі і зробимо ще раз далі.

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

 

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

З практичної точки зору політику безпеки доцільно розглядати на трьох рівнях деталізації. До верхнього рівня можна віднести рішення, що зачіпають організацію в цілому. Вони носять досить загальний характер і, як правило, виходять від керівництва організації. Орінтовний список подібних рішень може включати наступні елементи:

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

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

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

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

В політиці повинні бути визначені обов’язки посадовців по виробленню програми безпеки і проведенню її в життя. В цьому сенсі політика безпеки є основою підзвітності персоналу.

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

Взагалі, на верхній рівень слід виносити мінімум питань. Таке винесення доцільне, коли воно обіцяє значну економію засобів або коли інакше поступити просто неможливо.

Британський стандарт BS 7799:1995 (ISO 17799:2000) рекомендує включати в документ, що характеризує політику безпеки організації, наступні розділи:

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

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

Політика середнього рівня повинна для кожного аспекту освітлювати наступні теми:

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

Область застосування. Слід визначити, де, коли, як, по відношенню до кого і чому застосовується дана політика безпеки. Наприклад, чи торкається політика, пов’язана з використанням неофіційного програмного забезпечення, організацій-субпідрядників? Чи зачіпає вона співробітників, що користуються портативними і домашніми комп’ютерами і змушених переносити інформацію на виробничі машини?

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

Ролі і обов’язки. В “політичний документ” необхідно включити інформацію про посадовців, відповідальних за реалізацію політики безпеки. Наприклад, якщо для використання неофіційного програмного забезпечення співробітникам потрібен дозвіл керівництва, потрібно знати, у кого і як його можна отримати. Якщо неофіційне програмне забезпечення використовувати не можна, слід знати, хто стежить за виконанням даного правила.

Законослухняність. Політика повинна містити загальний опис заборонених дій і покарань за них.

Точки контакту. Потрібно, щоб було відомо, куди слід звертатися за роз’ясненнями, допомогою і додатковою інформацією. Звичайно “точкою контакту” служить певний посадовець, а не конкретна людина, яка займає в даний момент даний пост.

Політика безпеки нижнього рівня відноситься до конкретних інформаційних сервісів. Вона включає два аспекти – цілі і правила їх досягнення, тому її часом важко відділити від питань реалізації. На відміну від двох верхніх рівнів, дана політика повинна бути визначений більш детально. Є багато речей, специфічних для окремих видів послуг, які не можна єдиним чином регламентувати в рамках всієї організації. В той же час, ці речі настільки важливі для забезпечення режиму безпеки, що рішення, які відносяться до них повинні прийматися на управлінському, а не технічному рівні. Наведемо декілька прикладів питань, на які слід дати відповідь в політиці безпеки нижнього рівня:

  • хто має право доступу до об’єктів, підтримуваним сервісом?
  • за яких умов можна читати і модифікувати дані?
  • як організований віддалений доступ до сервісу?

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

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

 

Програма безпеки

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

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

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

  • управління ризиками (оцінка ризиків, вибір ефективних засобів захисту);
  • координація діяльності в області інформаційної безпеки, поповнення і розподіл ресурсів;
  • стратегічне планування;
  • контроль діяльності в області інформаційної безпеки.

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

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

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

Мета програми нижнього рівня – забезпечити надійний і економічний захист конкретного сервісу або групи однорідних сервісів. На цьому рівні вирішується, які слід використовувати механізми захисту; закуповуються і встановлюються технічні засоби; виконується повсякденне адміністрування; відстежується стан слабких місць і т.ін. Звичайно за програму нижнього рівня відповідають адміністратори сервісів.

Синхронізація програми безпеки з життєвим циклом систем

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

В життєвому циклі інформаційного сервісу можна виділити наступні етапи:

Ініціація. На даному етапі виявляється необхідність в придбанні нового сервісу, документується його передбачуване призначення.

Закупівля. На даному етапі складаються специфікації, опрацьовуються варіанти придбання, виконується власне закупівля.

Установка. Сервіс встановлюється, конфігурується, тестується і вводиться в експлуатацію.

Експлуатація. На даному етапі сервіс не тільки працює і адмініструється, але і піддається модифікаціям.

Виведення з експлуатації. Відбувається перехід на новий сервіс.

Розглянемо дії, виконувані на кожному з етапів, більш детально.

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

З погляду безпеки найважливішою дією тут є оцінка критичності як самого сервісу, так і інформації, яка з його допомогою оброблятиметься. Вимагається сформулювати відповіді на наступні питання:

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

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

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

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

По-друге, новий сервіс потребує процедурних регуляторів. Слід потурбуватися про чистоту і охорону приміщення, про документи, що регламентують використання сервісу, про підготовку планів на випадок екстрених ситуацій, про організацію навчання користувачів і т.п.

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

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

Для боротьби з ефектом повільних змін доводиться вдаватися до періодичних перевірок безпеки сервісів. Зрозуміло, після значних модифікацій такі перевірки є обов’язковими.

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

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

завантаження...
WordPress: 23.02MB | MySQL:26 | 0,332sec