Загальний зміст політики інформаційної безпеки

Як було зазначено вище, в процесі створення СЗІ повинна бути розроблена ПБ не тільки на формальному рівні, а і на описовому – що саме вона має містити. Також як, наприклад, кадрова політика має на увазі наявність чітких правил, яким повинні підкорятися службовці і адміністратори, ПБ визначає, яким саме чином організація хоче забезпечити безпеку інформаційних активів. Необхідно запам'ятати один з найважливіших постулатів: інформація є активом будь-якої організації ДПС. Не завжди керівництво організації усвідомлює цінність інформаційних активів, якими володіє, але є багато бажаючих, які цілком готові на великі витрати, щоб вивчити або навіть викрасти ці активи.

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

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

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

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

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

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

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

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

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

Для кожної підсистеми, кожної підзадачі, на які може бути розбитий глобальна мета діяльності організації, необхідно розробити окремий документ. Абсолютно нормально розробляти антивірусний захист окремо від правил використовування Internet. Загальноприйнята помилка полягає в спробах втиснути опис ПБ в один документ, який змальовував тільки загальні принципи. В результаті з'являється обширний документ, з яким дуже важко працювати, який, можливо ніколи не буде прочитаний і не отримає ніякої підтримки. Людство накопичило масу доказів того, що люди не в змозі зосередити увагу на чомусь одному тривалий час. На жаль, правила інформаційної безпеки не є захоплюючою темою. Отже стислий виклад правил з ясними формулюваннями і логічним обгрунтовуванням в чітко скомпонованном документі дадуть шанс цьому документу бути прочитаним.

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

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

Після визначення кола працівників, які можуть мати право доступу осіб, необхідно подумати над тим, якими повинні бути механізми правозастосування і покарання за НСД.

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

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

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

Отже, проблема побудови та підтримки конкретних ПБ є дуже важливою і актуальною.

За визначенням [1] під ПБ інформації слід розуміти набір законів, правил, обмежень, рекомендацій і та ін., які регламентують порядок обробки інформації і спрямовані на захист інформації від певних загроз. Термін ПБ може бути застосовано до всієї організації, інформаційної системи (ІС), операційної системи (ОС), послуги, що реалізується системою (набору функцій), та ін. Чим дрібніше об'єкт, відносно якого застосовується даний термін, тим більш конкретними та формальними стають правила.

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

ПБ повинна визначати ресурси ІС, що потребують захисту, зокрема, установлювати категорії інформації, оброблюваної в ІС. Мають бути також сформульовані основні загрози для ОС, персоналу, інформації різних категорій і вимоги до захисту від цих загроз. Як складові частини загальної ПБ в ІС мають існувати політики забезпечення конфіденційності, цілісності і доступності оброблюваної інформації. Відповідальність персоналу за виконання положень ПБ має бути персонiфікована.

ПБ, що реалізуються різними ІС, будуть відрізнятися не тільки тим, що реалізовані в них функції захисту можуть забезпечувати захист від різних типів загроз, але і в зв'язку з тим, що ресурси ІС можуть істотно відрізнятись. Так, якщо ОС оперує файлами, то СУБД має справу із записами, розподіленими в різних файлах.

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

Найважливішу частину ПБ, яка регламентує правила доступу користувачів і процесів до ресурсів ІС, складають правила розмежування доступу (ПРД).

Відповідальність персоналу за виконання положень ПБ має бути персонiфікована. Кожний співробітник із персоналу ІС має бути ознайомлений з необхідними положеннями ПБ і нести персональну відповідальність за їх додержання. В цьому розумінні ПБ повинна переслідувати дві основні задачі. Перша – визначити для персоналу ІС важливість безпеки інформації і явно вказати ролі для її забезпечення. Друга – встановити відповідні обов’язки щодо забезпечення захисту інформації (ЗІ).

ПБ має бути оформлена окремим документом, який містить наступні визначення та відомості:

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

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

· Застосовність – проблемні політики вимагають включення в них опису застосовності. Це означає, що треба уточнити де, як, коли, ким і до чого застосовується дана політика.

· Ролі і обов'язки – потрібно описати відповідальних посадових осіб і їх обов'язки відносно розробки і упровадження різних аспектів політики. Для такого складного питання, як, наприклад, безпека в Інтернеті, організації може бути потрібно ввести відповідальних за аналіз безпеки різної архітектури або за затвердження використовування тієї або іншої архітектури.

· Дотримання політики. – для деяких видів політик Інтернету може виявитися доречним опис з деякою мірою детальності порушень. Можуть бути явно описані покарання і це повинно бути пов'язано із загальними обов'язками співробітників в організації. Якщо до співробітників застосовуються покарання, вони повинні координуватися з відповідними посадовими особами і відділами. Також може виявитися корисним поставити задачу конкретному відділу в організації стежити за дотриманням політики.

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

Контрольні запитання

1. Які визначення та відомості мають міститися в документі під назвою політика безпеки?

2. Який розділ політики регламентує правила доступу?

3. Що таке керування доступом? Що воно включає до себе?