|
|
Скачати 2.3 Mb.
|
|
Позиція організації з даного аспекту. Продовжуючи приклад з неофіційним програмним забезпеченням, можна уявити собі позиції повної заборони, вироблення процедури прийому подібного ПЗ й т.п. Позицію можна сформулювати у більш загальному вигляді, як набір цілей, які переслідує організація в даному аспекті. Взагалі стиль документів, що визначають політику безпеки (як і їхній перелік), у різних організаціях може сильно відрізнятися. Ролі й обов'язки. В "політичний" документ необхідно включити інформацію про посадових осіб, відповідальних за реалізацію політики безпеки. Наприклад, якщо для використання неофіційного програмного забезпечення співробітникам потрібен дозвіл керівництва, повинно бути відомо, у кого і як його можна одержати. Якщо неофіційне програмне забезпечення використовувати не можна, варто знати, хто стежить за виконанням даного правила. Законослухняність. Політика повинна містити загальний опис заборонених дій і покарань за них. Крапки контакту. Повинно бути відомо, куди варто звертатися за роз'ясненнями, допомогою й додатковою інформацією. Звичайно "крапкою контакту" слугують певні посадові особи, а не конкретна людина, що займає в цей момент дану посаду. Політика безпеки нижнього рівня стосується конкретних інформаційних сервісів. Вона містить у собі два аспекти - мету й правила їхнього досягнення, тому її часом важко відокремити від питань реалізації. На відміну від двох верхніх рівнів, розглянута політика повинна визначатися більш докладно. Є багато речей, специфічних для окремих видів послуг, які не можна одним чином регламентувати в рамках всієї організації. У той же час, ці речі на стільки важливі для забезпечення режиму безпеки, що рішення, які їх стосуються повинні прийматися на управлінському, а не технічному рівні. Наведемо кілька прикладів питань, на які варто дати відповідь щодо політики безпеки нижнього рівня:
При формулюванні цілей політики нижнього рівня можна виходити з міркувань цілісності, доступності й конфіденційності, але не можна на цьому зупинятися. її мета повинна бути більш конкретною. Наприклад, якщо мова йде про систему розрахунку заробітної плати, можна поставити мету, щоб тільки співробітникам відділу кадрів і бухгалтерії дозволялося вводити й модифікувати інформацію. У більш загальному випадку мета повинна зв'язувати між собою об'єкти сервісу й дії з ними. Із цілей виводяться правила безпеки, що описують, хто, що й при яких умовах може робити. Що докладніше правила, що більш формально вони викладені, тим простіше підтримати їхнє виконання програмно-технічними засобами. З іншого боку, занадто жорсткі правила можуть заважати роботі користувачів, імовірно, їх доведеться часто переглядати. Керівництво повинно знайти розумний компроміс, коли за прийнятну ціну буде забезпечений прийнятний рівень безпеки, а співробітники не виявляться надмірно зв'язані. Зазвичай найбільш формально висуваються права доступу до об'єктів через особливу важливість даного питання. 4.3. Програма безпеки Після того, як сформульована політика безпеки, можна приступати до складання програми її реалізації і безпосередньо до реалізації. Щоб зрозуміти й реалізувати яку-небудь програму, її потрібно структурувати по рівнях, звичайно у відповідності зі структурою організації. У найпростішому й найпоширенішому випадку досить двох рівнів - верхнього, або центрального, котрий охоплює всю організацію, і нижнього, або службового, котрий стосується окремих послуг або груп однорідних сервісів. Програму верхнього рівня очолює особа, відповідальна за інформаційну безпеку організації. У цієї програми наступні головні цілі: * керування ризиками (оцінка ризиків, вибір ефективних засобів захисту); « координація діяльності в області інформаційної безпеки, поповнення й розподіл ресурсів;
У рамках програми верхнього рівня приймаються стратегічні рішення із забезпечення безпеки, оцінюються технологічні новинки. Інформаційні технології розвиваються дуже швидко, і необхідно мати чітку політику відстеження й впровадження нових засобів. Контроль діяльності в області безпеки має двосторонню спрямованість. По-перше, необхідно гарантувати, що дії організації не суперечать законам. При цьому варто підтримувати контакти із зовнішніми контролюючими організаціями. По-друге, потрібно постійно відслідковувати стан безпеки усередині організації, реагувати на випадки порушень і доопрацьовувати захисні заходи з урахуванням зміни обстановки. Варто підкреслити, що програма верхнього рівня повинна займати певне місце в діяльності організації, вона повинна офіційно прийматися й підтримуватися керівництвом, а також мати певний штат і бюджет. Ціль програми нижнього рівня - забезпечити надійний й економічний захист конкретного сервісу або групи однорідних сервісів. На цьому рівні вирішується, які варто використовувати механізми захисту; закуповуються й установлюються технічні засоби; виконується повсякденне адміністрування; відслідковується стан слабких місць і т.п. Звичайно за програму нижнього рівня відповідають адміністратори сервісів. 4.4. Синхронізація програми безпеки з життєвим циклом систем Якщо синхронізувати програму безпеки нижнього рівня з життєвим циклом захищуваного сервісу, можна домогтися більшого ефекту з меншими витратами. Програмісти знають, що додати нову можливість до вже готової системи на порядок складніше, ніж з нуля спроектувати й реалізувати її. Та ж умова виконується для інформаційної безпеки. У життєвому циклі інформаційного сервісу можна виділити наступні етапи: Ініціація. На даному етапі виявляється необхідність у придбанні нового сервісу, документується його передбачуване призначення. Закупівля. На даному етапі складаються специфікації, проробляються варіанти придбання, виконується власне закупівля. Установка. Сервіс установлюється, конфігурується, тестується й уводиться в експлуатацію. Експлуатація. На даному етапі сервіс не тільки працює й адмініструється, але й піддається модифікаціям. Виведення з експлуатації. Відбувається перехід на новий сервіс. Розглянемо дії, виконувані на кожному з етапів, більш докладно. На етапі ініціації оформляється розуміння того, що необхідно придбати новий або значно модернізувати існуючий сервіс; визначається, якими характеристиками і якою функціональністю він повинен володіти; оцінюються фінансові й інші обмеження. З погляду безпеки найважливішою дією тут є оцінка критичності як самого сервісу, так і інформації, що з його допомогою буде оброблятися. Потрібно сформулювати відповіді на наступні питання:
Результати оцінки критичності є відправною крапкою в складанні специфікацій. Крім того, вони визначають ту міру уваги, яку служба безпеки організації повинна приділяти новому сервісу на наступних етапах його життєвого циклу. Етап закупівлі - один із найскладніших. Потрібно остаточно сформулювати вимоги до захисних засобів нового сервісу, до компанії, що може претендувати на роль постачальника, і до кваліфікації, якою повинен володіти персонал, що використовує або обслуговує закуплений продукт. Усі ці відомості оформляються у вигляді специфікації, куди входять не тільки апаратура й програми, але й документація, обслуговування, навчання персоналу. Зрозуміло, особлива увага повинна приділятися питанням сумісності нового сервісу з існуючою конфігурацією. Підкреслимо також, що нерідко засоби безпеки є необов'язковими компонентами комерційних продуктів, і потрібно простежити, щоб відповідні пункти не випали зі специфікації. Коли продукт закуплений, його необхідно встановити. Незважаючи на можливу простоту, установка є дуже відповідальною справою. По-перше, новий продукт треба сконфігурівати. Як правило, комерційні продукти постачаються з вимкненими засобами безпеки; їх необхідно увімкнути й належним чином налаштувати. Для великої організації, де багато користувачів і даних, початкове налаштування може стати досить працеємною й відповідальною справою. По-друге, новий сервіс має потребу в процедурних регуляторах. Варто подбати про чистоту й охорону приміщення, про документи, шо регламентують використання сервісу, про підготовку планів на випадок екстрених ситуацій, про організацію навчання користувачів і т.п. Після прийняття перерахованих заходів необхідно провести тестування. Його повнота й комплексність можуть бути гарантією безпеки експлуатації в штатному режимі. Період експлуатації - найтриваліший і складний. Із психологічної точки зору найбільшу небезпеку в цей час становлять незначні зміни в конфігурації сервісу, у поводженні користувачів й адміністраторів. Якщо безпеку не підтримувати, вона слабшає. Користувачі не настільки чітко виконують посадові інструкції, адміністратори менш ретельно аналізують реєстраційну інформацію. То один, то інший користувач одержує додаткові привілеї. Здається, що в сутності нічого не змінилося; насправді ж від колишньої безпеки не залишилося й сліду. Для боротьби з ефектом повільних змін доводиться долучатися до періодичних перевірок сервісу безпеки. Зрозуміло, після значних модифікацій подібні перевірки є обов'язковими. При виведенні з експлуатації зачіпаються апаратно-програмні компоненти сервісу й оброблювані ними дані. Апаратура продається, утилізується або викидається. Тільки в специфічних випадках необхідно піклуватися про фізичне руйнування апаратних компонентів, що зберігають конфіденційну інформацію. Програми, імовірно, просто стираються, якщо інше не передбачено ліцензійною угодою. При виведенні даних з експлуатації їх звичайно переносять на іншу систему, архівують, викидають або знищують. Якщо архівування робиться з наміром згодом прочитати дані в іншому місці, варто подбати про апаратно-програмну сумісність засобів читання й запису. Інформаційні технології розвиваються дуже швидко, і через кілька років пристроїв, здатних прочитати старий носій, може просто не виявитися. Якщо дані архівуються в зашифрованому вигляді, необхідно зберегти ключ і засоби розшифровки. Під час архівування й зберігання архівної інформації не можна забувати про підтримку конфіденційності даних. Розділ 5. Керування ризиками 5.1. Основні поняття Керування ризиками розглядається нами на адміністративному рівні ІБ, оскільки лише керівництво організації здатне виділити необхідні ресурси, ініціювати й контролювати виконання відповідних програм. Загалом кажучи, керування ризиками, так само як і вироблення власної політики безпеки, актуально тільки для тих організацій, інформаційні системи яких й/або оброблювані дані можна вважати нестандартними. Звичайну організацію цілком улаштує типовий набір захисних заходів обраних на основі подання про типові ризики або взагалі без усякого аналізу ризиків. Можна провести аналогію між індивідуальним будівництвом й одержанням квартири в районі масової забудови. У першому випадку необхідно прийняти безліч рішень, оформити велику кількість паперів, у другому досить визначитися лише з декількома параметрами. Використання інформаційних систем пов'язане з певною сукупністю ризиків. Коли можливий збиток неприйнятно великий, необхідно прийняти економічно виправдані заходи захисту. Періодична (пере)оцінка ризиків необхідна для контролю ефективності діяльності в області безпеки й для обліку змін обстановки. З кількісної точки зору рівень ризику є функцією ймовірності реалізації певної загрози (використовуючи деякі уразливі місця), а також величини можливого збитку. Таким чином, суть заходів щодо керування ризиками полягає в тому, щоб оцінити їхній розмір, виробити ефективні й економічні заходи зниження ризиків, а потім переконатися, що ризики укладені в прийнятні рамки (і залишаються такими). Отже, керування ризиками містить у собі два види діяльності, які чергуються циклічно:
Стосовно виявлених ризиків можливі наступні дії: * ліквідація ризику (наприклад, за рахунок усунення причини); « зменшення ризику (наприклад, за рахунок використання додаткових захисних засобів);
Етапи 6 та 7 відносяться до вибору захисних засобів (нейтралізації ризиків), інші - до оцінки ризиків. Уже перелік етапів показує, що керування ризиками - процес циклічний. Власне кажучи, останній етап - це оператор кінця циклу, що пропонує повернутися до початку. Ризики потрібно контролювати постійно, періодично проводячи їхню переоцінку. Відзначимо, що сумлінно виконана й ретельно документована перша оцінка може істотно спростити наступну діяльність. Керування ризиками, як і будь-яку іншу діяльність в області інформаційної безпеки, необхідно інтегрувати в життєвий цикл ІС. Тоді ефект виявляється найбільшим, а витрати - мінімальними. Раніше ми визначили п'ять етапів життєвого циклу. Коротко опишемо, що може дати керування ризиками на кожному з них. На етапі ініціації відомі ризики варто врахувати при виробленні вимог до системи взагалі й засобів безпеки зокрема. На етапі закупівлі (розробки) знання ризиків допоможе вибрати відповідні архітектурні рішення, які відіграють ключову роль у забезпеченні безпеки. На етапі установки виявлені ризики варто враховувати при конфігуруванні, тестуванні й перевірці раніше сформульованих вимог, а повний цикл керування ризиками повинен передувати впровадженню системи в експлуатацію. На етапі експлуатації керування ризиками повинно супроводжувати всі істотні зміни в системі. При виведенні системи з експлуатації керування ризиками допомагає переконатися в тім, що міграція даних відбувається безпечним чином. |
|
К-сть годин Структура інформаційної системи. Апаратна й інформаційна складові інформаційної системи. Взаємозв’язки апаратної та інформаційної... |
Урок №4. Тема: Структура інформаційної системи. Апаратна та програмна... Мета: ознайомити учнів із структурою інформаційної системи, основними пристроями апаратної складової інформаційної системи, їх функціями... |
|
ФОРМУВАННЯ ІНВЕСТИЦІЙНОЇ МОДЕЛІ У НАПРЯМКУ ПІДВИЩЕННЯ ІННОВАЦІЙНОЇ БЕЗПЕКИ РЕГІОНІВ У статті розкриті теоретико-методологічні основи дослідження економічної безпеки, визначено сутність і структуру категорії, систему... |
Лекція 1 ПОНЯТТЯ ІНФОРМАЦІЙНОЇ БЕЗПЕКИ Перш ніж говорити про інформаційну безпеку необхідно з’ясувати, що таке інформація |
|
НАВЧАЛЬНО-МЕТОДИЧНІ МАТЕРІАЛИ ДО СЕМІНАРСЬКИХ ЗАНЯТЬ з дисципліни... Правові та організаційні основи безпеки підприємницької діяльності: навчально-методичні матеріали до семінарських занять / Розробник:... |
КАЛЕНДАРНЕ ПЛАНУВАННЯ З "ОСНОВИ БЕЗПЕКИ ЖИТТЄДІЯЛЬНОСТІ" |
|
Напрямки інформаційної безпеки Інформаційна безпека має кілька напрямків В условиях ужесточения конкуренции успех предпринимательства, гарантия получения прибыли все в большей мере зависят от сохранности... |
Організація позамашинної та машинної інформаційної бази Поняття машинної інформаційної бази. Особливості розміщення інформації на машинних носіях |
|
ПВНЗ «ЄВРОПЕЙСЬКИЙ УНІВЕРСИТЕТ» КАФЕДРА “ОРГАНІЗАЦІЇ КОМПЛЕКСНОГО ЗАХИСТУ ІНФОРМАЦІЇ” Поняття, специфіка та витоки правового забезпечення захисту інформації. Проблеми інформаційної безпеки України Основні терміни та... |
ЗАТВЕРДЖЕНО Призначення і основи організації технічної служби Державного департаменту пожежної безпеки МВС України |