Законодавча база Російської Федерації. Управління інцидентами та проблемами

У словнику ITSM є два поняття, які дуже часто створюють плутанину у ІТ-фахівців та користувачів: інцидент (Incident) та проблема (Problem). Обидва вони пов'язані з процесом вирішення збою, що виник, і реєструються за допомогою створення тикета в системі Сервіс-Деска. Однак за своєю суттю вони досить сильно відрізняються один від одного та мають різні способи вирішення. Розглянемо приклад, який пояснює різницю між цими поняттями.

Зламався чайник!

Ранок. На сніданок ви вирішив заварити собі чашечку міцного чаю, щоб підбадьоритися перед робочим днем. Наливаєте воду в чайник, вмикаєте його в розетку, клацаєте вимикачем, а він не вмикається. Клацаєте вимикачем знову і знову, перевіряєте, чи є електрика в будинку, вмикаєте чайник в іншу розетку, але він все одно не працює. Виник ІНЦИДЕНТ!

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

Тепер щоранку ви будете використовувати один із перерахованих способів для нагріву води, поки не знайдете час звернутися до майстерні, щоб електрик розібрався з ПРОБЛЕМОЮ, через яку чайник не працює. Проблема – причина поломки чайника. Електрик виявить, що перегорів запобіжник через стрибок напруги, замінить запобіжник, і ви знову зможете кип'ятити воду у чайнику – проблема вирішена.

Який стосунок чайник має до ІТ?

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

Це просто, але дуже ефективно!

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

Час випити смачного чаю та перевірити запобіжники в інших домашніх приладах!

розмір шрифту

НАЦІОНАЛЬНИЙ СТАНДАРТ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ- ІНФОРМАЦІЙНА ТЕХНОЛОГІЯ- МЕТОДИ І ЗАСОБИ ЗАБЕЗПЕЧЕННЯ БЕЗПЕКИ-МЕНЕДЖМЕНТ... Актуально у 2018 році

6 Приклади інцидентів інформаційної безпеки та їх причин

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

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

6.1 Відмова в обслуговуванні

Відмова в обслуговуванні є великою категорією інцидентів ІБ, що мають одну спільну рису.

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

Існує два основних типи інцидентів ІБ, пов'язаних із відмовою в обслуговуванні, створюваних технічними засобами: знищення ресурсів та виснаження ресурсів.

Деякі типові приклади таких навмисних технічних інцидентів ІБ "відмова в обслуговуванні" є:

Зондування мережевих широкомовних адрес з метою повного заповнення смуги пропускання мережі трафіком повідомлень у відповідь;

Передача даних у непередбаченому форматі в систему, сервіс чи мережу у спробі зруйнувати чи порушити їхню нормальну роботу;

Одночасне відкриття кількох сеансів із конкретною системою, сервісом чи мережею у спробі вичерпати їхні ресурси (тобто уповільнення їхньої роботи, блокування чи руйнування).

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

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

Інциденти ІБ "відмова в обслуговуванні", створювані нетехнічними засобами і що призводять до втрати інформації, сервісу та (або) пристроїв обробки інформації, можуть викликатися, наприклад, такими факторами:

Порушеннями систем фізичного захисту, що призводять до розкрадання, навмисного завдання шкоди або руйнування обладнання;

Випадковим завданням шкоди апаратурі та (або) її місцезнаходження від вогню або води/повені;

Екстремальними умовами навколишнього середовища, наприклад, високою температурою (внаслідок виходу з ладу системи кондиціювання повітря);

Неправильне функціонування або перевантаження системи;

Неконтрольованими змінами у системі;

Неправильне функціонування програмного або апаратного забезпечення.

6.2 Збір інформації

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

Наявності мети, отримання уявлення про навколишню мережеву топологію і про те, з ким зазвичай ця мета пов'язана обміном інформації;

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

Типовими прикладами атак, спрямованих на збирання інформації технічними засобами, є:

скидання записів DNS (системи доменних імен) для цільового домену Інтернету (передача зони DNS);

Надсилання тестових запитів за випадковими мережевими адресами з метою знайти працюючі системи;

Зондування системи з метою ідентифікації (наприклад, контрольної суми файлів) операційної системи хоста;

