Політика інформаційної безпеки є основою програми захисту інформації. Вона повинна відображати цілі організації щодо безпеки та узгоджену стратегію управління захистом інформації.
Для того, щоб політика дійсно слугувала підґрунтям для реалізації інших елементів програми захисту інформації, її має офіційно затвердити керівництво компанії. Це означає, що для створення такого документа організація повинна чітко визначити свої цілі щодо безпеки та мати узгоджену стратегію управління захистом інформації. Якщо існують суперечки щодо змісту політики, вони триватимуть і під час спроб її впровадження, що може призвести до неефективності всієї програми інформаційної безпеки.
Що робити в першу чергу?
На ринку існує безліч готових рішень для політик безпеки, але лише небагато з них буде офіційно схвалено керівництвом без детального пояснення фахівцем із безпеки. Однак це малоймовірно через обмеження часу, з якими стикаються керівники вищої ланки.
Навіть якщо керівництво могло б одразу затвердити готову політику, це не є правильним підходом, оскільки навчати керівництво мислити в категоріях безпеки — неефективно. Натомість першим кроком у створенні політики безпеки має бути з’ясування того, як керівництво сприймає питання безпеки. Політика безпеки за своєю суттю — це набір розпоряджень керівництва щодо захисту інформації, і саме ці розпорядження є керівництвом до дій для фахівця із безпеки. Якщо ж замість цього фахівець сам запропонує керівництву свої директиви для підпису, ймовірно, вимоги керівництва будуть проігноровані.
Якщо виникають суперечки щодо змісту політики, вони триватимуть і під час спроб її впровадження, що може призвести до дисфункціональності всієї програми інформаційної безпеки.
Фахівець із безпеки, чия робота полягає в розробці політики безпеки, повинен взяти на себе роль «губки» та «пера» для керівництва. «Губка» — це той, хто добре слухає і здатний легко засвоювати зміст кожної розмови, незалежно від різноманітності комунікаційних навичок та культурної специфіки групи. «Перо» документує почуте точно, без прикрас чи коментарів. Хороша «губка» та «перо» здатні вловити спільні теми з інтерв’ю з керівництвом і підготувати чітке бачення того, як організація в цілому хоче захищати свою інформацію. Час і зусилля, витрачені на досягнення консенсусу керівництва щодо політики, окупляться на етапі її впровадження.
Добрі питання для інтерв’ю, що допоможуть дізнатися думку керівництва щодо інформаційної безпеки, можуть бути такі:
- Як би ви описали різні типи інформації, з якими працюєте?
- Якими типами інформації ви керуєтесь під час ухвалення рішень?
- Чи є інформація, яку важливіше зберігати в таємниці порівняно з іншими?
На основі таких питань можна розробити систему класифікації інформації (наприклад, інформація про клієнтів, фінансова інформація, маркетингова інформація тощо) та описати відповідні процедури обробки кожного типу на рівні бізнес-процесів.
Звісно, досвідчений фахівець із безпеки також зможе дати поради щодо того, як сформувати думку керівництва стосовно безпеки у всеосяжну стратегію організації. Коли стане зрозуміло, що фахівець повністю розуміє позицію керівництва, можна буде представити структуру безпеки, яка буде з нею узгоджена. Ця структура стане основою програми інформаційної безпеки організації і буде слугувати орієнтиром для створення проєкту політики інформаційної безпеки.
Створення фреймворку інформаційної безпеки
Часто як базову основу для структури політики безпеки використовують стандарти з галузі інформаційної безпеки. Наприклад, це можуть бути такі документи, як «Стандарт належної практики» від Security Forum, серія стандартів управління безпекою від Міжнародної організації зі стандартизації (ISO 27001, 27002, 27005, www.iso.org), або «Цілі контролю для інформаційних технологій» (CoBIT) від Асоціації аудиту та контролю інформаційних систем (www.isaca.org). Такий підхід є доцільним, оскільки допомагає забезпечити, що політика буде визнана достатньою не лише керівництвом компанії, а й зовнішніми аудиторами та іншими зацікавленими сторонами програми інформаційної безпеки організації.
Однак ці документи є загальними за своєю суттю і не містять конкретних управлінських цілей щодо безпеки. Тому їх потрібно поєднувати із вхідними даними від керівництва для створення проєкту політики. Крім того, не варто очікувати, що керівництво організації змінюватиме спосіб управління компанією лише для відповідності стандартам. Натомість фахівець із безпеки може ознайомитися з передовими практиками управління безпекою з цих документів і спробувати інтегрувати їх у наявну структуру цільової організації.
Фокус на розпорядженнях
Важливо, щоб політика безпеки відображала реальну практику. В іншому випадку, з моменту публікації політики організація вже не буде відповідати їй. Краще обмежити політику невеликим набором розпоряджень, з якими всі згодні і яких усі можуть дотримуватися, ніж створювати широкомасштабну політику, яку мало хто в організації буде виконувати. Програма інформаційної безпеки повинна спрямовуватися на забезпечення дотримання політики, при цьому спірні питання вирішуються паралельно.
Якщо люди розуміють, що в політиці не існує винятків, вони зазвичай будуть більш схильні допомагати у правильному її формуванні з самого початку. Ще однією причиною, чому краще мати політику, яка містить невеликий набір розпоряджень, є те, що відсутність винятків підвищує ймовірність того, що люди прагнутимуть забезпечити її відповідність з самого початку, щоб мати можливість дотримуватися її в майбутньому. Як тільки в політиці з’являються фрази типу «винятки з цієї політики можуть бути зроблені за погодженням з керівником…», документ втрачає свою цінність. Він перестає представляти прихильність керівництва до програми інформаційної безпеки і, навпаки, демонструє сумнів у тому, що політика буде робочою.
Фахівець з інформаційної безпеки повинен враховувати, що якщо такі формулювання потраплять до кадрової або бухгалтерської політики, це може стати виправданням для сексуальних домагань або шахрайства у звітах про витрати. Фахівець з інформаційної безпеки повинен прагнути до того, щоб політика інформаційної безпеки дотримувалася на тому ж рівні, що й інші політики, які застосовуються в організації. Формулювання політики повинні бути розроблені таким чином, щоб гарантувати повний консенсус серед вищого керівництва.
Наприклад, якщо виникають суперечки щодо доступу користувачів до змінних носіїв, таких як USB-накопичувачі. Фахівець із безпеки може вважати, що такий доступ ніколи не повинен бути дозволений, тоді як технічний керівник може наполягати, що відділи, відповідальні за обробку даних, повинні мати можливість переносити дані на будь-який тип носіїв. На рівні політики підхід, заснований на консенсусі, може виглядати як загальне твердження: «усі доступи до змінних носіїв мають бути затверджені через процес, підтримуваний відповідальним керівником». Деталі процесу затвердження можуть бути обговорені окремо, проте загальна політика все ж забороняє використання змінних носіїв будь-кому, хто не має схвалення з боку відповідального керівника.
Використання підполітик
У дуже великих організаціях деталі альтернативних варіантів дотримання політики можуть суттєво відрізнятися. У таких випадках може бути доцільно розділити політики за цільовою аудиторією. Тоді загальноорганізаційна політика стає глобальною політикою, що включає лише найменший спільний знаменник мандатів у сфері безпеки. Різні суборганізації можуть публікувати свої власні політики. Такі розподілені політики є найбільш ефективними там, де аудиторія підполітики є чітко визначеною підгрупою організації. У цьому випадку не потрібно домагатися такого ж високого рівня прихильності керівництва, щоб оновлювати ці документи.
Наприклад, політика використання інформаційних технологій повинна вимагати лише затвердження керівника відділу інформаційних технологій, якщо вона відповідає глобальній політиці безпеки і лише посилює прихильність керівництва до послідовної стратегії безпеки в цілому. Вона, ймовірно, включатиме такі директиви, як «доступ до внесення змін до конфігурації операційної системи повинен надаватися лише уповноваженим адміністраторам» та «доступ до паролів для загальних ідентифікаторів повинен надаватися лише в контексті санкціонованих процесів контролю змін». Інший тип підполітики може передбачати, що люди в різних відділах займаються якоюсь незвичною діяльністю, яка, тим не менш, підлягає аналогічному контролю безпеки, наприклад, передача обробки інформації на аутсорсинг або шифрування електронного листування.
Час і зусилля, витрачені на досягнення виконавчого консенсусу щодо політики, окупляться авторитетом, який він надасть процесу впровадження політики.
З іншого боку, предметні політики, які застосовуються до всіх користувачів, не повинні бути причиною для розробки нових політик, а мають бути додані як розділи до глобальної політики. Не рекомендується створювати декілька політик, що містять мандати для всієї організації, оскільки наявність декількох джерел політик ускладнює досягнення послідовного рівня обізнаності про безпеку для кожного окремого користувача. Досить важко розробити програми підвищення обізнаності про політику, які б охоплювали всіх членів цільової спільноти, без необхідності пояснювати, навіщо було створено кілька документів політики, коли можна було б обійтися одним. Наприклад, нові обмеження на доступ до Інтернету в масштабах всієї організації не обов’язково мають бути причиною для створення нової політики «доступу до Інтернету». Замість цього можна додати розділ «доступ до Інтернету» до глобальної політики безпеки.
Ще одне застереження для фахівця з безпеки, який використовує підхід підполітики, полягає в тому, щоб переконатися, що підполітики не повторюють те, що міститься в глобальній політиці, і в той же час узгоджуються з нею. Повторення повинно бути заборонено, оскільки це може призвести до розбіжності між політичними документами в міру того, як вони розвиватимуться. Натомість, субдокументи повинні посилатися на глобальний документ, і ці два документи повинні бути пов’язані між собою у спосіб, зручний для читача.
Допоміжні документи інформаційної безпеки
Навіть при повазі до субполітик, коли існує директива щодо інформаційної безпеки, яка може бути інтерпретована по-різному, не підриваючи прихильність організації до цілей безпеки, фахівець із безпеки повинен утриматися від включення таких директив до політики. Політика має бути зосереджена лише на розпорядженнях. Альтернативні стратегії реалізації можуть бути викладені у вигляді відповідальності, стандартів, процесів, процедур або настанов. Це дозволяє впроваджувати інновації та забезпечує гнучкість на рівні відділів, зберігаючи при цьому чіткі цілі безпеки на рівні політики.
Це не означає, що відповідні цілі захисту інформації повинні бути вилучені з програми інформаційної безпеки. Може вказувати на те, що не вся стратегія безпеки може бути задокументована на рівні виконавчих розпоряджень політики. У міру розвитку програми інформаційної безпеки політика може оновлюватися, але такі оновлення не повинні бути необхідними для досягнення поступових поліпшень у сфері безпеки. Додатковий консенсус може постійно покращуватися за допомогою інших документів програми інформаційної безпеки.
Допоміжні документи, які слід розглянути:
- Ролі та обов’язки — Опис відповідальностей за безпеку, які виконуються відділами, окрім відділу безпеки. Наприклад, відділи розробки технологій можуть бути відповідальними за тестування на наявність вразливостей у системі перед впровадженням коду, а відділи кадрів — за ведення точних списків поточних співробітників та підрядників.
- Технологічні стандарти — Опис параметрів технічної конфігурації та відповідних значень, які визначені для забезпечення того, щоб керівництво могло контролювати доступ до електронних інформаційних активів.
- Процеси — Робочі процеси, що демонструють, як функції безпеки, виконувані різними відділами, поєднуються для забезпечення безпечної обробки інформації.
- Процедури — Покрокові інструкції для некваліфікованого персоналу, щоб вони могли виконувати рутинні завдання з безпеки таким чином, щоб забезпечити роботу відповідних механізмів попередження, виявлення або реагування відповідно до плану.
- Настанови — Рекомендації щодо найпростіших способів дотримання політики безпеки, зазвичай написані для нетехнічних користувачів, у яких є кілька варіантів безпечної обробки інформації.
Що включає політика інформаційної безпеки?
Це піднімає питання: яка мінімальна інформація має бути включена до політики інформаційної безпеки? Її зміст має бути достатнім для того, щоб чітко передати цілі та напрямки керівництва щодо безпеки. Політика повинна включати такі елементи:
- Обсяг — охоплює всю інформацію, системи, об’єкти, програми, дані, мережі та всіх користувачів технологій в організації, без винятку.
- Класифікація інформації — забезпечує конкретні визначення вмісту, а не загальні терміни типу “конфіденційно” або “обмежено”.
- Цілі керівництва — цілі щодо безпечної обробки інформації в кожній категорії класифікації (наприклад, юридичні, регуляторні та договірні зобов’язання щодо безпеки) можуть бути об’єднані та сформульовані як загальні об’єктиви: “приватність клієнтів означає відсутність несанкціонованого доступу до відкритого тексту даних клієнта, окрім уповноважених представників клієнта та лише для цілей спілкування з клієнтом”, “цілісність інформації означає відсутність права запису за межами відповідних посадових функцій”, “запобігання втраті активів”.
- Контекст — розміщення політики в контексті інших управлінських розпоряджень та додаткових документів (наприклад, узгоджена на рівні виконавчого керівництва, усі інші документи з обробки інформації мають бути з нею узгоджені).
- Підтримуючі документи — посилання на допоміжні документи (наприклад, ролі та обов’язки, процеси, технологічні стандарти, процедури, настанови).
- Конкретні інструкції — інструкції щодо загальновідомих організаційних вимог до безпеки (наприклад, доступ до будь-якої комп’ютерної системи вимагає ідентифікації та автентифікації, заборона спільного використання індивідуальних механізмів автентифікації).
- Відповідальність — чітке визначення встановлених відповідальностей (наприклад, технологічний відділ є єдиним постачальником телекомунікаційних ліній).
- Наслідки — опис наслідків у разі невиконання політики (наприклад, до і включно з звільненням або розірванням контракту).
Цей перелік елементів є достатнім для повноти політики інформаційної безпеки відповідно до поточних галузевих найкращих практик, за умови, що відповідальність за призначення конкретних заходів безпеки встановлена у розділах “допоміжні документи” та “відповідальність”. Хоча пункти 6 і 7 можуть містити велику кількість інших узгоджених деталей щодо заходів безпеки, важливо залишати їх мінімальними для підтримання читабельності політики та покладатися на субполітики або підтримуючі документи для включення вимог. Знову ж таки, важливіше забезпечити повне дотримання на рівні політики, ніж включати до неї надмірну кількість деталей.
Зверніть увагу, що сам процес розробки політики існує поза межами документа політики. Документація щодо затверджень політики, її оновлень та контролю версій також повинна бути ретельно збережена та доступна у разі аудиту процесу розробки політики.