Основные понятия управления инцидентами. В очередной раз об инцидентах и сервисных запросах

Работа с инцидентами информационной безопасности

• Информационная безопасность

Доброго дня, уважаемый хабрахабр!

Я продолжаю публикацию статей из практики по информационной безопасности.
В этот раз речь пойдёт о такой важной составляющей, как инциденты безопасности. Работа с инцидентами займёт львиную долю времени после установления режима информационной безопасности (приняты документы, установлена и настроена техническая часть, проведены первые тренинги).

Информирование об инцидентах

Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:

1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

2. Сообщения непосредственно от пользователей.
Организуйте единую точку контакта, о чём сообщите в тренинге по ИБ для сотрудников. На данный момент отделы ИБ в организациях, как правило, не очень большие, зачастую из 1-2 человек. Поэтому будет несложно назначить ответственного за приём инцидентов, можно даже не заморачиваться с выделением адреса электропочты под нужды IS Helpdesk.

3. Инциденты, обнаруженные сотрудниками ИБ.
Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.

4. Журналы и оповещения систем.
Настройте оповещения в консоли антивируса, IDS, DLP и других систем безопасности. Удобнее использовать аггрегаторы, собирающие данные также из логов программ и систем, установленных в вашей организации. Особое внимание нужно уделить точкам соприкосновения с внешней сетью и местам хранения чувствительной информации.

Хоть инциденты безопасности разнообразны и многообразны, их довольно легко разделить на несколько категорий, по которым проще вести статистику.

1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример - шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения - на лицо!

2. Несанкционированный доступ.
Для этого необходимо иметь список защищаемых ресурсов. То есть тех, где находится какая-либо чувствительная информация организации, её клиентов или подрядчиков. Причём желательно внести в эту категорию не только проникновения в компьютерную сеть, но и несанкционированный доступ в помещения.

3. Превышение полномочий.
В принципе можно объединить этот пункт с предыдущим, но лучше всё-таки выделить, объясню почему. Несанкционированный доступ подразумевает доступ тех лиц, которые не имеют никакого легального доступа к ресурсам или помещениям организации. Это внешний нарушитель, не имеющий легального входа в вашу систему. Под превышением полномочий же понимается несанкционированный доступ к каким-либо ресурсам и помещениям именно легальных сотрудников организации.

4. Вирусная атака.
В этом случае необходимо понимать следующее: единично заражение компьютера сотрудника не должно повлечь за собой разбирательство, так как это можно списать на погрешность или пресловутый человеческий фактор. Если же заражен ощутимый процент компьютеров организации (тут уже исходите из общего количества машин, их распределенности, сегментированности и тд), то необходимо разворачивать полновесную отработку инцидента безопасности с необходимыми поисками источников заражения, причин и т.д.

5. Компрометация учетных записей.
Этот пункт перекликается с 3 . Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

Классификация инцидента

С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

Сбор свидетельств инцидента

Есть особенная прикладная наука - форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика - компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

Для бумажных документов: подлинник хранится надежно с записью лица, обнаружившего документ, где документ был обнаружен, когда документ был обнаружен и кто засвидетельствовал обнаружение. Любое расследование должно гарантировать, что подлинники не были сфальсифицированы
Для информации на компьютерном носителе: зеркальные отображение или любого сменного носителя, информации на жестких дисках или в памяти должны быть взяты для обеспечения доступности. Должен сохраняться протокол всех действий в ходе процесса копирования, и процесс должен быть засвидетельствован. Оригинальный носитель и протокол (если это невозможно, то, по крайней мере, одно зеркальное отображение или копия), должны храниться защищенными и нетронутыми

После устранения инцидента

Итак, инцидент исчерпан, последствия устранены, проведено служебное расследование.
Но работа на этом не должна завершаться.
Дальнейшие действия после инцидента:

Переоценка рисков, повлекших возникновение инцидента
подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
актуализация необходимых политик, регламентов, правил ИБ
провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ

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

1. Ведите журнал регистрации инцидентов, где записывайте время обнаружения, данные сотрудника, обнаружившего инцидент, категорию инцидента, затронутые активы, планируемое и фактическое время решения инцидента, а так же работы, проведенные для устранения инцидента и его последствий.
2. Записывайте свои действия. Это необходимо в первую очередь для себя, для оптимизации процесса решения инцидента.
3. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.

