Національна академія наук України
Інститут програмних систем НАН України
ЗАТВЕРДЖЕНО
05540149.90000.044.И3-01-АЗ
Програма інформатизації НАН України
Проект «Розробка та впровадження типових рішень
щодо комплексної системи захисту інформації в АІС НАНУ»
Шифр –КСЗІ АІС НАНУ
Система управління інцидентами інформаційної безпеки
Керівництво адміністратора
05540149.90000.043.И3-06
2009
ЗМІСТ
ВСТУП 4
1. ПРАКТИКИ ЩОДО УПРАВЛІННЯ ІНЦИДЕНТАМИ ТА НОРМАТИВНІ ДОКУМЕНТИ 8
1.1. Опис створюваної системи управління інцидентами інформаційної безпеки 9
1.2. Процеси управління 11
1.3. Засоби автоматизації 13
1.4. Документація системи управління 13
1.5. Впровадження системи 14
1.6. Склад робіт зі створення системи 15
1.7. Практичний підхід до побудови системи управління ІБ 16
1.8. Складнощі управління інцидентами інформаційної безпеки 20
2. МЕТОДИ УПРАВЛІННЯ ІНЦИДЕНТАМИ ІБ 22
2.1. Що таке інцидент? 22
2.2. Управління інцидентами інформаційної безпеки 23
2.3. Ознаки інциденту інформаційної безпеки 26
2.4. Аналіз інцидентів інформаційної безпеки 27
2.5. Документування інциденту інформаційної безпеки 28
2.6. Концепція і структура побудови системи управління інцидентами ІБ 29
2.7. Пріоретизація інцидентів інформаційної безпеки 31
2.8. Розповсюдження повідомлень про інцидент інформаційної безпеки 31
2.9. Розробка політики реакції на інцидент 31
2.10. Як управляти інцидентами інформаційної безпеки? 32
2.10.1. Планування та підготовка 35
2.10.2. Експлуатація 37
2.10.3. Аналіз 37
2.10.4. Поліпшення 37
2.11. Виявлення і реєстрація інциденту 38
2.12. Усунення причин, наслідків інциденту і його розслідування 39
2.13. Коректуючі та превентивні дії 40
2.14. Рекомендації і можливі труднощі 42
2.15. Ефект від впровадження процесу управління інцидентами 44
2.16. Ефект від впровадження процесу управління проблемами 44
2.17. ITIL як бібліотека інфраструктури ІТ 45
3. ЗАСОБИ УПРАВЛІННЯ ІНЦИДЕНТАМИ NETFORENSICS 48
3.1. Автоматизація процесів управління інцидентами 48
3.2. Характеристики netForensics 49
3.3. Встановлення та деінсталяція nFX Log One 51
3.3.1. Вимоги до програмного забезпечення nFX LogOne 51
3.3.2. Покрокова інсталяція 52
3.3.3. Ліцензування nFX Log One 52
3.3.4. Огляд поточної ліцензійної інформації 52
3.3.5. Оновлення ліцензійного файлу nFX Log One 53
3.3.6. Деінсталяція агентів 53
3.3.7. Деінсталяція серверних компонентів nFX Log One 53
3.4. Початок роботи з nFX Log One 54
3.4.1. Консоль управління nFX Log One 54
3.4.2. Реєстрація всередині консолі управління nFX Log One 54
3.4.3. Реєстрація консолі управління nFX Log One ззовні 56
3.4.4. Інсталяція віддаленої консолі управління nFX Log One 56
3.5. Інтерфейс кофігурації установки nFX Log One 57
3.6. Інсталяція агентів nFX Log One 58
3.6.1. Віддалена агентна інсталяція 59
3.6.2. Створення звітів користувача 59
3.7. Властивості параметрів користувача 61
3.7.1. Розклад сповіщення 61
3.7.2. Формат повідомлення 61
3.7.3. Dialup-пейджер та SMS опції 62
3.8. Створення ділових груп 63
3.8.1. Таблиця властивостей перевірок звітності 64
3.8.2. Таблиця привілегій 64
3.8.3. Таблиця варіантів розгортання 65
3.8.4. Внесення корегуючих дій 66
3.9. Конфігурація маршруту обробки подій 67
3.9.1. Таблиця електронної пошти 68
3.9.2. Загальна таблиця Dialup пейджера 69
3.9.3. Таблиця генератора пасток (Traps Generator) SNMP 69
3.10. Спостерігач подій (Event Watcher) 71
3.10.1. Використання правил в спостерігачі подій 71
3.10.2. Перегляд живих подій (Live Events) в nFX Log One консолі 72
3.10.3. Побудова спостерігача живих подій (Live Event Watcher) 73
3.11. Правила спостерігача подій 75
3.11.1. Побудова правила Event Watcher Rule з події 75
3.11.2. Використання екрану опису правила спостерігача подій 77
3.11.3. Використання функцій правила спостерігача подій 77
3.11.4. Критерій правила, що базується на Header Subscreen 79
3.12. Вікно варіантів правила спостерігача подій 79
3.12.1. Варіант дії, покладеної на узгодженість події 80
3.12.2. Варіант відбору корегуючої дії 80
3.12.3. Варіант підтвердження події 81
3.12.4. Варіант події, що відсилає інформацію 81
3.12.5. Варіант частоти сповіщення 82
3.12.6. Варіант тексту повідомлення 82
3.12.7. Варіант розкладу сповіщення 83
3.12.8. Варіант пріоритету сповіщення 83
3.12.9. Резолюція 84
3.12.10. Варіант правил, що базуються на тексті 84
3.12.11. Створення нового, звичайного правила спостерігача подій 85
3.13. Спостерігач SysLog 86
3.13.1. Створення правила спостерігача SysLog 86
3.13.2. Базові установки 88
3.14. Спостерігач текстового файлу (Text File Watcher) 90
3.14.1. Створення правила спостерігача текстового файлу 91
3.14.2. Збереження та імпорт шаблону спостерігача текстового файлу 99
3.15. Інструментальні засоби супроводу програми nFX Log One 99
3.15.1. Огляд інструментальних засобів супроводу програми 99
3.15.2. Інструментальний засіб блокування рівней контролю (Snooze Tool) 101
3.15.3. Інструментальний засіб перезавантаження (Reboot Tool) 106
3.15.4. Інструментальний засіб виконання (Run Tool) 110
3.15.5. Інструментальний засіб менеджер розкладів (Scheduler) 114
3.19.6. Менеджер управління сервісом (Service Control Manager) 115
3.15.7. Інструментальний засіб контролю журналу подій (Event Log Management Tool) 116
3.15.8. Інструментальний засіб пильного технічного обслуговування тривог (Alert Maintenance Tool) 118
3.15.9. Інструментальний засіб конфігурації бази даних (Database Configuration Tool) 119
3.15.10. Інструментальний засіб управління квотою бази даних (Database Quota Management Tool) 120
3.15.11. Інструментальний засіб резервного копіювання (бекап) та відновлення (Backup and Restore Tool) 121
3.16. Початок роботи за допомогою netForensics Reporting 123
3.16.1. Вимоги щодо інсталяції netForensics Reporting для SQL Сервер звітних сервісів 123
3.16.2. Звітні сервіси SQL 124
3.16.3. Мінімальні системні вимоги та інсталяційні особливості 124
3.17. Встановлення netForensics Reporting 124
3.18. Використання звітів в netForensics Reporting 127
3.18.1. Виконання звіту 127
3.18.2. Конфігурація звіту 131
3.18.3. Історія звіту 138
3.18.4. Підписи звіту 138
3.18.5. Доступ звіту та призначення ролі 140
ЛІТЕРАТУРА 142
ВСТУП
Даний документ містить пропозиції щодо розробки та впровадження системи управління інцидентами інформаційної безпеки, що включає процеси, нормативно-розпорядчу документацію і засоби автоматизації.
Система управління інцидентами інформаційної безпеки є базовою частиною загальної системи управління інформаційною безпекою і дозволяє виявляти, враховувати, реагувати й аналізувати події та інциденти інформаційної безпеки. Без реалізації цих процесів неможливо забезпечити рівень захищеності, що адекватний сучасним стандартам і галузевим нормам. Для найбільш ефективної реалізації системи управління інцидентами інформаційної безпеки необхідно спиратись на вимоги міжнародних і галузевих стандартів, таких як ISO\IEC 27001-2005 ''Information security management systems. Requirements'' [1] та ITU-T X-1051 ''Information security management systems. Requirements for telecommunications'' [2].
Управління інцидентами, це важливий процес, який забезпечує організації можливість спочатку виявити інцидент, а потім за допомогою коректно обраних засобів підтримки якомога швидше його вирішити.
Основна задача управління інцидентами – якомога швидше відновити нормальну роботу служб і звести до мінімуму негативний вплив інциденту на роботу організації для підтримки якості і доступності служб на максимально можливому рівні. Нормальною вважається робота служб, що не виходить за рамки угоди про рівень обслуговування.
Цілі управління інцидентами:
відновлення нормальної роботи служб в найкоротші терміни;
зведення до мінімуму впливу інцидентів на роботу організації;
забезпечення злагодженої обробки всіх інцидентів і запитів обслуговування;
зосередження ресурсів підтримки на найбільш важливіших напрямах;
надання відомостей, що дозволяють оптимізувати процеси підтримки, зменшити кількість інцидентів і зпланувати управління.
Управління інцидентами і проблемами є комплексним рішенням, що оптимізує управління всіма аспектами обслуговування і підтримки, необхідними для підприємства.
Використовуючи кращі, перевірені часом, напрацювання і вирівнювання ІТ-процесів для обробки збоїв будь-яких видів, рішення з управління інцидентами дозволяють використовувати ресурси залежно від пріоритетів ділової діяльності, управляти рівнями обслуговування, а також краще контролювати витрати ІТ-служб.
Рішення з управління інцидентами прискорює процес вирішення інцидентів на всіх етапах: від первинного виявлення і діагностики проблем та основних причин до остаточного їх усунення.
Для реалізації системи управління інцидентами інформаційної безпеки необхідно провести наступні роботи:
Виділити ресурси для розробки та впровадження системи управління інцидентами.
Визначити область функціонування системи управління інцидентами.
Розробити комплекс процесів системи управління.
Навчити персонал.
Впровадити процеси управління інцидентами та інтегрувати їх зі вже функціонуючими процесами управління інформаційної безпекою, такими як, інвентаризація активів, аналіз ризиків та оцінка ефективності.
Розробити архітектуру і комплекс технічних засобів з автоматизації процесів управління інцидентами і моніторингу подій інформаційної безпеки.
Впровадити комплекс програмно-технічних засобів автоматизації управління інцидентами.
В результаті проведених робіт буде впроваджена система управління інцидентами інформаційної безпеки, яка буде вирішувати наступні задачі:
Оперативний моніторинг стану інформаційної безпеки в рамках обраної галузі діяльності системи.
Виявлення, облік, реагування, розслідування та аналіз інцидентів інформаційної безпеки.
Інформування вищого керівництва і зацікавлених осіб про поточний стан інформаційної безпеки.
Крім визначення того, яким чином і які ресурси захищати, а також вирішення питання щодо контролю доступу до внутрішніх ресурсів, для багатьох організацій на перший план виноситься питання про розуміння того, а що в принципі відбувається в інформаційній системі?
Основна задача служби ІБ – це запобігання і зменшення збитку активам бізнес-рівня. Яким чином зв'язати потік технічних подій з інцидентами бізнес- рівня? Як адміністратору своєчасно відстежити і виявити, про що саме сповіщають пристрої, вжити адекватні заходи щодо припинення інциденту або підозрілої активності? Необхідність своєчасного виявлення інцидентів і реакції на них обумовлена в першу чергу тим, що часто на карту поставлена репутація і гроші, яких в одну мить може позбавитися організація, не помітивши інцидента, про який сигналізували засоби захисту. Існує багато прикладів, коли після тих або інших дій зловмисників організації втрачали цінну інформацію, витрачали великі суми на усунення наслідків інцидентів безпеки, і потім довгий час вимушені були відновлювати збиток репутації і налагоджувати взаємини з партнерами і замовниками. Зазначимо, що всі ці чинники вкрай негативно позначалися на бізнес-діяльності. У зв'язку з цим, однією з актуальних задач є побудова і впровадження процесу управління інцидентами.
Жодна найдосконаліша міра щодо зниження ризиків інформаційної безпеки, будь це досконально відпрацьована політика або найсучасніший міжмережевий екран, не може гарантувати виникнення в інформаційному середовищі подій, що потенційно несуть загрозу ділової діяльності організації. Складність та різноманітність середовища діяльності сучасного бізнесу зумовлюють наявність залишкових ризиків незалежно від якості підготовки і впровадження заходів протидії. Також завжди існує ймовірність реалізації нових, невідомих до теперішнього часу, загроз інформаційної безпеки.
Таким чином, будь-якій організації, що серйозно відноситься до питань забезпечення інформаційної безпеки, необхідно реалізувати комплексний підхід щодо вирішення наступних задач:
виявлення, інформування та облік інцидентів інформаційної безпеки;
реакція на інциденти інформаційної безпеки, включаючи застосування необхідних засобів для запобігання, зменшення і відновлення завданого збитку;
аналіз відбувшихся інцидентів, з метою планування превентивних заходів захисту і поліпшення процесу забезпечення інформаційної безпеки в цілому.
Також слід зазначити, що при експлуатації різного роду систем менеджменту інформаційної безпеки процес управління інцидентами є одним з найважливіших постачальників даних для аналізу функціонування подібних систем, оцінки ефективності використовуваних заходів зниження ризиків і планування поліпшень в роботі системи.
1. Практики щодо управління інцидентами та нормативні документи
До теперішнього часу в міжнародній практиці розроблено достатню кількість нормативних документів, що регламентують питання управління інцидентами інформаційної безпеки. Необхідно відзначити, що питання управління інцидентами виникає не тільки в рамках забезпечення інформаційної безпеки, але й при управлінні ІТ-сервісами в цілому. Сімейство міжнародних стандартів ISO 20000:2005 в розділі Service Delivery and Support описує ряд вимог щодо організації процесу управління інцидентами в ІТ-інфраструктурі. Згідно зазначеним стандартам під інцидентом розуміється "будь-яка подія, що не є елементом нормального функціонування служби і при цьому надаює або здатна надати вплив на подання служби шляхом її переривання або зниження якості".
Специфічні питання управління інцидентами інформаційної безпеки розглядаються в наступних документах:
ISO/IEC 27001:2005 Information security management system. Requirements. В рамках даного стандарту висуваються загальні вимоги до побудови системи управління інформаційною безпекою, що відносяться у тому числі і до процесів управління інцидентами.
ISO/IEC TR 18044 Information security incident management. Даний документ описує інфраструктуру управління інцидентами в рамках циклічної моделі PDCA. Наводяться докладні специфікації для стадій планування, експлуатації, аналізу і поліпшення процесу. Розглядаються питання забезпечення нормативно-розпорядчою документацією, ресурсами, приводяться докладні рекомендації щодо необхідних процедур.
CMU/SEI-2004-TR-015 Defining incident management processes for CISRT. Цей документ описує методологію планування, впровадження, оцінки і поліпшення процесів управління інцидентами. Основний наголос робиться на організації роботи CISRT (Critical Incident Stress Response Team) – групи або підрозділів, які забезпечують сервіс і підтримку запобігання, обробки і реакції на інциденти інформаційної безпеки. Вводиться ряд критеріїв, на підставі яких можна оцінювати ефективність даних сервісів, приводяться докладні процесні карти.
NIST SP 800-61 Computer security incident handling guide. Тут наведена збірка "кращих практик" щодо побудови процесів управління інцидентами і реакції на них. Детально розбираються питання реакції на різні типи загроз, такі як розповсюдження шкідливого програмного забезпечення, несанкціонований доступ та ін.
В рамках даного проекту неможливо розглянути всі наявні рекомендації щодо управління інцидентами, і цілком ймовірно, що найбільш ефективним для конкретної організації буде використання якої-небудь іншої методології, у тому числі і розробленої самостійно. Але, будь-яка використовувана методологія повинна бути сумісна з основними сучасними стандартами на системи управління, такими як ISO/IEC 27001 та ISO 20000.
1.1. Опис створюваної системи управління інцидентами інформаційної безпеки
Міжнародний стандарт ISO/IEC 27001 «Інформаційні технології – Методи безпеки – Системи управління інформаційною безпекою – Вимоги» вводить наступні визначення:
подія інформаційної безпеки: ідентифікований випадок стану системи або мережі, вказуючий на можливе порушення політики інформаційної безпеки або відмову засобів захисту, або раніше невідома ситуація, яка може бути істотною для безпеки.
інцидент інформаційної безпеки: одинична подія або ряд небажаних і непередбачених подій інформаційної безпеки, через які існує ймовірність компрометації бізнес-інформації і загрози інформаційній безпеці.
Стандарт ISO/IEC 27001 накладає ряд загальних вимог з побудови процесів управління інформаційною безпекою, до складу яких входить і процес управління інцидентами. До числа таких вимог відноситься:
Використання моделі PDCA для забезпечення планування процесів, впровадження процесів, контролю й аналізу процесів, поліпшення процесів.
Належне документування процесів і процедур.
Своєчасне виявлення невдалих і успішних спроб порушення безпеки та інцидентів інформаційної безпеки.
Своєчасне повідомлення про інциденти ІБ за належними управлінськими каналами.
Встановлення відповідальності керівництва і процедур для забезпечення швидкої і ефективної реакції на інциденти ІБ.
Повинні бути реалізовані механізми, які дозволяють вимірювати і відстежувати типи, обсяги і вартість інцидентів ІБ.
Необхідно зібрати, зберегти і надати докази відповідно до вимог локального законодавства.
Повинна бути забезпечена підтримка керівництвом процесів управління інцидентами.
Процеси управління інцидентами повинні безперервно аналізуватися і поліпшуватися.
Документ ISO/IEC TR 18044 Information security incident management [3] визначає формальну модель процесу реакції на інциденти. Цілями проходження цієї моделі є впевненість в тому, що:
Події та інциденти інформаційної безпеки виявляються і обробляються ефективним чином, особливо в частині класифікації подій.
Виявлені інциденти інформаційної безпеки враховуються і обробляються найбільш відповідним і ефективним чином.
Наслідки інцидентів інформаційної безпеки можуть бути мінімізовані в процесі реакції на інциденти, можливо із залученням процесів відновлення після збоїв та аварій (DRP/BCP).
За рахунок аналізу інцидентів та подій ІБ підвищується ймовірність запобігання майбутніх інцидентів, поліпшуються механізми і процеси забезпечення ІБ.
Таким чином, для управління інцидентами інформаційної безпеки необхідно організувати комплекс процесів управління інцидентами, забезпечити його належними ресурсами, відповідною нормативно-розпорядчою і робочою документацією, технічними засобами забезпечення механізмів контролю.
1.2. Процеси управління
Для обробки подій та інцидентів інформаційної безпеки необхідно організувати процес реагування на інциденти. Основними задачами процесу реагування на інциденти ІБ є:
забезпечення координації реагування на інцидент;
підтвердження/спростування факту виникнення інциденту ІБ;
забезпечення збереження і цілісності доказів виникнення інциденту, створення умов для накопичення і зберігання точної інформації про інциденти ІБ, що мали місце, про корисні рекомендації;
мінімізація порушень порядку роботи і пошкодження даних ІТ-системи, відновлення в найкоротші терміни працездатності організації при її порушенні в результаті інциденту;
мінімізація наслідків порушення конфіденційності, цілісності і доступності інформації ІТ-систем;
захист прав організації, встановлених законом; створення умов для порушення цивільної або кримінальної справи проти зловмисників;
захист репутації організації та її ресурсів;
швидке виявлення та/або попередження подібних інцидентів в майбутньому;
навчання персоналу компанії діям з виявлення, усунення наслідків і запобігання інцидентів ІБ;
своєчасне інформування керівництва про стан інформаційної безпеки.
В якості прикладу основних процесів системи управління інцидентами інформаційної безпеки можна навести наступні процеси:
Стадія планування:
Виділення людських і матеріальних ресурсів.
Розробка схеми управління інцидентами.
Розробка і затвердження організаційно-регламентуючих документів.
Навчання персоналу та апробація обраної схеми реагування на інциденти.
Стадія експлуатації:
Виявлення та ідентифікація інциденту.
Попередній аналіз інциденту.
Початкове реагування на інцидент.
Реагування на інцидент.
Розслідування інциденту.
Аналіз інциденту.
Розробка рекомендацій.
Стадія аналізу:
Аналіз метрик внутрішньої ефективності процесів.
Аналіз метрик ефективності досягнення цілей процесів.
Аналіз відгуків зацікавлених осіб.
Розробка рекомендацій.
Стадія поліпшення:
Узгодження і апробація поліпшень.
Перехід на стадію планування процесу впровадження поліпшень.
1.3. Засоби автоматизації
В рамках системи управління інцидентами інформаційної безпеки необхідно збирати і обробляти велику кількість подій інформаційної безпеки, які надходять з різних джерел. Ці події повинні бути приведені до єдиного вигляду, що дозволяє застосовувати єдині алгоритми обробки, виділяти з них інциденти інформаційної безпеки. Необхідно зберігати події інформаційної безпеки протягом часу, достатнього для забезпечення розслідування інцидентів.
Таким чином, система підтримки процесів управління інцидентами інформаційної безпеки повинна реалізовувати наступний функціонал:
Надання доступу до всіх подій інформаційної безпеки, що генеруються в рамках корпоративного середовища компанії.
Реалізація різних механізмів логічної обробки даних подій незалежно від джерела надходження події.
Забезпечення цілісності та доступності накопичених подій інформаційної безпеки.
Забезпечення доведення подій інформаційної безпеки до відповідального персоналу відповідно до заданого режиму моніторингу.
Забезпечення автоматизації процесів визначення інцидентів, призначення відповідальних і виконавців, контролю виконання розпоряджень з інцидентів.
Для реалізації цих положень необхідно розробити архітектуру системи управління інцидентами, спроектувати комплекс рішень, що реалізують дану архітектуру, вибрати комплекс технічних засобів, здійснити впровадження системи. При розробці технічних рішень необхідно враховувати особливості функціонування ІТ інфраструктури організації, наявні засоби автоматизації.
1.4. Документація системи управління
Система управління інцидентами інформаційної безпеки повинна включати в себе широкий перелік нормативно-розпорядчої та організаційної документації. При документуванні системи необхідно враховувати вимоги з документування, що висуваються міжнародним стандартом ISO/IEC 27001-2005. До складу документації системи можуть входити наступні документи:
Організаційно-розпорядчі документи:
Опис процесу управління інцидентами ІБ.
Опис ролей процесу управління інцидентами ІБ.
Процедура виявлення і сповіщення про інциденти ІБ.
Процедура реагування на інциденти ІБ.
Процедура аналізу і службового розслідування інцидентів ІБ.
Процедура взаємодії з суміжними підрозділами.
Посадові інструкції.
Нормативні документи:
Політика управління інцидентами.
Політика моніторингу подій інформаційної безпеки.
Політика аудиту дій користувачів і адміністраторів.
Робочі документи:
Перелік активів організації та їх власників.
Перелік типових загроз активам.
Перелік осіб, відповідальних за експлуатацію ІТ-систем.
Журнали реєстрації інцидентів.
Форми записів щодо інцидентів.
Форми звітності для керівництва і зацікавлених осіб.
Документація на систему автоматизації управління інцидентами:
Документи техніко-робочого проекту.
Інструкції користувачів і адміністраторів.
1.5. Впровадження системи
Для ефективного функціонування системи управління інцидентами інформаційної безпеки необхідно на стадії впровадження забезпечити ряд ключових чинників. В першу чергу, система управління повинна бути забезпечена вхідним потоком подій інформаційної безпеки, що адекватно відображає стан в рамках обраної області дії. При виявленні і реагуванні на інцидент, необхідно мати дані щодо задіяних активів, їх власників і ступінь критичності. При розслідуванні інцидентів необхідно мати доступ до подій інформаційної безпеки, що вплинули на інцидент, таким як дані аудиту дій користувачів і адміністраторів. При аналізі інцидентів, наданню звітності керівництву необхідно мати можливість зіставлення активів, що підпали під вплив в результаті інциденту і ризиків для основних бізнес-процесів організації.
Таким чином, при виборі області дії системи управління інцидентами і черговості впровадження необхідно вибирати ту область, яка входить в область дії наступних процесів:
Інвентаризації активів.
Аналізу ризиків.
Моніторингу подій інформаційної безпеки.
Аудиту дій користувачів і адміністраторів в інформаційних системах.
1.6. Склад робіт зі створення системи
Роботи з впровадження системи управління інцидентами інформаційної безпеки пропонується проводити у декілька етапів, які детально розглядаються в роботі [4]. Нижче приведений опис робіт кожного етапу.
На першому етапі проводиться обстеження об'єкту. На даному етапі здійснюється збір й аналіз інформації щодо наявних та використовуваних на даний момент регламентах, процедурах і засобах забезпечення інформаційної безпеки і управління інцидентами. Виявляються джерела подій інформаційної безпеки, збираються відомості щодо використовуваних інформаційних систем і технологій обробки інформації. Визначається область дії системи управління інцидентами інформаційної безпеки. Розробляються документи «Завдання щодо робіт з розробки системи управління інцидентами інформаційної безпеки» і «Технічне завдання на автоматизовану систему моніторингу й управління інцидентами інформаційної безпеки».
На другому етапі здійснюється розробка процесів системи управління інцидентами інформаційної безпеки, написання відповідних документів (перелік яких задає «Завдання на роботи»). В рамках даного етапу здійснюється ескізне проектування автоматизованої системи, визначаються основні технічні рішення, розробляється перелік необхідного програмного і апаратного забезпечення.
На третьому етапі здійснюється впровадження системи управління інцидентами інформаційної безпеки. Проводиться навчання персоналу, розподіл ролей, інтеграція системи управління з іншими процесами управління інформаційною безпекою. На даному етапі здійснюється техніко-робоче проектування автоматизованої системи.
На четвертому етапі здійснюється впровадження автоматизованої системи моніторингу й управління інцидентами інформаційної безпеки.
1.7. Практичний підхід до побудови системи управління ІБ
Перший крок в побудові процесно-ролевої моделі управління системи ІБ – це складання та/або аналіз CMDB (configuration management database) – бази елементарних одиниць, що містить активи системи ІБ (ПЗ, апаратне забезпечення, співробітників і процедури). Спочатку потрібно зрозуміти, що є в організації, потім проаналізувати ключові процеси, які необхідно поліпшувати. Як правило, більшість організацій починають з організації служби Help Desk (Service Desk) і впровадження процесу управління інцидентами. Необхідно зосередити пріоритети впровадження процесів і співвіднести їх з планами створення СУІБ. Всі послуги повинні дотримуватися строгих корпоративних стандартів, що стосуються безпеки інформації.
В міру розширення сфери використання інформаційних систем та їх ускладнення, проблема забезпечення інформаційної безпеки (ІБ) загострюється. Безпеку вже неможливо забезпечити одним лише набором технічних засобів і підтримувати тільки силами підрозділу безпеки. Відсутність регулярної оцінки інформаційних ризиків, недостатня інформованість співробітників про правила роботи з інформацією, що захищається, і дотримання режиму ІБ, відсутність формалізованої класифікації інформації по ступеню її критичності і уявлень про те, скільки коштують інформаційні активи, – все це може звести нанівець зусилля організації щодо забезпечення інформаційної безпеки. З підвищенням ролі інформаційних систем в підтримці основних бізнес-процесів організації до цих проблем додаються питання забезпечення безперервності функціонування бізнесу в критичних ситуаціях.
Задачами СУІБ є систематизація процесів забезпечення ІБ, розташування пріоритетів організації в галузі ІБ, досягнення адекватності системи ІБ існуючим ризикам, досягнення її «прозорості». Останнє особливо важливо, оскільки дозволяє чітко визначити, як взаємозв'язані процеси і підсистеми ІБ, хто за них відповідає, які фінансові і людські ресурси необхідні для їх забезпечення та ін.
В цілому, процес управління безпекою (Security Management) відповідає за планування, виконання, контроль і технічне обслуговування всієї інфраструктури безпеки. Організація цього процесу ускладнюється також тією обставиною, що забезпечення інформаційної безпеки компанії пов'язано не тільки із захистом інформаційних систем і бізнес-процесів, які підтримуються цими інформаційними системами.
Як побудувати ефективну систему управління ІБ, яка інтегрувалася б в загальну систему управління ІТ? Як виділити і описати процеси забезпечення інформаційної безпеки? Як забезпечити виявлення інцидентів (нештатних ситуацій) в системі ІБ і як на них реагувати? Як визначити, чи вплине цей інцидент на інші процеси і працездатність інформаційних систем і яким буде цей вплив? Що зробити, щоб в майбутньому ця ситуація не повторилася?
В світовій практиці є розроблені моделі систем управління ІБ, наприклад, «Information Security Management Maturity Model» (ISM3 від ISECOM) або Systems Security Engineering Capability Maturity Model» або стандарт NIST SP800-33. Існує також ряд міжнародних стандартів. Серед них: ISO/IEC 17799:2005 [5] і перший стандарт нової серії ISO/IEC 27001, що прийшов на зміну англійському стандарту BS7799-2:2002.
Проте пряме використання цих моделей і стандартів ISO/IEC 27001 та ISO/IEC 17799:2005 для побудови СУІБ дуже складно. Вони або дуже конкретизовані, а в будь-якій організації, як правило, вже існує певна система процесів, ролей, організаційно-розпорядчих документів інформаційної безпеки, які необхідно інтегрувати в систему управління ІБ. Або, навпаки, рекомендації носять дуже загальний характер.
Підхід до побудови систем управління ІБ, включаючи розробку процесів забезпечення ІБ, базується на наступних методичних рекомендаціях і директивах:
рекомендації ITIL (Information Technology Infrastructure Library, кращий світовий досвід в галузі організації роботи ІТ-служби), а також моделі управління ІТ-ресурсами та ІТ-сервісами Microsoft Operations Framework (MOF);
рекомендації Microsoft Service Management Function (SMF);
стандарт ISO 27001.
Доцільність використання рекомендацій з управління ІТ-ресурсами та ІТ-послугами (і в першу чергу процесів управління інцидентами, змінами) при побудові СУІБ обумовлена тим, що процеси забезпечення інформаційної безпеки нерозривно пов'язані з процесами захисту, а тому управління інформаційними системами повинні бути тісно інтегровані з процесами управління ІТ.
Інтеграція процесу управління безпекою в систему процесів управління ІТ-ресурсами та ІТ-послугами і застосування сервісно-ресурсного підходу при побудові СУІБ (коли забезпечення ІБ розглядається як сервіс з певним рівнем якості, надання якої забезпечується певними фінансовими, технічними, людськими ресурсами) дає цілий ряд переваг.
/
Рис. 1. Процеси еталонної моделі ITIL
/
Рис. 2. Зв'язки процесу управління безпекою з іншими процесами ITIL
При побудові СУІБ необхідно використовувати наведені вище рекомендації і стандарти і на їх основі будувати процесну модель СУІБ, що містить три рівні процесів:
Процеси стратегічного рівня – управління ризиками, управління безперервністю ведення бізнесу, розробка і розвиток політики ІБ верхнього рівня.
Тактичні процеси – розробка і розвиток процедур ІБ, технічної архітектури системи ІБ, класифікація ІТ-ресурсів, моніторинг і управління інцидентами.
Процеси операційного рівня – управління доступом, управління мережною безпекою, перевірка відповідності та ін.
Визначаються взаємозв'язки процесів. В результаті ми одержуємо процесно-сервісну трьохрівневу модель системи управління ІБ, відповідно вимогам стандарту ISO 27001, на яку накладається ролева модель.
1.8. Складнощі управління інцидентами інформаційної безпеки
В багатьох організаціях не завжди можливо прослідкувати за зміною кількості та характеру інцидентів інформаційної безпеки – відсутня процедура управління інцидентами. Часто відсутність інцидентів не вказує на те, що система управління безпекою працює правильно, а означає тільки, що інциденти не фіксуються або не визначаються. Як правило, основні складнощі при управлінні інцидентами викликають наступні моменти.
Визначення інциденту. В компанії відсутня методика визначення інцидентів, а співробітники не знають, які події є інцидентами. Це особливо важливо у випадку інцидентів інформаційної безпеки – вони не завжди заважають нормальній роботі.
Сповіщення про виникнення інциденту. Співробітники компанії часто не обізнані про те, кого і в якій формі слід ставити перед фактом при виникненні інциденту, – наприклад, не визначені ні форми звітів, ні перелік осіб, яким необхідно відправляти звіти про інциденти.
Реєстрація інциденту. Відповідальним особам (навіть якщо такі призначені) часто не надається методика реєстрації інцидентів – не існує спеціальних журналів їх реєстрації, а також правил і термінів заповнення.
Усунення наслідків і причин інциденту. В організаціях, як правило, відсутня документально зафіксована процедура, що описує дії, які необхідно виконати з метою усунення наслідків і причин інциденту. В першу чергу така процедура повинна передбачати, щоб заходи щодо усунення наслідків і причин інциденту не порушували процедури їх розслідування: усунення наслідків інциденту не повинне «замітати сліди», щоб неможливо було встановити винних в інциденті.
Розслідування інциденту. На етапі розслідування інцидентів основну роль відіграють: ведення журналів реєстрації подій, чітке розділення повноважень користувачів, відповідальність за виконані дії – важливі докази того, хто приймав участь в інциденті і які дії він виконував. На жаль, про розслідування інцидентів в організаціях часто просто забувають. Як тільки наслідки інциденту усунені та бізнес-процеси відновлені, подальші дії щодо розслідування інциденту і здійснення коректуючих і превентивних заходів не виконуються.
Реалізація дій, застерігаючих повторне виникнення інциденту. Як правило, якщо організації був завданий який-небудь збиток, то до винних у виникненні інциденту (які визначені без необхідних в таких випадках процедур) все ж таки застосовуються різні стягнення, проте внесення дисциплінарних стягнень не завжди підкоряється затвердженим процедурам й інші дії щодо запобігання повторення інциденту виконуються теж не завжди.
Управління інцидентами – одна з найважливіших процедур управління інформаційною безпекою. Перш за все, важливо правильно і своєчасно усунути наслідки інциденту, а також мати нагоду проконтролювати, які дії були виконані для цього. Необхідно також розслідувати інцидент, що включає визначення причин його виникнення, винних осіб і конкретних дисциплінарних стягнень. Далі, як правило, слід виконати оцінку необхідності дій щодо усунення причин інциденту, якщо потрібно – реалізувати їх, а також виконати дії щодо попередження повторного виникнення інциденту. Окрім цього, важливо зберігати всі дані про інциденти інформаційної безпеки, оскільки статистика інцидентів інформаційної безпеки допомагає усвідомлювати їх кількість і характер, а також зміну в часі. За допомогою інформації про статистику інцидентів можна визначити найбільш актуальні загрози для організації і, відповідно, максимально точно планувати заходи щодо підвищення рівня захищеності інформаційної системи організації.
2. Методи управління інцидентами ІБ
2.1. Що таке інцидент?
Згідно прийнятому в ITIL визначенню під «інцидентом» розуміється «будь-яка подія, що не є елементом нормального функціонування служби і при цьому надає або здатна зробити вплив на роботу служби шляхом її переривання або зниження якості».
Основні категорії інцидентів:
Додатки:
служба недоступна;
помилка в додатку, що не дає змогу клієнту нормально працювати;
вичерпано дисковий простір.
Устаткування:
збій системи;
внутрішній сигнал тривоги;
відмова принтера.
Заявки на обслуговування:
надходження заявки на отримання додаткової інформації, поради, документації;
забутий пароль.
Більшість груп ІТ-фахівців має відношення щодо усунення тих або інших інцидентів. Служба Service Desk відповідає за моніторинг процесу усунення всіх зареєстрованих інцидентів, оскільки є власником всіх таких інцидентів. Цей процес більшою мірою реактивний; для ефективної реакції на інциденти повинен бути визначений формальний метод роботи співробітників, що включає використання необхідного програмного забезпечення.
Ті інциденти, які не можуть бути дозволені безпосередньо службою Service Desk, повинні бути переадресовані відповідним фахівцям. Спосіб розв'язання інциденту або варіант його обходу повинен бути встановлений і доведений до користувачів якнайшвидше. Це випливає з головної цілі – мінімізації негативного впливу на основну діяльність користувачів. Після усунення причини інциденту і відновлення служби до обумовленого в SLA рівня інцидент закривається.
2.2. Управління інцидентами інформаційної безпеки
Частота появи і кількість інцидентів, пов'язаних з інформаційною безпекою