Сканування доступних мережевих портів на протокол передачі файлів системі з метою ідентифікації відповідних сервісів (наприклад, електронна пошта, протокол FTP, мережа тощо) та версій програмного забезпечення цих сервісів;

Сканування одного або кількох сервісів з відомими вразливістю діапазону мережевих адрес (горизонтальне сканування).

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

Інциденти, спрямовані на збирання інформації, створювані нетехнічними засобами, призводять до:

Прямого чи непрямого розкриття чи модифікації інформації;

Розкрадання інтелектуальної власності, що зберігається в електронній формі;

Порушення обліковості, наприклад, під час реєстрації облікових записів;

Неправильне використання інформаційних систем (наприклад, з порушенням закону чи політики організації).

Інциденти можуть викликатися, наприклад, такими факторами:

Порушення фізичного захисту безпеки, що призводять до несанкціонованого доступу до інформації та розкрадання пристроїв зберігання даних, що містять значущі дані, наприклад, ключі шифрування;

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

6.3 Несанкціонований доступ

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

Спроби вийняти файли з паролями;

Атаки переповнення буфера для одержання привілейованого (наприклад, на рівні системного адміністратора) доступу до мережі;

використання вразливостей протоколу для перехоплення з'єднання або хибного спрямування легітимних мережевих з'єднань;

Спроби розширити привілеї доступу до ресурсів або інформації в порівнянні з легітимно наявними у користувача або адміністратора.

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

Руйнуванням пристроїв фізичного захисту з подальшим несанкціонованим доступом до інформації;

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

Приклади авіаційних подій та інцидентів.

Сталося кілька інцидентів високого рівня та авіаційних подій через людські чинники. Сайт інтернету за Людськими факторами при авіаційному обслуговуванні та інспекціях (HFAMI) містить 24 доповіді NTSB про інциденти, причинами яких стали людські фактори. У Великій Британії сталося кілька подій та інцидентів. Подробиці про них можна знайти на сайті AAIB. Деякі з цих інцидентів наведені нижче:

• Інцидент з Боїнгом-737, (Алоха рейс 243), Мауї, Гаваї, Квітень 1988;
• Інцидент з ВАС 1-11, G-BJRT (British Airways рейс 5390), Дідкот, Оксфордшир, 10 червня 1990 року.
• Інцидент з А-320, G-KMAM у Лондонському аеропорту Гатвік 26 серпня 1993 року;
• Інцидент з Боїнгом-737, G-OBMM біля Девінтрі 23 лютого 1995 року.

Інцидент, що стався з рейсом Алоха № 243 у квітні 1988, пов'язаний з тим, що 18 футів верхньої обшивки кабіни під час польоту були зірвані. Літак перед польотом перевірявся згідно з вимогами США двома авіаційними інспекторами. Один інспектор мав стаж роботи 22 роки, а другий, старший із них 33 роки. Жоден не виявив тріщин під час інспекції. Аналізи, проведені після інциденту, виявили наявність понад 240 тріщин у обшивці цього літака на час інспекції. Ті, хто випливає з цього, визначили багато проблем пов'язаних з людськими факторами, що ведуть до неналежних інспекцій.

В результаті інциденту з рейсом Алоха, у США було розроблено програму дослідження проблем пов'язаних з людськими факторами з акцентуванням на проведення інспекцій.

10 червня 1990р. у Великій Британії літак ВАС 1-11 (British Airways рейс 5390) вилетів з аеропорту Бірмінгема. Після набору висоти 17300 футів у кабіні пілотів було видавлено тиском назовні ліве лобове скло. Це скло було замінено перед польотом. Виявилося, що з 90 болтів, що кріплять, 84 виявилися меншого діаметру, ніж необхідно. Командир корабля наполовину витягнув з кабіни через отвір вікна і його утримували члени екіпажу, поки другий пілот не здійснив благополучну посадку в аеропорту Саутгемптона.

Начальник зміни (SMM) через недокомплект людей під час нічної зміни вирішив провести заміну лобового скла самостійно. Він переглянув Інструкцію (ММ) та дійшов висновку, що це проста робота. Він вирішив замінити кріпильні болти і взявши один як зразок (7D)