В словаре ITSM есть два понятия, которые очень часто создают путаницу у ИТ-специалистов и пользователей: инцидент (Incident) и проблема (Problem). Оба они связаны с процессом решения возникшего сбоя и регистрируются с помощью создания тикета в системе Сервис-Деска. Однако по своей сути они достаточно сильно отличаются друг от друга и имеют различные способы решения. Рассмотрим пример, который просто объясняет разницу между этими понятиями.

Сломался чайник!

Утро. На завтрак вы решил заварить себе чашечку крепкого чая, чтобы взбодриться перед рабочим днем. Наливаете воду в чайник, включаете его в розетку, щелкаете выключателем, а он не включается. Щелкаете выключателем снова и снова, проверяете, есть ли электричество в доме, включаете чайник в другую розетку, но он все равно не работает. Возник ИНЦИДЕНТ!

Вы разочарованы и разозлены. Почему не работает чайник, вы не знаете, а выпить чая все равно очень хочется. Вы понимаете, что вскипятить воду можно разными способами: нагреть кипяток в кофеварке, поставить кастрюлю с водой на газ, достать походный кипятильник из кладовки – все это пути достижения поставленной цели. Одним из способов вода нагрета, чай заварен и налит в кружку – инцидент исчерпан, вы использовали обходное решение для выполнения поставленной задачи.

Теперь каждое утро вы будете использовать один из перечисленных способов для нагрева воды, пока не найдете время обратиться в мастерскую, чтобы электрик разобрался с ПРОБЛЕМОЙ, из-за которой чайник не работает. Проблема – это причина поломки чайника. Электрик обнаружит, что перегорел предохранитель из-за скачка напряжения, заменит предохранитель, и вы снова сможете кипятить воду в чайнике – проблема решена.

Какое отношение чайник имеет к ИТ?

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

Это просто, но очень эффективно!

Внедрение процесса управление проблемами позволяется изменить подход к решению инцидентов от реактивного к проактивному. Это означает, что ИТ начинает не только устранять инциденты и бороться с причиной их возникновения, но и предпринимает меры к тому, чтобы они даже не возникали. Как только все инциденты и проблемы, к ним приводящие, устранены, у ИТ-специалистов появляется время, чтобы заняться поиском «узких мест» в инфраструктуре, которые пока себя не проявляют. Хорошая организация управления инцидентами, приоритетами и классификацией создает цепной эффект для улучшения работы других ИТ-направлений компании.

Время выпить вкусного чая и проверить предохранители в других домашних приборах!

Метод критических инцидентов.

Выявление критического инцидента - это метод, предназначенный для иден-

тификации процесса, подпроцесса или проблемной области, которые стоит со-

вершенствовать. Метод разработан Лолором в 1985 году . Это вполне откры-

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

в изложении своих взглядов. Любая цензура или сокрытие информации из бояз-

ни, что она окажется слишком честной, решительно отвергается.

Метод включает три этапа:

1). Выбираются участники проведения анализа. Если цель заключается в при-

нятии решения о совершенствовании всего процесса целиком, то естественно

включить представителей различных областей в организации. Если же це-

лью является более точное определение направленности действий в рамках

уже определенного бизнес-процесса, то лучше выбрать людей, вовлеченных в

этот процесс.

2). Затем участникам обсуждения предлагается ответить на вопросы типа:

С каким инцидентом на прошлой неделе было труднее всего справиться?

Какой эпизод создал наибольшие проблемы для удовлетворения потреб-

ностей потребителя?

Какой инцидент обошелся дороже всего с точки зрения привлечения

дополнительных ресурсов или прямых расходов?

На этом этапе использования метода важно выделить так называемые кри-

тические инциденты, которые тем или иным способом создают проблемы

для отдельных сотрудников, для всей организации и для других заинтересо-

ванных сторон. Период, к которому относится вопрос, может варьироваться

от нескольких дней до нескольких месяцев. Не рекомендуется, однако, вы-

бирать слишком долгий период, так как в этом случае может оказаться зат-

руднительным выделить самый актуальный критический инцидент, потому

что для большого периода времени таких инцидентов могло быть много.

