 |
|
|||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Строительные нормативные акты
   
|
||||||||||||||
|
||||||||||||||
ДСТУ ISO/TR 13335-2:2003 Інформаційні технології. Настанови з керування безпекою інформаційних технологій (IT). Частина 2. Керування та планування безпеки IT
 |
|
|||||||||||||
|
ПЕРЕДМОВА 1 ВНЕСЕНО: Технічний комітет зі стандартизації «Інформаційні технології» (ТК 20) при Держ- ПЕРЕКЛАД І НАУКОВО-ТЕХНІЧНЕ РЕДАГУВАННЯ: А. Анісімов, д-р фіз.-мат. наук; О. Марковсь-кий, канд. техн. наук; Є. Осадчий, канд. техн. наук; В. Осадчий; О. Осадчий; В. Ткаченко; Т. Кальчук; В. Чорноморець; М. Афанасенко; В. Кравченко
Ступінь відповідності ідентичний (IDT) Переклад з англійської (en) 4 УВЕДЕНО ВПЕРШЕ ЗМІСТ Національний вступ
8 Корпоративна методика безпеки IT
9 Організаційні аспекти безпеки IT
10 Вибір стратегії корпоративного аналізування ризику
11 Рекомендації щодо захисту IT
17 Висновки НАЦІОНАЛЬНИЙ ВСТУП Цей стандарт є тотожний переклад ISO/IEC TR 13335-2:1997 Information technology Guidelines for the management of IT Security Part 2: Managing and planning IT Security (Інформаційні технології. Настанови з керування безпекою інформаційних технологій (IT). Частина 2. Керування та планування безпеки IT). Призначеність ДСТУ ISO/IEC TR 13335 надати рекомендації, а не конкретні рішення з керування безпекою інформаційних технологій (IT). Кваліфікація осіб, відповідальних за безпеку IT у межах організацій повинна бути достатньою для адаптування матеріалів, поданих у цьому стандарті, до конкретних потреб організацій. Технічний комітет, відповідальний за ISO/IEC TR 13335-2:1996, ISO/IEC JTC 1. Технічний комітет, відповідальний за цей стандарт, ТК 20 «Інформаційні технології». ISO/IEC TR 13335 складено з п'яти частин. Частина 1 описує фундаментальні концепції та моделі, що їх використовують для описування процесів керування безпекою IT. Цей документ призначено для адміністраторів, відповідальних за безпеку IT та за загальну безпеку в організації. Частина 2 описує аспекти керування і планування, її призначено для адміністраторів, до компетенції яких належить взаємодія із системами IT організації. До них належать адміністратори IT, які відповідальні за спостереження над процесами розробляння, реалізування, випробовування, постачання або оперування системами IT, та адміністратори, відповідальні за отримання максимальної користі від використовування систем IT. Частина 3 описує методи захисту і призначена для використовування тими, хто залучений до керування протягом усього життєвого циклу проекту, зокрема під час планування, проектування, реалізування, випробовування, аналізування або застосовування. Частина 4 містить настанови щодо вибору засобів захисту та їх супровід основними моделями й елементами керування безпекою. Вона також показує, як ці засоби можуть доповнювати техніку безпеки, описану в частині 3, і як можна використовувати додаткові методи оцінювання під час вибору засобів захисту. Частина 5 містить настанови щодо організації взаємозв'язку систем IT із зовнішніми мережами. Вона містить також настанови щодо вибирання і використовування засобів захисту, для убез-печнювання з'єднань і послуг, що надають з'єднання і додаткові засоби захисту, які застосовують для під'єднаних систем IT. Структура ДСТУ ISO/IEC TR 13335 відповідає структурі ISO/IEC TR 13335 і також буде складатися з п'яти частин, три з яких згармонізовані тепер, а саме: ДСТУ ISO/IEC TR 13335-1:2003 Інформаційні технології. Настанови з керування безпекою інформаційних технологій. Частина 1. Концепції та моделі безпеки IT; ДСТУ ISO/IEC TR 13335-2:2003 Інформаційні технології. Настанови з керування безпекою інформаційних технологій. Частина 2. Керування та планування безпеки інформаційних технологій; ДСТУ ISO/IEC TR 13335-3:2003 Інформаційні технології. Настанови з керування безпекою інформаційних технологій. Частина 3. Методи керування захистом інформаційних технологій; а дві інші частини: ДСТУ ISO/IEC TR 13335-4 та ДСТУ ISO/IEC TR 13335-5 будуть згармонізовані в майбутньому. До стандарту внесено такі редакційні зміни: слова «ця частина ISO/IEC TR 13335» замінено на слова «ця частина стандарту», а «цей до розділу 2 «Нормативні посилання» подано «Національне пояснення», яке виділено структурні елементи цього стандарту: «Обкладинку», «Передмову», «Зміст», «Національ Необхідно взяти до уваги, що в Україні чинний ДСТУ ISO/IEC TR 13335-1:2003 Information technology Guidelines for the management of IT Security Part 1: Concepts and models for IT Security (Інформаційні технології. Настанови з керування безпекою інформаційних технологій (IT). Частина 1. Концепції та моделі безпеки IT). ДСТУ ISO/IEC TR 13335-2:2003 НАЦІОНАЛЬНИЙ СТАНДАРТ УКРАЇНИ Інформаційні технології. Настанови з керування безпекою інформаційних технологій (IT). Частина 2. Керування та планування безпеки IT ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ БЕЗОПАСНОСТЬЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Часть 2. Управление и планирование безопасности ИТ INFORMATION TECHNOLOGY GUIDELINES FOR THE MANAGEMENT OF IT SECURITY Part 2. Managing and planning IT Security Чинний від 2004-10-01 1 СФЕРА ЗАСТОСУВАННЯ У цьому стандарті подано рекомендації, призначені для тих, хто пов'язаний з керуванням безпекою IT, і які стосуються відносин між ними. Ці рекомендації можна використовувати для ідентифікації і керування усіма аспектами безпеки IT. Для повноцінного розуміння цього стандарту необхідно ознайомитися з концепціями і моделями, описаними в частині 1. 2 НОРМАТИВНІ ПОСИЛАННЯ У цьому стандарті є посилання на такий стандарт: ISO/IEC TR 13335-1:1996 Information technology Guidelines for the management of IT Security Part 1 :Concepts and models for IT Security. НАЦІОНАЛЬНЕ ПОЯСНЕННЯ ISO/IEC TR 13335-1:1996 Інформаційні технології. Настанови з керування безпекою IT. Частина 1. Концепції та моделі безпеки IT. З ТЕРМІНИ ТА ВИЗНАЧЕННЯ ПОНЯТЬ У цьому стандарті використано терміни і визначення, які наведено в ISO/IEC TR 13335-1. Зокрема такі: обліковість, активи, достовірність, доступність, базові засоби керування, конфіденційність, цілісність даних, ураження, цілісність, захист в інформаційних технологіях, стратегія захисту в інформаційних технологіях, надійність, залишковий ризик, ризик, аналіз ризику, керування ризиком, засоби захисту, цілісність системи, загроза, уразливість. 4 СТРУКТУРА Цей стандарт складається з 17 розділів. Розділи 5 і 6 подають інформацію про цілі та основні засади цього документа. Розділ 7 подає загальний огляд різних дій для успішного керування безпекою IT. Розділи з 8 по 16 конкретизують ці дії. У розділі 17 подано висновки. 5 ПРИЗНАЧЕНІСТЬ Призначеність цього стандарту описати різні дії, пов'язані з керуванням і плануванням безпеки IT, і розподіл обов'язків персоналу в організації. Стандарт призначено для персоналу IT, який відповідає за впровадження, експлуатацію, застосування системи безпеки IT і ефективність використовування систем IT. Цей стандарт буде корисний усім, хто виконує службові обов'язки стосовно інформаційно-технологічних систем організацій. 6 ОГЛЯДАННЯ Організації від урядових до комерційних накопичують інформацію, яка відображає їхню діяльність. Втрата конфіденційності, цілісності, доступності, обліковості, достовірності і надійності інформації може шкодити роботі організацій. Отже, захист інформації і керування безпекою систем IT в організаціях є найголовнішими потребами. Необхідність захисту інформації є особливо актуальною, тому що багато організацій мають внутрішні й зовнішні мережні з'єднання систем IT. Керування безпекою систем IT це процес досягнення і забезпечення необхідних рівнів конфіденційності, цілісності, доступності, обліковості, достовірності й надійності. До функцій керування безпекою систем IT належать: визначання цілей, стратегій і методик під час організовування захисту IT; визначання необхідних умов організовування захисту IT; ідентифікування й аналізування загроз безпеки для всіх активів IT в організації; ідентифікування й аналізування ризиків; визначання відповідних засобів захисту; контролювання за застосовуванням і функціюванням засобів захисту, що є необхідними розробляння і реалізування програми компетентності в захисті; виявляння інцидентів і реагування на них. Для повноцінного реалізування цих функцій керування безпекою в системах IT захист має бути невід'ємною частиною загального плану керування організацією. Тому деякі описані в цьому стандарті положення захисту є більш значущі для керування. Завдання стандарту зосереджуватись не на різноманітних схемах керування, а швидше на конкретних аспектах захисту та їх зв'язку з керуванням IT у цілому. 7 КЕРУВАННЯ БЕЗПЕКОЮ IT 7.1 Планування і загальне оглядання процесів планування і керування Планування і керування захистом IT загальний процес встановлювання і підтримування програми безпеки IT в організації. На рисунку 1 відображено основні положення цього процесу. Відмінність типів керування, розмірів і структур організацій спричинює орієнтацію процесу на середовище. Важливо, що всі аспекти та функції, які зображені на рисунку 1, пристосовані до типу, розміру і структури організації та способу ведення діяльності. Безумовно, ці огляди керування є лише частиною діяльності організації. Відправною точкою є встановлювання чітких цілей захисту IT організації. Ці цілі виходять з цілей вищого рівня (наприклад, з цілей ділової активності) і, в свою чергу, визначають стратегію безпеки IT організації і корпоративну методику безпеки IT, розглянуті докладно в розділі 8. Отже, частиною корпоративної методики безпеки IT є створення відповідної структури організації, яка буде гарантувати досягнення певної мети.
Рисунок 1 Загальна схема планування і керування безпекою IT 7.2 Загальне оглядання керування ризиком Керування ризиком складається з чотирьох різних дій: визначання загальної стратегії керування ризиком згідно з корпоративною методологією вибирання засобів захисту для конкретної системи IT згідно з аналізуванням ризику або у розробляння методик захисту системи IT, виходячи з рекомендацій безпеки, і за потреби, розробляння проектів безпеки IT щодо застосування засобів захисту на основі схвалених 7.3 Загальне оглядання застосування Застосування необхідних засобів захисту для кожної системи IT має відповідати проектам безпеки IT. Поліпшення загальної компетентності в захисті IT, яким часто нехтують, є важливим аспектом ефективності засобів захисту. Рисунок 1 показує, що ці два завдання, а саме: застосування засобів захисту і програму компетентності в захисті треба розв'язувати паралельно, оскільки звична поведінка конкретного користувача не може бути раптово змінена й для освоєння потрібен певний час. 7.4 Загальне оглядання механізму доопрацювання Діяльність, яка описана в розділі 16 «Механізм доопрацювання» охоплює: обслуговування засобів захисту для забезпечення їхньої безперервної й ефективної роботи; перевіряння, яке гарантує, що засоби захисту задовольняють обумовлені методики і проекти; контролювання активів, загроз, уразливості і засобів захисту щодо відхилень, щоб виявити відстежування інциденту, щоб гарантувати відповідну реакцію на небажані події. 7.5 Інтеграція захисту IT Усі дії щодо захисту IT будуть найефективнішими, якщо їх застосовують одночасно у всій організації і з самого початку всякого життєвого циклу системи IT. Процес захисту IT це важливий окремий цикл діяльності, який повинен бути інтегрований в усі стадії життєвого циклу системи IT. Захист найефективніший, якщо його інтегрують в нові системи з самого початку; успадковані системи та їхня діяльність мають користь від інтеграції захисту протягом усього періоду. Життєвий цикл системи IT може бути поділений на три базові стадії. Кожна з цих стадій стосується безпеки IT таким способом: проектування: захист в IT треба враховувати протягом усього процесу проектування та комплектація: вимоги захисту IT потрібно інтегрувати в процеси проектування, розроблян дії: захист IT треба інтегрувати в оперативне середовище. Система IT, що її використову Убезпеченювання IT безперервний процес з багатьма зворотними зв'язками в середині і між стадіями життєвого циклу системи IT. Повний зворотний зв'язок наведено на рисунку 1. У більшості випадків зворотний зв'язок пронизує всю основну діяльність процесу захисту IT. Це забезпечує безперервний потік інформації щодо уразливості, загроз і засобів захисту системи IT протягом усіх трьох стадій життєвого циклу системи IT. Також варто зазначити, що кожна із сфер діяльності організації може визначити унікальні вимоги щодо захисту IT. Ці сфери повинні взаємно зміцнювати одна одну і весь процес захисту IT, спільно використовуючи інформацію про стан безпеки, що в свою чергу може впливати на процес прийняття керівних рішень. 8 КОРПОРАТИВНА МЕТОДИКА БЕЗПЕКИ IT 8.1 Цілі Цілі (які повинні бути досягнуті), стратегії (як досягнути цих цілей) і методики (правила для досягнення цілей) можна визначити для кожного рівня організації і для кожного ділового підрозділу чи відділу. Для досягнення ефективної безпеки IT необхідно впорядкувати різні цілі, стратегії і методики для кожного організаційного рівня і ділового підрозділу. Узгодженість між відповідними документами, незважаючи на вплив різних точок зору, дуже важлива, оскільки більшість загроз (таких як злом системи, знищення файлів і пожежі) загальні проблеми ділової активності. 8.2 Зобов'язання керівництва Зобов'язання вищого керівництва щодо питань безпеки IT є важливим завданням і має приводити до офіційно узгодженої й задокументованої корпоративної методики безпеки IT. Корпоративна методика безпеки IT повинна бути отримана з корпоративної стратегії захисту. 8.3 Взаємозв'язки методик Рисунок 2 Залежності між різними методиками Відповідно до цього поняття корпоративна методика безпеки IT може бути включена до корпоративного технологічного й методологічного керування, і все це разом формує основу для загальних стратегічних положень в IT. Ці положення повинні містити деякі вагомі твердження на користь захисту, особливо якщо є необхідність узгодження захисту і стратегії. Рисунок 2 показує залежність між різними методиками. Незалежно від документації та адміністративної структури, що її використовують в організації, дуже важливо, щоб різні положення описаних методик були спрямовані, і це підтримає узгодженість.
Інші, деталізованіші, методики захисту IT необхідні для певних систем і служб або для групи систем IT і служб, їх зазвичай описують як методики захисту систем IT. Це важливий аспект керування, оскільки їхній контекст і межі чітко визначені й обґрунтовані діловими і технологічними підставами. 8.4 Елементи корпоративної методики безпеки IT Корпоративна методика безпеки IT повинна охоплювати принаймні такі розділи: вимоги безпеки IT, наприклад, умови конфіденційності, цілісності, доступності, обліковості, інфраструктура організації і розподіл обов'язків; інтеграція захисту в розробляння і реалізування системи; директиви і процедури; визначання класів для класифікації інформації; стратегії керування ризиком; планування непередбачених обставин; підготовка персоналу (особлива увага повинна приділятися службовцям, що займають компетентність і навчання; юридичні і регуляторні зобов'язання; зовнішнє керування розроблянням й інформаційна взаємодія; реакція на інциденти. 9 ОРГАНІЗАЦІЙНІ АСПЕКТИ БЕЗПЕКИ IT 9.1 Функції та обов'язки Безпека IT є міжгалузевою темою і стосується кожного проекту IT, системи і всіх користувачів IT в організації. Відповідний розподіл посад і розмежування обов'язків гарантують, що всі важливі завдання будуть успішно й ефективно виконані. Цієї мети досягають за допомогою різних організаційних заходів залежно від розміру і структури організації. У кожній конкретній організації мають існувати такі структури: рада з безпеки IT, яка підсумовує міжгалузеві досягнення і затверджує директиви і стан корпоративний (головний) контролер безпеки IT, який діє як центральна ланка всіх аспектів Як рада з безпеки IT, так і корпоративний контролер безпеки IT повинні мати добре визначені та однозначні обов'язки і мати достатній вплив, щоб гарантувати прив'язку до корпоративної методології безпеки IT. Організація повинна забезпечити надійний зв'язок, а також визначити повноваження й відповідальність корпоративного контролера безпеки IT, ці обов'язки повинні бути схвалені радою з безпеки IT. Перелік цих обов'язків може бути доповнений шляхом зовнішніх консультацій. Рисунок 3 показує типовий приклад зв'язків між корпоративним контролером безпеки IT, радою з безпеки IT і представниками інших підрозділів в організації, таких як інші відділи безпеки, товариства користувачів і персонал IT. Ці стосунки можуть полягати як у безпосередньому керуванні, так і у функційному. Наприклад, для організовування безпеки IT, зображеної на рисунку 3, використовується три організаційних рівні, їх можна легко пристосувати до будь-якої організації, додаючи або виключаючи відповідні рівні згідно з потребами організації. Невеликі й середні організації можуть мати корпоративного контролера безпеки IT, чиї обов'язки охоплють всі питання, пов'язані з безпекою. Коли функції тісно залежать одна від одної, важливо забезпечити відповідні перевіряння й утримання рівноваги, щоб уникнути концентрації дуже великої кількості обов'язків у однієї особи, без можливості впливу на неї або контролю за нею.
Рисунок 3 Приклад організовування безпеки IT 9.1.1 Рада з безпеки IT Така рада складається з персоналу необхідного рівня кваліфікації для визначання вимог, розробляння методик, складання програми захисту, аналізування здобутків та видачі вказівок (завдань, рекомендацій) корпоративному контролеру безпеки IT. Для цього може використовуватися уже існуюча рада, або бути створена окрема рада з безпеки IT. Ця рада може засновуватися на наявній структурі: повідомлення керівного комітету IT про стратегічні плани безпеки; розробляння корпоративної методики безпеки IT в межах підтримки всієї стратегії IT перенесення корпоративних методик безпеки IT в програму безпеки IT; контролювання застосування програми захисту в IT; контролювання ефективності корпоративних методик безпеки IT; підтримування компетентності щодо проблем безпеки IT; консультації з питань персоналу, фінансів, інформації, знань, іншого, необхідних для Для максимальної ефективності роботи в раду повинні входити спеціалісти з базовою підготовкою з захисту і технічних аспектів системи IT, а також представники постачальників послуг і користувачів системи IT. Знання і кваліфікація в усіх цих галузях необхідні для розробляння практичних корпоративних методик безпеки IT. 9.1.2 Корпоративний контролер безпеки IT Оскільки відповідальність за безпеку IT розподілена, то існує ризик, що в результаті ніхто не буде відчувати відповідальності взагалі. Щоб уникнути цього, повинен бути призначений відповідальний за всі питання безпеки IT. Корпоративний контролер безпеки IT повинен діяти як центральна ланка для всіх аспектів безпеки IT в організації. Для цього може бути задіяна вже наявна посада, з додатковими обов'язками, або, що найчастіше доцільно, необхідна окрема посада. Треба надавати перевагу особі, що вже має базовий рівень підготовки з питань захисту IT. Головні обов'язки корпоративного контролера безпеки IT: нагляд за реалізацією програми захисту IT; зв'язок і звітування перед органом з безпеки IT; підтримка корпоративних методик захисту IT і директив; координація розслідувань інцидентів; керування ходом проведення програми компетентності безпеки на рівні корпорації; визначання компетенції системних контролерів безпеки щодо проекту (і, при наявності, 9.1.3 Контролер безпеки проекту IT і контролер безпеки системи IT Індивідуальні проекти або системи повинні мати відповідального за захист, якого називають контролером безпеки IT. У деяких випадках це може бути посада за сумісництвом. Обов'язки керування цими контролерами належать до компетенції корпоративного контролера безпеки IT (або, де можливо, контролера підрозділу безпеки IT). Контролер безпеки в цьому випадку діє як головна ланка всіх аспектів захисту проекту, системи або групи систем. Головні обов'язки цих посадовців: зв'язок та підзвітність корпоративному контролеру безпеки (або, де можливо, контролеру ініціювання і підтримування проекту або методики захисту системи IT; розробляння і реалізування проекту безпеки; щоденне контролювання реалізації і використовування захисних засобів IT; ініціювання і допомога в запобіганні інцидентам. 9.2 Відповідальність Відповідальність є необхідною для забезпечення ефективного захисту в IT, якщо керування на різних рівнях забезпечується зусиллями конкретних осіб. Бізнесова відповідальність включає в себе і цілі безпеки IT: розуміння глобальних потреб організації; розуміння необхідності захисту IT в організації; пояснення зобов'язань щодо захисту IT; готовність приділяти увагу потребам захисту IT; готовність розподіляти ресурси для захисту IT; обізнаність на самому високому рівні, що таке засоби захисту IT або їхні складові (межі, Цілі безпеки IT повинні бути оголошені для всієї організації. Кожний службовець чи субпідрядник повинен знати свої функції та обов'язки, їх вплив на захист IT і активно брати участь в досягненні цих цілей. 9.3 Послідовний підхід Послідовний підхід до захисту IT треба застосовувати до процесів проектування, експлуатування й оновлення. Захист повинен бути невід'ємним складником протягом усього життєвого циклу інформації і системи IT від проектування до знищення. Організаційна структура, показана на рисунку 3, може підтримувати узгоджений підхід до захисту IT у межах організації. Це, однак, вимагає прив'язки до стандартів, охоплюючи міжнародні, національні, регіональні, промислові і корпоративні стандарти або правила, які вибирають і застосовують згідно з потребами захисту ІТ організації. Технічні стандарти повинні бути доповнені правилами і рекомендаціями щодо їх впровадження, використовування і керування ними. Переваги використовування стандартів такі: інтегрованість захисту; здатність до взаємодії; послідовність; мобільнність; економність розмірів (шкали затрат); взаємодія між організаціями. 10 ВИБІР СТРАТЕГІЇ КОРПОРАТИВНОГО АНАЛІЗУВАННЯ РИЗИКУ Організація з метою поліпшення своєї інформаційної безпеки повинна виробити стратегію керування ризиком, яка відповідає її оточенню і містить засоби, що дають змогу ефективно використати характеристики ризиків. Для цього необхідна стратегія, яка концентрує зусилля для розробляння захисту саме там, де це потрібно, для оптимізування вартісних і часових показників. Жоден ресурс, ефективне використання або звернення до детального аналізу всіх систем не є ефективним без врахування серйозності ризиків. Підхід, який забезпечує рівновагу між цими екстремальними показниками, передбачає аналіз посадовцями високих рівнів для встановлення потреб в захисті системи IT, а потім проведення докладного досліджування з урахуванням цих потреб. Потреби в захисті будь-якої організації будуть залежати від її розміру, виду ділової активності, який вона здійснює, її оточення і мікрополітики. Корпоративна стратегія аналізування ризику, яку планується вибрати, повинна прямо стосуватися цих аспектів. У деяких ситуаціях організація вирішує питання відносно застосування засобів захисту або призупинення їхньої дії на даному етапі. Таке рішення потрібно приймати тільки після того, як організація ретельно здійснить всі аналізи. Якщо таке рішення прийняте, адміністрація повинна знати всі потенціальні ризики і несприятливі ситуації й імовірність виникнення небажаного інциденту. Без цих відомостей організація може ненавмисно порушити закони або правила і може довести свою ділову активність до потенційного збитку. Рішення і його затвердження про пасивність або відкладання застосування засобів захисту повинні бути прийняті тільки після того, як зроблено докладний розгляд цих та інших можливих несприятливих наслідків. На основі результатів ретельних аналізів можуть бути вибрані засоби захисту для зменшення ризиків, застосовуючи один із чотирьох варіантів, описаних в 10.1-10.4. В них пояснені переваги і недоліки кожного з варіантів. 10.1 Основний підхід Перший варіант передбачає вибір багатьох засобів захисту для досягнення базового рівня захисту всіх систем. Ряд стандартних засобів захисту запропоновано в основних документах і практичних рекомендаціях з використовування. Після експертизи основних вимог можна викори- стати засоби захисту інших організацій, наприклад, міжнародних і державних організацій із стандартизації, промислового сектора або іншої подібної компанії (зі схожою діловою активністю, розмірами, системами IT і застосованнями), заздалегідь їх пристосувавши до своїх потреб. Існує ряд переваг використовування цього підходу: не потрібно ніяких витрат для детального аналізування ризику; скорочуються час і зусилля на вибір засобів захисту; зазвичай не потрібно значних витрат на визначання основних засобів захисту; ті самі або подібні основні засоби захисту можуть бути адаптовані до багатьох систем без Недоліки цього підходу: якщо базовий рівень захисту визначено як дуже високий, то це може або занадто дорого коштувати, або не забезпечувати необхідного захисту деяких систем, а якщо основний рівень дуже низький, то може виявитися, що для деяких систем немає достатнього рівня захисту. Може виникнути утруднення в керуванні змінами, що залежать від захисту. Наприклад, якщо система модернізована, можуть виникнути труднощі у визначенні, чи є первинні основні засоби захисту, як і раніше, ефективними. 10.2 Неформальний підхід Другий підхід складається з неформального, прагматичного аналізування ризику для всіх систем. Неформальний підхід базується не на структурованих методах, а на обізнаності і досвіді осіб. Якщо експертизу захисту не можна провести своїми силами, то залучають зовнішніх консультантів. Переваги цього підходу: немає потреби набувати додаткових навичок або проводити навчання для здійснення неформального аналізування і воно може бути проведено значно швидше, ніж докладне аналізування ризику. Отже, цей підхід ефективний з точки зору вартості і найбільше підходить для малих організацій. Проте у цього підходу є недоліки: відсутність структурованого підходу збільшує імовірність неврахування деяких ризиків і оскільки підхід є неформальним, результатам властива суб'єктивність поглядів і упере існує лише незначне мотивування для вибору засобів захисту, отже, складно визначати може виникнути складність у керуванні безпекою під час змін без частого аналізування. 10.3 Докладне аналізування ризику Третій підхід полягає в докладному аналізуванні ризику для всіх систем. Докладне аналізування ризику включає визначання й оцінювання активів, а також оцінювання рівнів загроз для цих активів і їх уразливості. Цю інформацію використовують для визначання ризиків. Виконання цього аналізу ризику сприяє ідентифікуванню, вибору і впровадженню засобів захисту, скоригованих ідентифікованими ризиками стосовно активів, а також знижує ці ризики до прийнятного визначеного рівня керування. Докладне аналізування ризику може бути ресурсомістким процесом і тому вимагає чіткого визначення меж і постійної уваги адміністрації. Переваги цього підходу: визначають рівень захисту відповідно до вимог безпеки для кожної системи; додаткова інформація, що отримана з детального аналізування ризику, сприяє керуванню Основний недолік цього підходу: він потребує значної кількості часу, зусиль і експертизи для отримання корисних результатів. 10.4 Змішаний підхід Четвертий підхід насамперед ідентифікує ті системи, які мають підвищений ризик або є кри- тичними щодо ділової активності і передбачає високорівневе аналізування ризику. Ґрунтуючись на отриманих при цьому результатах, системи поділяються на ті, які потребують докладного аналізування ризику для досягнення відповідного захисту, і ті, для яких є достатнім базовий захист. Цей підхід комбінація кращих положень, описаних в 10.1 і 10.3. Таким чином, він забезпечує рівновагу та мінімізацію часу і зусиль, що їх витрачають на ідентифікацію засобів захисту, для того щоб гарантувати відповідну захищеність усіх систем. Переваги цього підходу: поєднання на початку швидкості і простоти підходу підвищує імовірність прийняття про можливість швидко отримати уявлення про стратегію програми захисту в організації, що ресурси і кошти можуть бути спрямовані на отримання максимальної вигоди, і системи Недоліки цього підходу: якщо високорівневий аналіз ризику дає неточні результати, то деяким системам, для яких необхідне докладне аналізування ризику, не буде приділено належної уваги. Звичайно, така ситуація малоймовірна, якщо результати аналізування ризику відповідно перевірені, але в будь-якому випадку такі системи все ж повинні додатково підтримуватися базовими засобами захисту. У більшості випадків цей підхід є найрентабельнішим рішенням, і його рекомендовано до застосування більшістю організацій. 11 РЕКОМЕНДАЦІЇ ЩОДО ЗАХИСТУ IT Будь-який з підходів, наведених у розділі 10, повинен надати мінімальний набір рекомендацій для доведення ризику захисту до допустимого рівня. Ці рекомендації повинні бути схвалені адміністрацією і включати: критерії для визначання допустимих рівнів ризиків для систем IT, що розглянуті; вибирання засобів захисту, які доводять ризики до допустимого рівня; переваги, отримані внаслідок застосування цих засобів захисту, і значне зниження ризиків; приймання ризиків, що залишаються після застосування всіх засобів захисту. 11.1 Вибирання засобів захисту Є декілька типів засобів захисту: ті, які попереджають, зменшують, контролюють, виявляють або виправляють небажані інциденти, і ті, які відновлюють після них. Запобігання може охоплювати засоби, що стримують небажані дії і що забезпечують краще розуміння захисту. Основні сфери, де можна застосовувати відповідні захисні засоби, і деякі приклади для кожної сфери такі: апаратні засоби (резервне копіювання, ключі); програмне забезпечення (електронні підписи, реєстрація, антивірусні засоби); зв'язок (мережні пристрої захисту (firewall), кодування інформації); фізичне оточення (огороджувальні споруди, контрольні пункти); персонал (компетентність персоналу, процедури для швидкого анулювання доступу служ адміністрування (повноваження, розподіл апаратних засобів, ліцензоване керування). вибирання повинен враховувати залежність засобів захисту. У процесі вибирання засобів захисту треба також перевіряти, чи не залишилося прогалин. Такі прогалини роблять можливим обхід наявних засобів захисту і дають змогу випадковим загрозам викликати пошкодження. Для нових систем або для тих, де зроблені корінні зміни, вибирання засобів захисту повинно враховувати структуру захисту. Структура захисту є частиною загальної структури системи і відображає, наскільки задовольняються вимоги безпеки системи IT. Це також стосується і технічних засобів захисту, навіть коли розглядають нетехнічні аспекти. Усі засоби захисту вимагають уваги, щоб гарантувати ефективне використання. Багато засобів захисту вимагають підтримки керівництвом для досягнення ефективності. Ці чинники треба враховувати протягом всього процесу вибирання засобів захисту. Дуже важливо, щоб використання засобів захисту було ефективним і не викликало зайвого втручання користувача або органу керування. Якщо засоби захисту спричинюють істотні зміни, то їх застосування потрібно враховувати в програмі компетентності захисту, а також в керуванні змінами і настроюванням системи. 11.2 Врахування ризику Після застосування вибраних засобів захисту завжди буде існувати залишковий ризик. Це пов'язано з принциповою неможливістю побудови абсолютно захищеної системи, а також з тим, що деякі активи, можливо, залишаються навмисно незахищеними (наприклад, через низький ризик або високі витрати на засоби захисту порівняно з розрахунковою вартістю активів, які треба захищати). Перший крок процесу враховування ризику полягає в оцінці вибраних засобів захисту, в ідентифікації і визначенні всіх залишкових ризиків. Наступний крок повинен кваліфікувати залишкові ризики як такі, що «можуть бути допущеними», і такі, що «не можуть бути допущеними» організацією. Очевидно, що неприйнятні ризики не можна допускати і тому необхідні додаткові засоби захисту, що обмежують ураження або наслідки ризиків. У кожному з цих випадків необхідно прийняти відповідне рішення. Або ризик треба оцінювати як допустимий, або необхідні додаткові витрати на засоби захисту, які понизять ризик до допустимого рівня. 12 МЕТОДИКА ЗАХИСТУ СИСТЕМИ IT Методики, що їх розробляють для захисту системи IT, повинні ґрунтуватись на корпоративній або відомчій методиці захисту. Ці методики захисту системи містять багато принципів і правил для убезпечнювання систем і служб. Методики повинні бути реалізовані у вигляді застосування відповідних засобів захисту до систем і служб, щоб гарантувати, що досягнуто належного рівня захисту. Методики захисту системи IT повинні бути затверджені вищим керівництвом як обов'язкові набори принципів і правил, щоб гарантувати, що фінансові і трудові ресурси використовують за призначенням. Ключові моменти, які треба враховувати під час визначання кожної методики захисту системи IT:
недоступності, відмови або знищення допоміжних, або основних активів, включаючи несанкціонованої зміни інформації або програмного забезпечення; несанкціонованого розголошування даних, з наслідками, що їх вимірюють кількісно, такими
Захист IT вимагає планового підходу і не повинен розглядатися окремо. Це має бути головним питанням у процесі стратегічного планування для гарантування, що захист був запланований та інтегрований в систему спочатку. У більшості випадків затримка в застосуванні засобів захисту веде до більших витрат або стає непрактичним. 13 ПЛАН ЗАХИСТУ IT План захисту IT документ, який визначає узгоджені заходи, які необхідно здійснити для реалізації методики захисту системи IT. Цей план повинен включати короткі, середні і довготривкі першорядні заходи з відповідними капіталовкладеннями, термінами фінансування, вартістю експлуатації, навантаженнями тощо, а також графіком впровадження. Він повинен містити:
короткий розгляд системи IT для узгодження з задачами захисту організації, відображени визначення засобів захисту, підтриманих і затверджених вищим керівництвом згідно оціне оцінку фактичного рівня впевненості в засобах захисту, згідно визначання їхньої ефектив
ідентифікацію і визначення пріоритетності заходів для впорядкованості впровадження за детальний робочий план впровадження засобів захисту, враховуючи пріоритети, фінан
розподіл ресурсів, обов'язків і відповідальності; визначання процедур звітності про хід роботи; 9) компетентність у захисті і вимоги до навчання персоналу IT та кінцевих користувачів; 10) вимоги до умов експлуатації засобів захисту і процедур керування. Крім того, план повинен охоплювати заходи, що визначають умови і дії із затвердження кожного з вище перерахованих положень, включаючи і внесення змін до плану. 14 ВПРОВАДЖУВАННЯ ЗАСОБІВ ЗАХИСТУ Після затвердження проекту безпеки IT необхідно його впровадити. Як правило, за це відповідає системний контролер безпеки IT. У процесі застосування засобів захисту досягнення цілей повинно гарантувати, що: вартість засобів захисту повинна залишитись у прийнятих межах; засоби захисту використовують відповідно до вимог проекту безпеки IT; використання і керування засобами захисту повинно відповідати вимогам проекту безпеки IT. Більшість технічних засобів захисту потребують експлуатаційного й адміністративного регламентування, їх не можна використовувати як звичайні технічні засоби. Відповідні інструкції повинні бути підтримані і впроваджені керівництвом. Обізнаність в питаннях захисту (компетентність у захисті) і навчання також включають у заходи безпеки. Це важливе положення буде детально розглянуте в розділі 15. Оскільки весь персонал повинен бути обізнаним у захисті, потрібно провести навчання: персоналу, відповідального за впровадження системи IT; персоналу, відповідального за експлуатування системи IT; контролерів безпеки проекту і системи IT; персоналу, відповідального за керування безпекою, наприклад за контролювання доступу. зазначених у проекті безпеки системи IT. Після затвердження дозвіл передають у систему IT або послуги вводять в дію. Процес затвердження в деяких комітетах проводять як акредитацію. Будь-які істотні зміни в системі IT або послугах повинні викликати повторне перевіряння, повторні випробовування і затвердження системи IT або послуг. 15 КОМПЕТЕНТНІСТЬ У ЗАХИСТІ Програму обізнаності у захисті треба застосовувати до всіх рівнів організації, від вищого керівництва до користувачів. Без участі персоналу на рівні користувачів програма компетентності у захисті не може бути успішною. Користувачі повинні розуміти своє значення в успіху програми. Програма компетентності повинна враховувати корпоративні методики безпеки IT і забезпе- чувати однозначне розуміння рекомендацій із захисту і відповідних дій. Крім того, програма компетентності у захисті повинна охоплювати цілі проектів захисту системи. Програма повинна включати принаймні такі розділи: основні вимоги захисту інформації; залучення користувачів до аналізування інцидентів у безпеці, як і організації в цілому; перелік цілей, роз'яснення корпоративних методик захисту IT та стратегії керування ризи плани безпеки IT із застосування і перевіряння засобів захисту; класифікація інформації; обов'язки власників даних; обов'язки, опис задач і процедур; необхідність у звітності і розслідуванні порушень безпеки або спроб; наслідки некомпетентних дій (включно з дисциплінарними заходами); перевіряння сумісності захисту; керування змінами і настройкою. Для досягнення ефективності програми компетентності у захисті потрібно використовувати широкий спектр носіїв, наприклад брошури, довідники, плакати, відео, інформаційні листи, практичні вправи, семінари і лекції. Дуже важливо, щоб реалізація програми компетентності враховувала соціальні, культурні і психологічні аспекти значення захисту. Компетентність у захисті стосується кожного працівника організації і повинна впливати на поведінку та відповідальність усіх працівників. Головним чинником е розуміння адміністрацією потреби у захисті. Адміністративний апарат повинен гарантувати компетентність персоналу у захисті. Тому він повинен планувати відповідні статті в бюджеті. У великих організаціях відповідальність за компетентність у захисті IT треба покласти на корпоративного контролера безпеки IT. Метою програми компетентності є також потреба переконати всіх причетних осіб у важливості ризиків для системи IT і в можливих інформаційних втратах або несанкціонованій зміні чи розкритті, які можуть призвести до тяжких наслідків для організації та її службовців. Для покращення роботи необхідно організовувати навчання з врахуванням реальних умов роботи організації. Необхідно наводити релевантні приклади, які ґрунтуються на реальних випадках в організації, що покращує розуміння суті і розмірів уражень у випадках, ніж опис цього в засобах інформації. Такі навчання також дають змогу службовцям оптимально взаємодіяти з викладачем. Розуміння службовцями засобів захисту треба контролювати для визначення ефективності процесу підвищення компетентності у захисті і для оцінювання змісту цього процесу. Якщо результат не задовольняє, зміст процесу підвищення компетентності захисту потрібно відповідно коригувати. Навчання з підвищення компетентності у захисті треба періодично повторювати, щоб оновити знання діючого персоналу й інформувати новий. Крім того, кожний новий службовець чи особа, що здійснила переміщення по службі, або кандидат на посаду повинні бути ознайомлені зі своїми новими обов'язками. Бажано також інтегрувати питання захисту IT в інші курси. Варто також підкреслити, що компетентність у захисті це тривалий процес, який ніколи не є повністю завершеним. 16 МЕХАНІЗМ ДООПРАЦЮВАННЯ Всі засоби захисту потрібно використовувати так, щоб вони функціонували і продовжували функціонувати передбачуваним і відповідним способом. Цей аспект безпеки є одним з найважливіших, однак йому часто приділяють мало уваги. Частіше система або служба вже існують, тому захист впроваджують пізніше і потім залишають без нагляду. Існує навіть тенденція ігнорувати засоби захисту, які були застосовані, а підтримці або убезпечнюванню приділяти незначну увагу. Більше того, втрату ефективності засобів захисту потрібно спрогнозувати в планах, а не спостерігати вже як факт. Також необхідно перевіряти узгодженість захисту, контролювати робоче оточення, оглядати записи у журналі та обробляти інциденти для гарантії тривалості процесу убез-печнювання. 16.1 Обслуговування Обслуговування засобів захисту, що охоплює також і керування, є важливою частиною програми безпеки організації. Всі рівні керівництва відповідальні за обслуговування, щоб гарантувати: виділення необхідних ресурсів організації для обслуговування засобів захисту; періодичну переатестацію засобів захисту для гарантування виконання ними своїх функцій; модернізацію засобів захисту у разі появи нових вимог; чітко визначену відповідальність за обслуговування засобів захисту; незмінність визначеного рівня ефективності наявних засобів захисту під час модифікації запобігання новим загрозам або ураженням при модернізації технологій. Якщо здійснено описані вище заходи з обслуговування, то засоби захисту продовжуватимуть виконувати свою призначеність, що дає змогу уникати несприятливих і збиткових уражень. 16.2 Відповідність засобів захисту Перевіряння відповідності засобів захисту, тобто аудит чи ревізія захисту, є дуже важливим для гарантування відповідності й узгодженості з планом безпеки системи IT. Щоб гарантувати, що рівень безпеки IT залишається ефективним, важливо, щоб впроваджувані засоби захисту завжди відповідали проекту чи плану захисту системи IT. Це треба затверджувати на усіх етапах проходження проектів і систем IT: проектування і впровадження; життєвого циклу експлуатації; заміни або переміщення. Перевіряють відповідність захисту за допомогою зовнішнього або внутрішнього персоналу (наприклад, аудиту), і це повинно значною мірою ґрунтуватись на використовуванні контрольних списків, що стосуються проекту або методики захисту системи IT. Перевіряння відповідності захисту треба планувати і об'єднувати з іншими запланованими заходами. Вибіркові перевіряння особливо корисні для визначання, чи відповідає виконавчий персонал і користувачі певним засобам захисту і процесам. Перевіряти треба, щоб забезпечити коректність функціювання засобів захисту, правильність їхнього впровадження і використовування і, за потреби, провести випробовування. Там, де знайдено, що засоби захисту не відповідають безпеці, повинен бути створений і реалізований план коригувальних дій з подальшим аналізом результатів. 16.3 Контролювання Контролювання вирішальна частина циклу захисту IT. Якщо його проводять коректно, то це дає адміністрації чітке уявлення про те: що було досягнуто порівняно з поставленими цілями; чи переконливими є досягнення, і які специфічні ініціативи впроваджено. Всі зміни в активах, загрозах, вразливості засобів захисту потенційно можуть мати істотний вплив на ризики, і раннє виявлення змін дозволяє здійснити запобіжні заходи. Багато засобів захисту ведуть журнали з безпеки для фіксації важливих подій. Ці журнали треба, як мінімум, періодично переглядати, і, якщо можливо, аналізувати за допомогою статистичних методів для раннього прогнозування тенденцій до змін і прогнозування повторів несприятливих подій. Використовування журналів тільки для аналізування подій, що відбулися, веде до втрати потенційних можливостей засобів захисту. Контролювання повинне також охоплювати процедури для звітності контролеру безпеки IT і для керування на постійній основі. 16.4 Обробляння інцидентів Практично неможливо уникнути небажаних інцидентів у захисті. Кожний інцидент потрібно досліджувати настільки глибоко, наскільки вагомий збиток він спричинив. Регулювання інциденту дає змогу відповідно реагувати на випадкові або навмисні збої нормального режиму роботи системи IT. Отже, проект звітності і розслідування інцидентів повинні бути придатними для всієї організації і сервісних служб системи IT. Після цього потрібно об'єднати міжорганізаційні плани звітності для глибшого уявлення про місця виявлення інцидентів безпеки IT і пов'язаних з ними загроз, їх впливу на активи IT та ділову активність. Основними цілями розслідування інцидентів безпеки IT повинні бути: чи було компетентним і ефективним реагування на інцидент; робити висновки з інцидентів, щоб запобігти подібним несприятливим подіям. прийнятних умовах для припинення подальшого пошкодження і, якщо можливо, продовжувати ділову активність із запасними засобами. План реагування на інциденти повинен включати вимоги хронологічного документування всіх подій і заходів; це повинно допомогти ідентифікувати джерела інцидентів. Це є передумовою для досягнення іншої мети зменшення ризику в майбутньому через вдосконалення засобів захисту. Інший позитивний наслідок інцидентів збільшення готовності інвестувати в засоби захисту. Важливо також проаналізувати здійснення й документування інциденту, керуючись такими питаннями: що сталося і коли саме? чи діяв персонал згідно з планом? чи вчасно необхідна інформація була в розпорядженні персоналу? що персонал запропонував робити інакше наступного разу? Відповіді на ці питання допоможуть зрозуміти інцидент. Також це допоможе знизити ризик шляхом збільшення релевантності проектів і методик захисту IT (наприклад, вдосконалення засобів захисту, зменшення уразливості й адаптування програми компетентності в захисті). 17 ВИСНОВКИ У частині 2 обговорювалися обов'язки, процеси керування і колективної відповідальності за ефективність програми захисту. Обговорення призначене для ознайомлення керівного персоналу з основними процесами і функціями, які мають значення в керуванні захистом IT. Подана в цій частині інформація не може безпосередньо застосовуватися для всіх організацій. Зокрема, малі організації навряд чи будуть мати всі ресурси для повного виконання описаних функцій. У цих ситуаціях важливо, щоб основні концепції функції застосовували в організації відповідним способом. Навіть у деяких великих організаціях деякі з функцій, обговорених у цій частині, не можуть бути застосовані точно за описом. В частині 3 досліджується декілька технічних заходів, які можуть бути використані для виконування функцій, описаних у частині 2. Наступні частини розглядають питання вибору засобів захисту і певних засобів захисту для зовнішніх зв'язків. 35.040 Ключові слова: концепція, корпоративна методика, безпека IT, технологія захисту IT, керування, обмін інформацією, аналізування ризику, процедури. |
||||||||||||||
|
Категории документа:
|
||||||||||||||
Читайте также:
|
||||||||||||||
|
Copyright © 2009-2013 Bud Info. Все права защищены. Disclaimer
|
||||||||||||||