став підбирати інші заміни. Комірник сказав йому, що для заміни потрібні болти (8D), однак через їх брак на складі, начальник зміни вирішив, що підійдуть болти (7D). (Оскільки вони стояли дома раніше). Тим не менш, він візуально порівняв болти і помацав їх і помилково вибрав болти 8С, які довші і тонші. Також він не помітив, що при установці заглиблення для головки болта (потай) глибше, ніж необхідно. Він сам виконав роботу та підписав сертифікат випуску. Процедура не вимагала проведення поглибленої чи вторинної перевірки. До цього інциденту мають відношення кілька людських факторів, що включають неправильне визначення розмірів болтів начальником зміни, погане освітлення на складі, не використання окулярів, практика проведення робіт та можливі фактори конструкції та організації роботи.

Літак А-320 у Великій Британії у серпні 1993р. Під час першого польоту після заміни закрилка відбулося різке звалювання праворуч відразу після зльоту. Літак повернувся до Гатвика і благополучно приземлився. Розслідування показало, що під час обслуговування, щоб замінити правий закрилок, спойлери були переведені в режим обслуговування і зрушені при незавершеній процедурі; відповідно відбортування та прапорці не були встановлені. Призначення відбортувань та спойлерів інженерами недостатньо розумілося.

Це нерозуміння частково було викликано знайомство та звичка до літака іншого

типу (Боїнг 757) і виявилося у недостатньому позначенні стану спойлерів під час передачі змін. Замкнений спойлер не було виявлено під час проведення пілотом стандартних перевірок.

У лютому 1995р. на літаку Боїнг 757-400 виявилася втрата тиску олії на обох двигунах. Літак розвернувся та благополучно приземлився в аеропорту Лутона. Розслідування показало, що попередньої ночі на літаку проводилося бороскопічне дослідження обох двигунів та кожухи приводів роторів високого тиску, після виконання робіт не було встановлено. Внаслідок цього під час польоту було втрачено майже всю олію з обох двигунів. Інженер з лінійного обслуговування спочатку мав виконати цю роботу, але з різних причин він передав роботу контролеру базового обслуговування. Контролер у відсутності необхідних документів по роботам. Контролер і слюсар виконали роботу, незважаючи на численні перерви, але не встановили кожухи роторів. На землі не було проведено випробування двигунів на неодружених оборотах для виявлення течій олії. Роботу було розписано як виконану.

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

• була відсутня достатня кількість персоналу;
• був тиск у часі;
• Усі помилки сталися вночі;
• Проводилася передача змін;
• Усі задіяні особи виконували довгі ручні роботи;
• Був елемент відносини «Можу значить роблю»;
• Були перерви у роботі;
• Не вдалося використати підтверджену інформацію чи процедури;
• Інструкції були суперечливі;
• Було зроблено недостатнє попереднє планування, обладнання та запчастин.

Інциденти та аварії – Порушення людських факторів.

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

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

Рис 3. Ланцюг помилок.

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

Управління інцидентами

Основна мета процесу управління інцидентами (incident management) - відновлення нормальної працездатності системи у максимально короткі терміни та мінімізація негативного впливу на бізнес, який користується службами, працездатність яких виявилася порушеною. Під "нормальним функціонуванням служб" розуміється функціонування, що відповідає зафіксованому в угоді про рівень обслуговування (service level agreement, SLA).

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

Будь-якому процесу управління інцидентами можна дати формальний короткий опис шляхом перерахування набору показників.

Вхідними даними для опису інцидентів є:

• детальний опис інциденту, отриманий від Service Desk, служб забезпечення оперативного функціонування мереж чи серверів тощо;
• опис конфігурацій та елементів, можливо пов'язаних з інцидентом. Описи беруться з CMDB, бази даних одиниць конфігурації, до яких належать всі елементи ІТ-інфраструктури (обладнання, програмне забезпечення, документація, послуги, що надаються тощо);
• інформація (за її наявності) з бази проблем та бази відомих помилок;
• опис способу вирішення.

Результат процесу управління інцидентами може бути таким:

• запит на тимчасове внесення змін для усунення інциденту, оновлений реєстраційний запис інциденту, що включає спосіб вирішення та/або обходу;
• дозволений (усунений) та закритий інцидент;
• повідомлення для клієнта;
• управлінська інформація (звіт).