3). Собранные ответы сортируются и определяется, какой из различных инци-

дентов упоминался чаще других. Для выделения критического инцидента

удобно использовать графическое представление полученных результатов. Тот

инцидент, который встретился чаще других, и будет критическим. Он - яв-

ный кандидат на профилактику. Однако бороться нужно не столько с самим

инцидентом и его симптомом, сколько с причинами, его породившими.

Пример.

Большая корпорация, имевшая в штате 15 телефонисток, приступила

к проекту улучшения телефонного обслуживания потребителей при от-

ветах на звонки. Было решено воспользоваться методом выявления кри-

тического инцидента.

Всем телефонисткам было предложено описать те инциденты, имев-

шие место за последний месяц, которые поставили их в крайне за-труднительное положение. Результаты опроса были рассортированы по частоте

повторения инцидентов. Они представлены на рис. 7.1 в виде диаграммы. Из ри-

сунка видно, что критическими инцидентами были: 1) невозможность дозвониться до

человека, которому следовало бы отвечать на звонок, 2) незнание, кто именно дол-

жен отвечать. На основании результатов исследования были предприняты усилия

по созданию системы отслеживания перемещений каждого сотрудника, а также бы-

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

отвечать. Контрольный листок - это бланк-формуляр или специальная форма, предназ-

наченная для регистрации данных, Ролстадос (1995) . Одно из основных при-

ложений контрольного листка заключается в том, чтобы фиксировать, как часто

встречаются различные проблемы или инциденты. Это дает важную информа-

цию о проблемных областях или возможных причинах ошибок. Использование

контрольных листков создает хорошую основу для принятия решений о том, где

следует сконцентрировать усилия при проведении совершенствования.

Заполнение контрольного листка обычно идет в несколько этапов:

1) Достижение соглашения о том, какие события надо записывать. Все это надо

точно определить, чтобы не было сомнений в том, имело ли место событие

на самом деле. Желательно также включить в контрольный листок позицию

«Прочее», чтобы зарегистрировать инциденты, которые трудно отнести в

2) Определение периода регистрации данных и его удобного деления на интер-

3) Разработка формы (бланка) контрольного листка, используемого для регис-

трации. 4) Сбор данных происходит в течение всего согласованного периода времени.

Предварительно следует убедиться в том, что все принимающие участие в

сборе данных одинаково понимают суть происходящего. Тогда собранные

разными людьми данные будут состоятельными.

5) По окончании сбора данных производится их анализ для выявления собы-

тий, имеющих наивысшую частоту проявления. Это позволит определить

приоритеты проблемных областей в рамках заданного бизнес-процесса для

обеспечения акцентов в работе по совершенствованию. Удобное вспомога-

тельное средство для проведения такого анализа - диаграмма ПаретоДиаграмма Парето

Построение этой схемы основано на так называемом принципе Парето, сфор-

мулированном итальянским математиком Вильфредо Парето в 1800-х годах. Под-

робности данной схемы можно найти также в книге Ролстадоса . Парето был

озабочен распределением богатств в обществе и считал, что 20% населения вла-

деют 80% всех богатств. В переводе на современный язык систем качества этот

принцип заключается в том, что часто примерно 80% всех возможных проявлений

обусловлены примерно 20% всех возможных причин. Разумный подход в этом

случае - начать работу по совершенствованию с атаки именно на эти 20% при-

чин, которые обычно называют «жизненно важным меньшинством». Это совсем

не означает, что можно игнорировать оставшиеся 80% причин: в надлежащий

момент времени этими причинами, которые называют «этим важным большин-

ством», также следует заняться. Принцип Парето определяет приоритеты про-

блем, за решение которых следует браться.

Диаграмма Парето сама по себе представляет графическую интерпретацию в

виде скошенного распределения так называемого правила «80/20». Это причины,

рассортированные по степени важности, по частоте возникновения, по затратам,

по уровню показателей и т.д. При упорядочивании причин на диаграмме Парето

самые важные из них относят к левому краю схемы, так, чтобы это «жизненно

важное меньшинство» было легко идентифицировать. Для повышения информа-

тивности диаграммы Парето обычно на нее наносят и кривую накопленных час-

тот. Пример построения диаграммы представлен на рис. 7.4.

