1.2.2. Рекомендаціі Інституту програмного інжинірингу університету Карнегі Мелона
Документ Інституту програмного інжинірингу університету Карнегі Мелона містить рекомендації щодо формування та експлуатації інцидент комп'ютерної безпеки групи реагування (CSIRT). Зокрема, вона допомагає організації визначити документальний характер і масштаби інциденту комп'ютерної безпеки обробки обслуговування, яка є ядром служби CSIRT. Документ пояснює, функції, що входять до складу служби; як ці функції взаємопов'язані, і інструменти, процедури і функції, які необхідні для реалізації послуг. У цьому документі також описується, як CSIRT взаємодіяти з іншими організаціями і, як поводитися з конфіденційною інформацією. Крім того, розглядаються експлуатаційні та технічні питання, наприклад, обладнання, безпека і кадрові міркування.
Цей документ [60] покликаний забезпечити команду цінними ресурсами щодо формування команд та існуючих команд, послуг, політик і процедур, які чітко не визначені та не документовані. Основна аудиторія для даного документа є менеджери, які несуть відповідальність за створення та діяльність CSIRT чи служби управління інцидентами. Він також може бути використаний як еталон для всього персоналу CSIRT, менеджерів більш високих рівнів, та інших, які взаємодіють з CSIRT.
Цей документ [60] являє собою керівництво з загальних питань, які необхідно враховувати при формуванні та експлуатації CSIRT.
Зокрема, цей документ допомагає організації визначити документальний характер і масштаби інциденту комп'ютерного сервісу щодо обробки безпеки. З цією метою розглядаються функції, що входять до складу служби; та, як ці функції взаємопов'язані, і інструменти, процедури, функції, необхідні для реалізації послуг. В рекомендаціях [60] також зосереджена увага на інцидент аналізу. Так само, як пожежники можуть розслідувати пожежу, зрозуміти, як це сталося (наприклад, від стихійного лиха, підпалу або електричної несправності дизайну), так і CSIRT намагається зрозуміти, як стався інцидент. Хоча аналіз пожежні буде включати просіювання через попіл, то CSIRT буде включати в себе, дивлячись на системні журнали і будь-які файли, залишені зловмисником.
Команда повинна взаємодіяти з іншими екстреними службами, щоб адекватно реагувати і надавати правоохоронним органам інформацію, як воно цього законно вимагає. У цьому документі обговорюється, як CSIRTs взаємодіє з іншими організаціями, такими як сайти, правоохоронні органи і засоби масової інформації. CSIRT повинна обробляти інформацію відповідним чином. Отже, обробка інформації є важливим предметом обговорення в даному керівництві [60].
1.3. Аналіз сучасних підходів до створення команд реагування на інциденти іб
Сучасний підхід до організації системи ЗВУНІБ, який знайшов відображення у багатьох міжнародних рекомендаціях, полягає у тому, що створюється єдина методика і єдина система обробки як інцидентів з інформаційною безпекою, так й інших інцидентів – з фізичною, пожежною, фінансовою безпекою, безпекою електроживлення, постачання запчастинами тощо [23].
Щодо створення команди реагування на інциденти ІБ, слід зазначити, що на початковому етапі необхідно розрахувати фінансову модель.
У досконалому світі фінансування було б адаптоване під потреби клієнтів, але в реальності набір послуг, повинен бути адаптований під певний бюджет. Тому більш реалістично почати планування з фінансових питань.
Розглядаючи модель затрат, необхідно зазначити, що двома основними факторами, що впливають на витрати, є встановлення робочих годин і кількість (а також якість) найманого персоналу. Чи є потреба в 24х7 наданні сервісу реагування на інциденти та технічної підтримки? Або ці сервіси надаватимуться протягом робочого часу?
Залежно від бажаної доступності послуги, а також від необхідного обладнання (Наприклад, чи можливо працювати з дому?), Може бути вигідним працювати з графіком «За викликом» або ж з погодинним графіком.
Можливим сценарієм є надання профілактичних послуг і послуг реагування під час робочого часу. Поза робочим часом будуть надаватися тільки обмежені послуги, наприклад, надання послуг персоналом з графіком роботи «по викликом »у разі настання серйозних аварій та інцидентів.
Інша альтернатива – знайти міжнародне співробітництво з іншими CSIRT групами, яке забезпечує хороший спосіб обміну ресурсами один з одним. Наприклад, Група Реагування на Інциденти Комп'ютерної Безпеки компанії Sun Microsystems, яка має численні підрозділи в різних часових зонах по всьому світу, надає сервіс 24х7 позмінним чергуванням команд з усього світу (але все підрозділи в різних часових зонах є членами однієї групи CSIRT).
Після визначення витрат наступний крок – подумати про можливі моделі доходів – як заплановані сервіси будуть фінансуватися. Ось деякі можливі сценарії [40]:
використання існуючих ресурсів – завжди вигідно оцінювати існуючі ресурси в інших підрозділах компанії. Чи є серед найнятого персоналу відповідний для CSIRT з потрібним досвідом і кваліфікацією (наприклад, у відділі ІТ)? Можна спільно з керівництвом знайти варіант їх залучення за сумісництвом в CSIRT на початковій стадії. Або, як варіант, надання ними підтримки CSIRT на спеціальних умовах.
членські внески – надавати послуги клієнтам за щорічні / щоквартальні членські внески. Додаткові сервіси можуть оплачуватися на основі «у разі використання », наприклад, консультаційні послуги або аналіз системи безпеки. Інший ймовірний сценарій – послуги (внутрішнім) клієнтам надаються безкоштовно, але послуги, що надаються зовнішнім замовникам, можуть бути платними. А також, як варіантом, може бути ідея – публікувати рекомендації та інформаційні бюлетені на громадських веб-сайтах і мати розділ «Тільки для членів мережі» з більш детальною спеціалізованою інформацією.
субсидія – подання заявку на субсидування проекту за рахунок коштів уряду або урядової організації, тому що в даний час більшість країн має в наявності фонди на проекти в області IT безпеки. Хорошим початком могло б бути – зв'язатися з Міністерством Внутрішніх Справ [40].
Щодо комбінації різних моделей, то це є ,звичайно, можливо.
Типова команда реагування на інциденти комп'ютерної безпеки виділяє наступні ролі всередині групи:
керівництво:
головний менеджер;
персонал:
офіс-менеджер;
бухгалтер;
консультант з комунікацій;
юридичний консультант;
оперативна технічна група:
керівник технічної групи;
техніки CSIRT, які надають CSIRT-сервіси;
дослідники;
зовнішні консультанти:
наймаються, коли потрібні.
Надзвичайно корисно мати в штаті юридичної фахівця, особливо під час початкової фази CSIRT. Це збільшить витрати, але в кінцевому підсумку ви заощадите час і уникнете правових проблем.
В залежності від рівня та різноманіття кваліфікації всередині групи клієнтів, а також коли CSIRT має хороший медіа-профіль, буде дуже корисним мати в групі експерта з комунікацій. Такий експерт може зосередитися на перекладі складних технічних питань у більш зрозумілі повідомлення для клієнтів або медіа-партнерів. Експерт з комунікацій також буде забезпечувати зворотний зв'язок від клієнтів до технічним експертам, так він може служити «перекладачем» і «посередником» між цими двома групами.
Одними з самих поширених організаційних моделей, використовуваних діючими CSIRT є:
незалежна бізнес модель;
вбудована модель;
модель капсула;
добровільна модель [40].
Незалежна бізнес модель. CSIRT створюється і діє як незалежна організація зі своїм менеджментом і працівниками.
Рис. 1.3. Незалежна бізнес модель
Вбудована модель. Ця модель може бути використана, якщо CSIRT заснована в рамках існуючої організації, використовуючи існуючий IT відділ, наприклад, CSIRT очолює лідер групи, який відповідає за діяльність CSIRT. Лідер групи збирає необхідних техніків на час усунення інцидентів або для роботи над завданнями CSIRT. Він може попросити допомоги в межах існуючої організації.
Ця модель може бути також адаптована під конкретні ситуації по мірі їх виникнення. У цьому випадку команда має певну кількість еквівалентів повної зайнятості. Служба скарг Інтернет Сервіс Провайдера, наприклад, виразною є робота з повною зайнятістю на один або (у більшості випадків) більше, ніж один еквівалент зайнятості [40].
Рис. 1.4. Вбудована організаційна модель
Модель кампусу. Модель кампусу, як підказує ім'я, головним чином використовується освітніми і дослідницькими CSIRT. Більшість академічних та дослідницьких організацій складаються з різних університетів і кампусних інфраструктур у різних місцях, розподілених по регіону чи навіть всієї країні (як у випадку NREN, Національних Дослідних Мереж). Зазвичай ці організації незалежні одна від одної і мають свою власну CSIRT. Ці CSIRT – групи зазвичай організовані під парасолькою «материнської», або центральної CSIRT. Центральна CSIRT займається координуванням і є єдиним контактом для зовнішнього світу. В більшості випадків центральна CSIRT теж надає основні CSIRT-сервіси, а також поширює інформацію про інциденти CSIRT відповідного кампусу.
Деякі CSIRT поширюють свої основні CSIRT-сервіси іншим кампусним CSIRT, що в результаті призводить до зменшення перевантаження центрального сервісу [40].
Рис. 1.5. Модель кампусу
Добровільна модель. Ця організаційна модель описує групу людей (фахівців), які об'єднуються для обміну радами і надання підтримки один одному (і третім особам) на добровільній основі. Це вільне суспільство, сильно залежне від мотивації учасників
Після того як буде вирішено, які сервіси і який рівень підтримки надавати, а також буде вибрано організаційну модель, наступний крок – пошук потрібної кількості кваліфікованого персоналу.
Щодо використання обладнання в офісі, слід зазначити, що воно повинно забезпечувати безпеку, як інформації, яка циркулює в офісі, так і її персоналу. Так як CSIRT зазвичай працює з дуже важливою інформацією, то було б добре підготувати команду, яка турбувалася б про фізичну безпеки офісу. Це дуже сильно залежить від існуючих умов та інфраструктури, а також від існуючої політики інформаційної безпеки компанії-власника [40].
Політика інформаційної безпеки буде залежати від типу CSIRT. Крім опису бажаних операційних та адміністративних процесів і процедур, політика має відповідати законодавству і стандартам, особливо щодо відповідальності SCIRT. Зазвичай CSIRT обмежена національними законами і нормами, які часто виконані у відповідності з Європейським законодавством та міжнародними угодами. Стандарти не обов'язково застосовуються безпосередньо, вони можуть бути рекомендовані законами або інструкціями.
Нижче слідує список можливих законів і методик:
Національні:
різні закони про інформаційні технології, телекомунікації, медіа;
закони про захист даних і конфіденційність;
закони і норми про збереження даних;
законодавство про фінанси, бухгалтерський облік та корпоративний менеджмент;
кодекси поведінки для корпоративного управління та IT управління;
Європейські:
директиви про електронний підпис (1993/93/EC);
директиви про захист даних (1995/46/EC) та конфіденційність в електронних комунікаціях (2002/58/EC);
директиви про телекомунікаційні мережі та сервіси (2002/19/EC - 2002/22/EC);
директиви про Корпоративне Законодавство (наприклад, 8-а Директива про корпоративне законодавство);
Міжнародні:
Базельська Угода II (особливо щодо управління операційними ризиками);
Конвенція Ради Європи з кіберзлочинності;
Конвенція Ради Європи з прав людини (стаття 8 про конфіденційність);
Міжнародні стандарти фінансової звітності (МСФО, вони в якійсь мірі відносяться до контролю над IT);
Стандарти:
Британський стандарт BS 7799 (Інформаційна безпека);
Міжнародні стандарти ISO2700x (Системи управління інформаційної безпекою);
Німецький IT-Grundschutzbuch, Французький EBIOS та інші національні варіації.
Щоб визначити, чи діє CSIRT відповідно до національного та міжнародного законодавства, краще всього необхідно скористатися юридичною консультацією [40].
Оперативне визначення вражених місць, технологій та мети атаки, об`єм втраченої (чи вкраденої) інформації стає життєво необхідним як для недопущення повторних інцидентів, так і для визначення адміністративної та менеджерської стратегії відносно результатів атаки. І тому, найголовніша задача команд реагування, яка працює над кожним конкретним інцидентом – мінімізація негативних наслідків, фінансових та публічних, та забезпечення стратегій, які дозволять довіряти своїй інформаційній інфраструктурі та політиці безпеки надалі.
Висновки до розділу 1
У даному розділі було проаналізовано міжнародні стандарти щодо управління інцидентами ІБ, такі як: ГОСТ Р ІСО/МЕКТО 18044-2004, МСЕ-Т Е.409, галузевий стандарт України СУІБ 2.0/ISO/IEC 27002:2010 та рекомендовані практики: NIST SP 800-61 Computer security incident handling guide, рекомендаціі Інституту програмного інжинірингу університету Карнегі Мелона. Провівши аналіз джерел, було розглянуто основні терміни та визначення щодо інцидентів ІБ, методи та основні підходи до організації виявлення, реагування та запобігання їх появи, а також описані основні процедури, які повинна виконувати група реагування на інциденти ІБ при виявлені інцидентів, які впливають на функціонування роботи ІКС.
Було проаналізовано сучасні підходи до створення команд реагування на інциденти ІБ.