Можливі заходи щодо управління інцидентами:

• визначення та реєстрація інциденту;
• класифікація інциденту та початкова допомога;
• дослідження та діагностика;
• дозвіл інциденту та відновлення системи;
• закриття інциденту;
• власність, моніторинг, відстеження та взаємодія.

Ролі та функції управління інцидентами:

• групи підтримки першої, другої та третьої ліній, а також групи фахівців та зовнішні партнери (ролі); менеджер управління інцидентами (роль); менеджер Service Desk (функція).

Можливі метрики:

• загальна кількість інцидентів;
• середній час усунення або обходу інциденту з різних типів інцидентів;
• відсоток інцидентів, усунених за час, що не перевищує обумовленого SLA;
• середня вартість усунення інциденту;
• процент інцидентів, закритих без залучення інших фахівців;
• число та відсоток інцидентів, усунених віддалено (без візиту до користувача).

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

Передача інциденту від Service Desk на другу лінію підтримки (функціональна ескалація) потрібна у разі неможливості усунути інцидент на першій лінії. Автоматизована функціональна ескалація можлива, але має бути ретельно спланована відповідно до SLA.

Ієрархічна ескалація виявляється необхідною за неможливості усунення інциденту або за виділений час, або з необхідною якістю. Як правило, вона здійснюється персоналом служби Service Desk відповідно до їх досвіду та вручну. Автоматизована ієрархічна ескалація також використовується і може будуватися на основі обліку часових інтервалів. Доцільно щоб вона здійснювалася до часу, встановленого SLA; при цьому відповідний керівник отримає можливість вжити додаткових дій.

Ефект від запровадження процесу управління інцидентами

Перерахуємо найбільш важливі корисні якості, які здобуваються в результаті впровадження процесу управління інцидентами. Для бізнесу загалом це:

• зниження негативного впливу на бізнес з боку інцидентів, що досягається підвищенням ефективності та скорочення часу при їх усуненні;
• проактивне (запобіжне) визначення необхідності розширення та корекції важливих для бізнесу систем;
• доступність необхідної бізнесу управлінської інформації, співвіднесеної з умовами SLA.

Ряд корисних якостей набуває і робота ІТ-підрозділу:

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

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

Управління проблемами

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

Процес управління проблемами має як реактивний, і проактивний характер. Перший варіант стосується вирішення проблем, пов'язаних з інцидентами, другий спрямований на виявлення та усунення проблем, здатних привести, але поки що не призвели до виникнення інцидентів.

Контроль проблем та помилок разом із проактивним управлінням проблемами становлять сферу відповідальності процесу управління проблемами. Мовою формальних визначень, «проблема» - це невідома основна причина виникнення одного чи кількох інцидентів, а «відома помилка» - успішно діагностована проблема, на яку знайдено обхідний шлях чи спосіб усунення.

Як і процесу управління інцидентами, наведемо групи основних характеристик процесу управління проблемами. Хоча деякі з них і збігаються, вказати їх все має сенс, оскільки йдеться про різні процеси.

Вхідними даними для опису є:

• деталі інциденту, запозичені із управління інцидентами;
• детальний опис конфігурацій із CMDB;
• всі відомі обхідні шляхи (з управління інцидентами).

Можливі заходи:

• контроль проблем та помилок;
• проактивне запобігання проблемам;
• ідентифікація трендів;
• аналіз накопичуваної інформації та підготовка звітів;
• підготовка управлінської інформації.

Результати можуть бути такими:

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

Ролі та функції: співробітники, відповідальні за обробку проблем (ролі); менеджер управління проблемами (роль).

Можливі метрики:

• кількість ініційованих запитів на внесення змін, а також вплив цих запитів на надійність та доступність охоплених ними служб;
• час, витрачений на роботи з дослідження та діагностики на кожен підрозділ, з урахуванням розподілу на типи проблем;
• число і вплив інцидентів до виявлення причини проблеми або до реєстрації відомої помилки;
• відношення обсягу зусиль з негайної допомоги та підтримки до планового;
• число проблем і помилок, згрупованих за різними ознаками (статус, служби, вплив, категорії, групи користувачів);
• середній та максимальний час, що витрачається на закриття проблеми або узгодження відомої помилки, що розраховується з моменту реєстрації проблеми, згрупований за кодами впливу та групами підтримки;
• очікуваний час усунення відкритих проблем;
• загальний витрачений час на всі закриті проблеми.