При работе с диаграммой Парето выполняют следующие действия:

1). Определите главную проблему события и ее различные потенциальные при-

чины. С учетом допущений, принятых в настоящей книге, будем считать,

что уже выбран конкретный процесс, который желательно улучшить. Таким

образом, цель построения диаграммы Парето заключается в идентификации

основных причин низкого уровня показателей.

2). Определите, какой количественный показатель будет использоваться при

сравнении возможных причин. В качестве такого показателя можно было бы

взять частоту возникновения разного рода проблем или их следствий в тер-

минах денежных затрат и других условий.

3). Определите период времени, в течение которого будут собраны данные и со-

берите их. Часто эта работа уже оказывается выполненной ранее при за-

полнении контрольных листков. Суть контрольного листка описана в § 7.2.

4). Расположите причины слева направо вдоль горизонтальной оси диаграммы

Парето по убыванию степени их относительной важности. Нарисуйте стол-

бики схемы. Их высота соответствует степени относительной важности соот-

ветствующей причины. 5). Отметьтеполученные абсолютные значения показателей на левой вертикаль-

ной оси. Отметьте относительные значения показателей в процентах на пра-

вой вертикальной оси. Нарисуйте кривую накопления важности вдоль верх-

него края столбиков.

Изучение диаграммы Парето может дать ответ на вопросы типа: 1) «Что пред-

ставляют собой две-три основные причины низкого уровня показателей данного

процесса?» или 2) «Какова доля затрат, приходящихся на самые жизненно важ-

ные причины?». Эта информация может быть использована для действий, на-

правленных на усилия по совершенствованию процесса в сторону достижения

его наивысших результатов.

Построение диаграммы Парето можно упростить, если пользоваться стандар-

тным компьютерным обеспечением, предназначенным для составления элект-

ронных таблиц. Вместе с тем для построения диаграмм Парето есть и специали-

зированное программное обеспечение. Две такие специализированные компьютерные программы - это StatGraphics Plus и ASAS/QC. Они также дают воз-

можность пользователю строить контрольные карты СУП"а. Отметим также пакет

Memory Jogger software, который может применяться с некоторыми инструментами

повышения качества.

Достоинства: Позволяет получать информацию о качествах, которые способствуют или препятствуют достижению результата в работе. Способствует лучшему пониманию содержания работы.

Недостатки: Часть полученной информации может не использоваться при создании модели, так как ряд описанных инцидентов может в итоге оказаться совершенно не характерным для работы.

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

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

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

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

Обнаружение и анализ инцидентов информационной безопасности

Инциденты информационной безопасности могут иметь различные источники происхождения. В идеале, организация должна быть готова к любым проявлением вредоносной активности. На практике это неосуществимо.

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

Для расширения тезауруса о возможных угрозах и связанных с ними возможных инцидентов хорошей практикой является использование постоянно обновляемых открытых источниках сети Internet.

Признаки инцидента информационной безопасности

Предположение о том, что в организации произошёл инцидент информационной безопасности, должно базироваться на трёх основных факторах:

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

В общем случае, признаки инцидента делятся на две основные категории, сообщения о том инцидент происходит в настоящий момент и сообщения о том, что инцидент, возможно, произойдёт в скором будущем. Ниже перечислены некоторые признаки совершающегося события:

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

Примерами событий, которые могут послужить источниками информационной безопасности могут служить:

• журнальные файлы сервера фиксируют сканирование портов
• объявление в СМИ о появлении нового вида эксплойта
• открытое заявление компьютерных преступников об объявлении войны вашей организации и.т.д.

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

Инцидент не является очевидным свершившимся фактом, напротив, злоумышленники стараются сделать всё чтобы не оставить в системе следов своей деятельности. Признаки инцидента содержит незначительное изменение в файле конфигурации сервера или, на первый взгляд, стандартная жалоба пользователя электронной почты. Принятие решения о наступлении события инцидента во многом зависит от компетентности экспертов команды реагирования. Необходимо отличать случайную ошибку оператора от злонамеренного целенаправленного воздействия на информационную систему. Факт отработки “в холостую” инцидента информационной безопасности также является инцидентом информационной безопасности, поскольку отвлекает экспертов команды реагирования от насущных проблем. Руководство организации должно обратить внимание на данное обстоятельство и предоставить экспертам команды реагирования известную свободу действий.

Составление диагностических матриц служит для визуализации результатов анализа событий, происходящих в информационной системе. Матрица формируется из строк потенциальных признаков инцидента и столбцов – типов инцидентов. В пересечении даётся оценка событию по шкале приоритетов “высокий”, “средний”, ”низкий”. Диагностическая матрица призвана документировать ход логических заключений экспертов в процессе принятия решения и, наряду с другими документами, служит свидетельством расследования инцидента.

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

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

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

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

Инцидент (incident или INC ) – любое событие (сбои, запросы на консультации и т.п,), не являющееся частью нормальной работы услуги, ведущее/способное привести к остановке услуги или снижению уровня её качества.

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

Для успешного управления инцидентами необходимо создание диспетчерской службы (Service desk ), которая должна являться единой точкой контакта с пользователями и координирует устранение инцидентов. Service Desk - подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.

Эскалация – механизм, служащий своевременному разрешению INC с помощью привлечения дополнительных знаний (функциональная эскалация) или полномочий (иерархическая эскалация). Цель - решить INC в срок указанный в SLA .

Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.

Различают функциональную и иерархическую эскалацию:

• Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
• Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.

Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.

Маршрутизация инцидента, или функциональная эскалация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk , второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации . В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки.

Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это раз­граничение иногда может запутывать, но его главное достоинство заключается в установлении разли­чия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением.

Процесс Управления Инцидентами предназначен для устранения инцидента и быстрого возобнов­ления предоставления услуг . Инциденты регистрируются, причем качество регистрационной ин­формации определяет эффективность ряда других процессов.

Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами :

1. Создание базы данных записей обо всех инцидентах . Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления (электронная почта, телефонный звонок, факс и т.д.). Вся информация о ходе решения инцидента так же должна фиксироваться в базе данных.
2. Создание базы знаний , где будет содержаться дополнительная информация для разрешения инцидента. Чем больше информации, тем лучше. В ITIL это базы данных управления конфигурацией (CMDB) и/или системы управления конфигурацией (CMS).
3. Разработайте и утвердите четкие инструкции и правила обработки инцидентов (регистрация, классификация, определение приоритета, анализа и т.д.).
4. Определите, в привязке к SLA, процедуры , которые позволят вам управлять воздействием (impact) инцидента на бизнес.
5. Создайте модель «основного инцидента» – набор правил четко описывающих очень серьёзный инцидент. Под основным инцидентом понимается такой, который затрагивает критичный бизнес-сервис и/или большое количество заказчиков и пользователей. В любом случае, основной инцидент требует немедленной эскалации, уведомления заказчиков и другой специальной обработки. Вся суть заключается в том, что такой инцидент требует максимальной реакции со стороны ИТ-организации.
6. Информируйте тех, кто сообщил вам об инциденте, о статусе работ . Вам необходимо представлять, кому и как часто необходимо направлять информацию. Например, Вы можете уведомить об инциденте заказчиков и пользователей. Вы должны также проинформировать их о невозможности вернуть уровень предоставляемого сервиса к согласованным параметрам в согласованное время.

Если у вас не реализован хотя бы один из этих 6 пунктов, то, в соответствии со стандартом ISO/IEC 20000-1 (Service Management), сфокусировавшись на нем, вы сможете улучшить качество сервиса. Если же все пункты у вас реализованы, то, скорее всего, вам уже не нужно тратить много времени на внедрение процесса управления инцидентами – сосредоточьтесь на других областях ITIL, таких как Управление проблемами (Problem Management ) или Управление изменениями (Change Management ).

В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание .

Запрос на обслуживание – это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.

Примеры Запросов на Обслуживание:

• вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
• запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
• запрос о замене пароля;
• запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
• получение информации из базы данных.

Для того чтобы можно было отличить “настоящие инциденты ” от “инцидентов-Запросов на Обслу­живание “, рекомендуется присваивать Запросам на Обслуживание специальную категорию.

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты . Обос­нованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользо­вателя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уров­нях Услуг (Service Level Agreements – SLAs ) Служба Service Desk назначает приоритеты, определя­ющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более ли­нии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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