Ефект від запровадження процесу управління проблемами

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

• Якість служб.Управління проблемами допомагає підтримувати безперервний цикл постійного підвищення якості ІТ-служб.
• Скорочення інцидентів.Процес управління проблемами є інструментом для скорочення числа інцидентів, що негативно впливають на бізнес організації.
• Безперервне рішення.В результаті роботи процесу скорочується число та вплив на бізнес уже вирішених проблем та відомих помилок.
• Вдосконалене навчання.Процес ґрунтується на концепції використання накопичених знань з минулого та надає можливості для аналізу трендів та запобігання збоям, або зниження їх значущості та впливу на основний бізнес.
• Збільшення числа інцидентів, які дозволяються при першому зверненні.Це досягається шляхом надання в розпорядження Service Desk рекомендацій щодо шляхів запобігання та обходу виникаючих інцидентів.

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

Реалізація та впровадження

Ми вже звертали увагу на основну відмінність аналізованих процесів, враховану у формуванні ключових метрик якості. Завданням управління інцидентами є усунення інцидентів у максимально короткі терміни. Управління ж проблемами має виключити можливість повторного виникнення інциденту з тієї ж самої (іноді - і з аналогічних) причин.

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

Допустимо (і рекомендується) суміщення функцій Service Desk та функцій керування інцидентами. Однак важливо пам'ятати, що це різні процеси: первинне спілкування з користувачами не входить до функцій процесу управління інцидентами. До того ж, користувач може звернутися в службу підтримки не тільки у зв'язку з інцидентом, що виник, але й з іншої причини (потреба в інформації, необхідність поповнення витратних матеріалів і т.д.). З іншого боку, при деяких способах реалізації (наприклад, у разі побудови служби підтримки на основі Web-технологій, коли користувач самостійно вносить усі необхідні дані у форми), необхідність виділеної служби Service Desk під питанням. Водночас у жодному разі не можна відмовлятися від управління інцидентами - звідки б не надійшло повідомлення про їхнє виникнення, хтось обов'язково повинен відповідати за їхнє усунення.

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

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

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

Виробники інструментарію намагаються враховувати згадані рекомендації. Наприклад, HP OpenView Service Desk 3.0 має модульну структуру. У вигляді окремого модуля реалізовано можливості реєстрації та управління звернень користувачів, інцидентів та проблем, що цілком відповідає згаданим рекомендаціям: інтеграція у цьому випадку є максимально повною. Користувачі системи, побудованої на основі цього продукту, мають можливість будувати зв'язки між реєстраційними записами всіх перерахованих типів, здійснювати пошук за контекстом та з урахуванням цих зв'язків, визначати відомі способи вирішення несправностей, що виявляються. Поділ цих функцій може знизити ефективність роботи інструментального засобу, а як наслідок - якість реалізації процесів. У той самий час, основу будь-якого рішення з управління ІТ-інфраструктурою лежить облік наявного устаткування, додатків, документації тощо. - всього того, що й складає цю інфраструктуру. Ці можливості також доступні в рамках HP Service Desk 3.0. Крім того, у вигляді окремих модулів реалізовані можливості, призначені для автоматизації управління змінами та управління угодами SLA. Інтеграція всіх перерахованих модулів реалізується в максимально повному обсязі, надаючи можливість використовувати продукт, що розглядається, як основа для побудови комплексної системи управління ІТ.

Продукт компанії Remedy будується дещо складніше, основою його є Remedy Action Request System, що встановлюється на сервері. До системи як прикладна частина можуть додатково купуватися функціональні модулі: Help Desk, Asset Management, Change Management і Service Level Agreement. Кожен із модулів може використовуватися як самостійно (без інших прикладних модулів), так і у складі комплексного рішення. Питання автоматизації процесів керування проблемами та інцидентами, як і у разі вирішення від HP, реалізуються у модулі Remedy Help Desk. При цьому є деякі відмінності і реалізуються окремі підходи до розуміння даних процесів, але основні побажання і вимоги ITIL повністю враховані.

Для успішного впровадження процесів управління інцидентами та проблемами

необхідно виконання, як мінімум, таких умов.

• Наявність актуальної та своєчасно оновлюваної бази CMDB. Якщо ця база недоступна, інформація про одиниці конфігурації, що мають відношення до інциденту, буде видобуватися вручну, що істотно збільшить час обробки інциденту і підвищить її складність.
• Доступність оновлюваної бази знань з помилок/проблем та способів їх вирішення, а також обходу. Наявність такої бази дозволяє швидко вирішувати багато проблем. Бажано мати можливість підключення до неї аналогічних баз, розроблених іншими організаціями та компаніями. Питання сумісності, що виникають при цьому, можуть призвести до великих складнощів, тому рекомендується використовувати рішення з відкритою архітектурою, що містять засоби для імпорту та експорту даних. Останнім часом все частіше як стандартний спосіб доступу до інформації використовується Web-інтерфейс, який є зручним і зрозумілим, а також широко поширеним.
• З точки зору потенційно конфліктної ситуації між управлінням проблемами та управлінням інцидентами (через їх різні цілі), необхідно організувати спільну роботу та співпрацю виконавців обох процесів. При цьому не можна забувати про те, що з тих же міркувань та сама людина не може виконувати й ті й інші обов'язки одночасно: йому буде дуже важко знайти баланс інтересів.
• Організація ефективної автоматизованої системи реєстрації інцидентів з можливостями детальної та якісної класифікації, що є надзвичайно важливим елементом для організації функціонування як служби Service Desk, так і процесів, що розглядаються в чистому вигляді. Використання цих цілей паперових технологій не рекомендується.

Дуже зручно, якщо інструментальні засоби, що використовуються для реалізації аналізованих процесів, мають такі додаткові можливості:

• автоматичною реєстрацією інцидентів, що відбуваються в найважливіших пристроях (сервери, мережеве обладнання тощо), для чого може знадобитися створення додаткових інтерфейсів;
• автоматичною ескалацією інцидентів у разі порушення тимчасових графіків;
• гнучкою маршрутизацією інцидентів, оскільки персонал служб підтримки може бути розміщений у різних приміщеннях та будинках;
• автоматичним пошуком необхідних даних у базі CMDB;
• спеціальними рішеннями для полегшення класифікації інцидентів;
• інтеграцією із телефонними системами;
• наявністю різноманітних діагностичних модулів.

Проілюструємо перелічені можливості з прикладу вже згадуваного Service Desk 3.0. Будучи представником сімейства продуктів HP OpenView, Service Desk містить можливості отримання повідомлень від інших продуктів даного сімейства, у тому числі від Network Node Manager, засоби моніторингу та керування мережевими пристроями, та VantagePoint Operations, засоби моніторингу та керування серверами та додатками. Дані продукти можуть в автоматичному режимі, на підставі інформації про контрольовані об'єкти, що збирається, генерувати запити для Service Desk, які автоматично передаються і аналізуються операторами служби підтримки або обробляються в автоматичному режимі. При відповідному налаштуванні джерелами аналогічних повідомлень можуть стати інші діагностичні засоби. Продукт передбачає можливості автоматичного інформування шляхом надсилання повідомлень керівників відповідних рівнів у разі порушення термінів усунення інциденту. У ньому реалізовано розширені можливості пошуку необхідної інформації серед уже врахованих проблем, інцидентів та інших даних. У продукті представлені можливості інтеграції з поштовими, телефонними та пейджинговими системами.

У зв'язку з актуальністю та корисністю перерахованих додаткових можливостей, виробники програмних рішень намагаються включати їх у свої продукти. Багато з сказаного про HP Service Desk відноситься і до продуктів інших виробників, у тому числі Remedy, Tivoli, CA, Peregrin, FrontRange.

Тим, хто береться за роботу з впровадження цих процесів, треба бути готовим до різноманітних труднощів. Серед них:

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

***

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

Література

1. З. Альохін. ITIL – основа концепції управління ІТ-службами. "Відкриті системи". 2001 № 3
2. З. Альохін. Service Desk – цілі, можливості, реалізації. "Відкриті системи". 2001 № 5-6
3. CCTA. Best Practice for Service Support. London: The Stationery Office, 2000

Заурбек Альохін ([email protected]) – керівник проекту компанії i-Teco (Москва).

Що таке інцидент

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

Програми:

• служба недоступна;
• помилка у додатку, що не дає клієнту нормально працювати;
• вичерпано дисковий простір.

Обладнання:

• збій системи;
• внутрішній сигнал тривоги;
• відмова принтера.

Заявки на обслуговування:

• надходження заявки на отримання додаткової інформації, поради, документації;
• забутий пароль.

Більшість груп ІТ-фахівців мають відношення до усунення тих чи інших інцидентів. Служба Service Desk відповідає за моніторинг процесу усунення всіх зареєстрованих інцидентів, оскільки є власником усіх таких інцидентів. Цей процес більшою мірою реактивний; для ефективного реагування на інциденти має бути визначено формальний метод роботи співробітників, що включає використання необхідного програмного забезпечення.

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

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

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

Фахівці команди реагування аналізують загрози та сприяють підтримці в актуальному стані, прийнятій службою інформаційної безпеки організації, моделі порушника.

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

Виявлення та аналіз інцидентів інформаційної безпеки

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

Служба реагування повинна класифікувати та описати кожен інцидент, що відбувся в організації, а також класифікувати та описати можливі інциденти, припущення про які були зроблені на основі аналізу ризиків.

Для розширення тезаурусу про можливі загрози та пов'язані з ними можливі інциденти гарною практикою є використання постійно оновлюваних відкритих джерел мережі Internet.

Ознаки інциденту інформаційної безпеки

Припущення про те, що в організації стався інцидент інформаційної безпеки, має базуватись на трьох основних чинниках:

• повідомлення про інцидент інформаційної безпеки надходять одночасно з кількох джерел (користувачі, IDS, журнальні файли)
• IDS сигналізують про множинну подію, що повторюється
• Аналіз журнальних файлів автоматизованої системи дає підстави для виведення системним адміністраторам щодо можливості настання події інциденту

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

• IDS фіксує переповнення буфера
• повідомлення антивірусної програми
• крах WEB – інтерфейсу
• користувачі повідомляють про вкрай низьку швидкість при спробі виходу в Інтернет
• системний адміністратор фіксує наявність файлів із нечитабельними назвами
• користувачі повідомляють про наявність у своїх поштових скриньках безлічі повідомлень, що повторюються
• хост робить запис до журналу аудиту про зміну конфігурації
• програма фіксує в журнальному файлі множинні невдалі спроби авторизації
• адміністратор мережі фіксує різке збільшення мережного трафіку, і т.д.

Прикладами подій, які можуть стати джерелами інформаційної безпеки можуть служити:

• журнальні файли сервера фіксують сканування портів
• оголошення в ЗМІ про появу нового виду експлойту
• відкрита заява комп'ютерних злочинців про оголошення війни вашої організації тощо.

Аналіз інцидентів інформаційної безпеки

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

Складання діагностичних матриць служить візуалізації результатів аналізу подій, які у інформаційної системі. Матриця формується із рядків потенційних ознак інциденту та стовпців – типів інцидентів. У перетині дається оцінка події за шкалою пріоритетів "високий", "середній", "низький". Діагностична матриця покликана документувати хід логічних висновків експертів у процесі ухвалення рішення і, поряд з іншими документами, є свідченням розслідування інциденту.

Документування інциденту інформаційної безпеки

Документування подій інциденту інформаційної безпеки необхідне для збирання та подальшої консолідації свідоцтв розслідування. Документуванню підлягають усі факти та докази зловмисного впливу. Розрізняють технологічні свідоцтва та операційні свідоцтва впливу. До технологічних свідоцтв відносять інформацію, отриману від технічних засобів збору та аналізу даних (сніфери, IDS), до операційних – дані або докази, зібрані в процесі опитування персоналу, свідоцтва звернень на service desk, дзвінки до call center.

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

• поточний статус розслідування
• опис інциденту
• дії, які здійснюються командою реагування в процесі обробки інциденту
• список акторів розслідування з описом їх функцій та відсотком зайнятості у процедурі розслідування
• перелік свідоцтв (з обов'язковою вказівкою джерел), зібраних під час обробки інциденту