Работа с инцидентами информационной безопасности
- Информационная безопасность
Доброго дня, уважаемый хабрахабр!
Я продолжаю публикацию статей из практики по информационной безопасности.
В этот раз речь пойдёт о такой важной составляющей, как инциденты безопасности. Работа с инцидентами займёт львиную долю времени после установления режима информационной безопасности (приняты документы, установлена и настроена техническая часть, проведены первые тренинги).
Информирование об инцидентах
Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:
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.
Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.
Действует Редакция от 27.12.2007
| Наименование документ | "НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст) |
| Вид документа | приказ, стандарт, гост |
| Принявший орган | ростехрегулирование |
| Номер документа | 18044-2007 |
| Дата принятия | 01.01.1970 |
| Дата редакции | 27.12.2007 |
| Дата регистрации в Минюсте | 01.01.1970 |
| Статус | действует |
| Публикация |
|
| Навигатор | Примечания |
"НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст)
6 Примеры инцидентов информационной безопасности и их причин
Инциденты ИБ могут быть преднамеренными или случайными (например, являться следствием какой-либо человеческой ошибки или природных явлений) и вызваны как техническими, так и нетехническими средствами. Их последствиями могут быть такие события, как несанкционированные раскрытие или изменение информации, ее уничтожение или другие события, которые делают ее недоступной, а также нанесение ущерба активам организации или их хищение. Инциденты ИБ, о которых не было сообщено, но которые были определены как инциденты, расследовать невозможно и защитных мер для предотвращения повторного появления этих инцидентов применить нельзя.
Ниже приведены некоторые примеры инцидентов ИБ и их причин, которые даются только с целью разъяснения. Важно заметить, что эти примеры не являются исчерпывающими.
6.1 Отказ в обслуживании
Отказ в обслуживании является обширной категорией инцидентов ИБ, имеющих одну общую черту.
Подобные инциденты ИБ приводят к неспособности систем, сервисов или сетей продолжать функционирование с прежней производительностью, чаще всего при полном отказе в доступе авторизованным пользователям.
Существует два основных типа инцидентов ИБ, связанных с отказом в обслуживании, создаваемых техническими средствами: уничтожение ресурсов и истощение ресурсов.
Некоторыми типичными примерами таких преднамеренных технических инцидентов ИБ "отказ в обслуживании" являются:
Зондирование сетевых широковещательных адресов с целью полного заполнения полосы пропускания сети трафиком ответных сообщений;
Передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу;
Одновременное открытие нескольких сеансов с конкретной системой, сервисом или сетью в попытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение).
Одни технические инциденты ИБ "отказ в обслуживании" могут возникать случайно, например в результате ошибки в конфигурации, допущенной оператором, или из-за несовместимости прикладного программного обеспечения, а другие - преднамеренными. Одни технические инциденты ИБ "отказ в обслуживании" инициируются намеренно с целью разрушения системы, сервиса и снижения производительности сети, тогда как другие - всего лишь побочными продуктами иной вредоносной деятельности.
Например, некоторые наиболее распространенные методы скрытого сканирования и идентификации могут приводить к полному разрушению старых или ошибочно сконфигурированных систем или сервисов при их сканировании. Следует заметить, что многие преднамеренные технические инциденты типа "отказ в обслуживании" часто инициируются анонимно (то есть источник атаки неизвестен), поскольку злоумышленник обычно не получает информации об атакуемой сети или системе.
Инциденты ИБ "отказ в обслуживании", создаваемые нетехническими средствами и приводящие к утрате информации, сервиса и (или) устройств обработки информации, могут вызываться, например, следующими факторами:
Нарушениями систем физической защиты, приводящими к хищениям, преднамеренному нанесению ущерба или разрушению оборудования;
Случайным нанесением ущерба аппаратуре и (или) ее местоположению от огня или воды/наводнения;
Экстремальными условиями окружающей среды, например высокой температурой (вследствие выхода из строя системы кондиционирования воздуха);
Неправильным функционированием или перегрузкой системы;
Неконтролируемыми изменениями в системе;
Неправильным функционированием программного или аппаратного обеспечения.
6.2 Сбор информации
В общих чертах инциденты ИБ "сбор информации" подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки. Подобные инциденты ИБ предполагают проведение разведки с целью определения:
Наличия цели, получения представления об окружающей ее сетевой топологии и о том, с кем обычно эта цель связана обменом информации;
Потенциальных уязвимостей цели или непосредственно окружающей ее сетевой среды, которые можно использовать для атаки.
Типичными примерами атак, направленных на сбор информации техническими средствами, являются:
Сбрасывание записей DNS (системы доменных имен) для целевого домена Интернета (передача зоны DNS);
Отправка тестовых запросов по случайным сетевым адресам с целью найти работающие системы;
Зондирование системы с целью идентификации (например, по контрольной сумме файлов) операционной системы хоста;
Сканирование доступных сетевых портов на протокол передачи файлов системе с целью идентификации соответствующих сервисов (например электронная почта, протокол FTP, сеть и т. д.) и версий программного обеспечения этих сервисов;
Сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов (горизонтальное сканирование).
В некоторых случаях технический сбор информации расширяется и переходит в несанкционированный доступ, если, например, злоумышленник при поиске уязвимости пытается получить несанкционированный доступ. Обычно это осуществляется автоматизированными средствами взлома, которые не только производят поиск уязвимости, но и автоматически пытаются использовать уязвимые системы, сервисы и (или) сети.
Инциденты, направленные на сбор информации, создаваемые нетехническими средствами, приводят к:
Прямому или косвенному раскрытию или модификации информации;
Хищению интеллектуальной собственности, хранимой в электронной форме;
Нарушению учетности, например, при регистрации учетных записей;
Неправильному использованию информационных систем (например, с нарушением закона или политики организации).
Инциденты могут вызываться, например, следующими факторами:
Нарушениями физической защиты безопасности, приводящими к несанкционированному доступу к информации и хищению устройств хранения данных, содержащих значимые данные, например ключи шифрования;
Неудачно и (или) неправильно конфигурированными операционными системами по причине неконтролируемых изменений в системе или неправильным функционированием программного или аппаратного обеспечения, приводящим к тому, что персонал организации или посторонний персонал получает доступ к информации, не имея на это разрешения.
6.3 Несанкционированный доступ
Несанкционированный доступ как тип инцидента включает в себя инциденты, не вошедшие в первые два типа. Главным образом этот тип инцидентов состоит из несанкционированных попыток доступа в систему или неправильного использования системы, сервиса или сети. Некоторые примеры несанкционированного доступа с помощью технических средств включают в себя:
Попытки извлечь файлы с паролями;
Атаки переполнения буфера с целью получения привилегированного (например, на уровне системного администратора) доступа к сети;
Использование уязвимостей протокола для перехвата соединения или ложного направления легитимных сетевых соединений;
Попытки расширить привилегии доступа к ресурсам или информации по сравнению с легитимно имеющимися у пользователя или администратора.
Инциденты несанкционированного доступа, создаваемые нетехническими средствами, которые приводят к прямому или косвенному раскрытию или модификации информации, нарушениям учетности или неправильному использованию информационных систем, могут вызываться следующими факторами:
Разрушением устройств физической защиты с последующим несанкционированным доступом к информации;
Неудачной и (или) неправильной конфигурацией операционной системы вследствие неконтролируемых изменений в системе или неправильного функционирования программного или аппаратного обеспечения, приводящих к результатам, подобным тем, которые описаны в последнем абзаце 6.2.
Метод критических инцидентов.
Выявление критического инцидента - это метод, предназначенный для иден-
тификации процесса, подпроцесса или проблемной области, которые стоит со-
вершенствовать. Метод разработан Лолором в 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, который может применяться с некоторыми инструментами
повышения качества.
Достоинства: Позволяет получать информацию о качествах, которые способствуют или препятствуют достижению результата в работе. Способствует лучшему пониманию содержания работы.
Недостатки: Часть полученной информации может не использоваться при создании модели, так как ряд описанных инцидентов может в итоге оказаться совершенно не характерным для работы.
Инцидент (incident или INC ) – любое событие (сбои, запросы на консультации и т.п,), не являющееся частью нормальной работы услуги, ведущее/способное привести к остановке услуги или снижению уровня её качества.
Цель процесса управления инцидентами - скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.
Для успешного управления инцидентами необходимо создание диспетчерской службы (Service desk ), которая должна являться единой точкой контакта с пользователями и координирует устранение инцидентов. Service Desk - подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.
Эскалация – механизм, служащий своевременному разрешению INC с помощью привлечения дополнительных знаний (функциональная эскалация) или полномочий (иерархическая эскалация). Цель - решить INC в срок указанный в SLA .
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
- Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
- Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Маршрутизация инцидента, или функциональная эскалация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk , второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации . В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки.
Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это разграничение иногда может запутывать, но его главное достоинство заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением.
Процесс Управления Инцидентами предназначен для устранения инцидента и быстрого возобновления предоставления услуг . Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов.
Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами :
- Создание базы данных записей обо всех инцидентах . Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления (электронная почта, телефонный звонок, факс и т.д.). Вся информация о ходе решения инцидента так же должна фиксироваться в базе данных.
- Создание базы знаний , где будет содержаться дополнительная информация для разрешения инцидента. Чем больше информации, тем лучше. В ITIL это базы данных управления конфигурацией (CMDB) и/или системы управления конфигурацией (CMS).
- Разработайте и утвердите четкие инструкции и правила обработки инцидентов (регистрация, классификация, определение приоритета, анализа и т.д.).
- Определите, в привязке к SLA, процедуры , которые позволят вам управлять воздействием (impact) инцидента на бизнес.
- Создайте модель «основного инцидента» – набор правил четко описывающих очень серьёзный инцидент. Под основным инцидентом понимается такой, который затрагивает критичный бизнес-сервис и/или большое количество заказчиков и пользователей. В любом случае, основной инцидент требует немедленной эскалации, уведомления заказчиков и другой специальной обработки. Вся суть заключается в том, что такой инцидент требует максимальной реакции со стороны ИТ-организации.
- Информируйте тех, кто сообщил вам об инциденте, о статусе работ . Вам необходимо представлять, кому и как часто необходимо направлять информацию. Например, Вы можете уведомить об инциденте заказчиков и пользователей. Вы должны также проинформировать их о невозможности вернуть уровень предоставляемого сервиса к согласованным параметрам в согласованное время.
Если у вас не реализован хотя бы один из этих 6 пунктов, то, в соответствии со стандартом ISO/IEC 20000-1 (Service Management), сфокусировавшись на нем, вы сможете улучшить качество сервиса. Если же все пункты у вас реализованы, то, скорее всего, вам уже не нужно тратить много времени на внедрение процесса управления инцидентами – сосредоточьтесь на других областях ITIL, таких как Управление проблемами (Problem Management ) или Управление изменениями (Change Management ).
В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание .
Запрос на обслуживание – это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.
Примеры Запросов на Обслуживание:
- вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
- запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
- запрос о замене пароля;
- запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
- получение информации из базы данных.
Для того чтобы можно было отличить “настоящие инциденты ” от “инцидентов-Запросов на Обслуживание “, рекомендуется присваивать Запросам на Обслуживание специальную категорию.
При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты . Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements – SLAs ) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.
- степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздействию инцидента;
- срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.
Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий.
Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей.
Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования.
Как видно из определения процесса, Управление инцидентами предназначено для максимально быстрого восстановления нормальной эксплуатации услуги и минимизации неблагоприятного влияния на бизнес в случае возникновения инцидента. Под "нормальной эксплуатацией услуги" здесь понимается эксплуатация в соответствии с SLA . Процесс рассматривает все события, которые нарушают или могут нарушить нормальную эксплуатацию услуги. Информация о таких событиях может поступать из разных источников, основными из которых являются звонки пользователей и технического персонала в сервис-деск и процесс Управления событиями.
Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что:
- быстро находит и разрешает инциденты, в результате чего снижается время простоя услуг, что в целом увеличивает показатели доступности услуг;
- выравнивает деятельности IT в соответствии с приоритетами бизнеса;
- увеличивает способность выявления возможностей для улучшения услуг в результате расследования инцидентов;
- сервис-деск, разрешая инциденты, определяет дополнительные требования IT и бизнеса к услугам и обучению.
Время разрешения инцидента обычно формализовано в рамках SLA , OLA и других базовых соглашений. Команды поддержки должны быть готовы к соблюдению временных ограничений.
ITIL вводит также понятие Модель инцидентов, которая включает в себя:
- шаги, которые необходимо предпринять для того, чтобы разрешить инцидент;
- хронологический порядок шагов;
- распределение ответственностей - кто и что делает;
- временные рамки и пороговые величины для завершения каждого действия;
- вопросы того, с кем необходимо связать и на каком этапе;
Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих "стандартных" инцидентов. "Нестандартные" случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. В отдельную категорию выделяются "значительные инциденты", которые должны разрешаться максимально быстро. Значительный инцидент (Major Incident ) наивысшая категория влияния для инцидента. Значительный инцидент означает значительные потери для бизнеса. То, какие инциденты будут считаться значительными, каждая организация решает индивидуально.
Для того чтобы разрешить инцидент, его необходимо сначала обнаружить, то есть идентифицировать. С точки зрения непрерывности бизнеса неприемлемо ждать обращений пользователей или технического персонала в сервис-деск. Все ключевые компоненты должны контролироваться, чтобы своевременно обнаруживать сбои или возможности их возникновения.
После того, как инцидент обнаружен, информацию о нем необходимо занести в лог. В логе должно быть отображено время обнаружения инцидента, вне зависимости от того, как он был обнаружен - по звонку в сервис-деск или в результате работы автоматических агентов. В логе также необходимо записать всю связанную с инцидентом информацию. Запись об инциденте должна послужить базой для его разрешения соответствующей командой поддержки.
Запись об инциденте должна включать:
- уникальный идентификатор инцидента;
- категорию инцидента;
- срочность инцидента. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета.
- влияние инцидента;
- приоритет инцидента;
- дата и время записи;
- Имя/ID человека или группы, сделавшей запись об инциденте;
- метод уведомления;
- имя/отдел/номер/расположение пользователя;
- метод обратной связи;
- описание симптомов;
- статус инцидента;
- связанные конфигурационные единицы;
- группа поддержки/сотрудник, к кому переадресован инцидент;
- связанная с инцидентом проблема/известная ошибка;
- деятельности, осуществленные для разрешения инцидента;
- время и дата разрешения инцидента;
- категория закрытия;
- время и дата закрытия.
Следующий этап разрешения инцидента - категорирование . Оно необходимо для дальнейших работ , в частности, поиска известных ошибок и проблем, которые могли послужить причиной для возникновения инцидента. Обычно используется три-четыре уровня категорирования (рис. 12.3).
Рис.
12.3.
Нет стандартных методов для категорирования инцидентов, каждая организация сама определяет, какие категории будет использовать.
Приоритет инцидента определяется исходя из двух понятий - срочности и влияния. Влияние в отношении инцидентов чаще всего определяется на основе количества пользователей, которые он затронул. Тем не менее, этот показатель не всегда является объективным. В некоторых случаях влияние инцидента даже на одного единственного пользователя может оказать значительное негативное влияние на бизнес в целом.
Другие факторы, которые можно использовать для оценки влияния:
- риск для жизни или сегмента;
- количество услуг, которые затрагивает инцидент;
- уровень финансовых потерь;
- влияние на бизнес-репутацию;
- возникновение нарушений законодательства и требований регуляторов.
В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить.
| Влияние | ||||
|---|---|---|---|---|
| Высокое | Среднее | Низкое | ||
| Срочность | Высокая | 1 | 2 | 3 |
| Средняя | 2 | 3 | 4 | |
| Низкая | 3 | 4 | 5 | |
| Приоритет | Характеристика | Время разрешения |
|---|---|---|
| 1 | Критичный | 1 час |
| 2 | Высокий | 8 часов |
| 3 | Средний | 24 часа |
| 4 | Низкий | 48 часов |
| 5 | Планируемый | Запланировать |
Для персонала поддержки необходимо разработать четкие инструкции определения приоритета инцидента на основе срочности и влияния на бизнес. Необходимо отметить, что приоритет инцидента может меняться в зависимости от изменения окружающих условий и требований бизнеса.
Далее следует этап начальной диагностики. В первую очередь он относится к инцидентам, поступившим в сервис-деск. Специалист службы сервис-деск должен попытаться найти причину, вызвавшую инцидент, понять, что именно работает некорректно и выявить максимальное количество характеристик инцидента во время связи с пользователем, например, по телефону. Другими словами, специалист должен попытаться решить инцидент и закрыть его. Если это невозможно, он сообщает пользователю идентификационный номер инцидента.
Если сервис-деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше.
Эскалация (Escalation) - деятельность , направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация.
- функциональная эскалация. Функциональная эскалация подразумевает передачу инцидента в группу поддержки с более высокой квалификацией и компетенцией. При этом если очевидно, что второй уровень поддержки не сможет разрешить инцидент, его можно сразу передать на третий уровень поддержки . Третий уровень поддержки может включать в себя не только сотрудников организации, но и поставщиков, вендоров и т.п. При этом ответственность за уведомление пользователя о ходе разрешения инцидента остается на сервис-деске, вне зависимости от того, где инцидент рассматривается на данный момент.
- иерархическая эскалация. Иерархическая эскалация подразумевает вовлечение или просто информирование руководителей более высокого уровня о возникновении инцидента. Она способствует своевременному принятию решений относительно выделения дополнительных ресурсов и вовлечения внешних организаций в процесс разрешения инцидента.
Следующий этап разрешения инцидентов называется исследование и диагностика . В случаях, когда пользователи обращаются только для поиска информации, сервис-деск должен предоставить ее в минимальные сроки. Но если сообщается о наличии сбоя, это требует определенных действий по исследованию и диагностике инцидента. При этом все предпринятые действия должны быть отображены в записи об инциденте. Действия чаще всего включают в себя:
- установление того, что именно не работает или что именно ищет пользователь;
- определение хронологии событий;
- оценка влияния инцидента, в том числе количества пользователей, которых он затронул;
- поиск в базе знаний аналогичных случаев в прошлом.
Когда потенциальное разрешение инцидента определено, необходимо провести тестирование того, что действия по восстановлению завершены, и услуга полностью восстановлена для пользователей. Группа , разрешившая инцидент, должна передать его на закрытие сервис-деску.
Сервис-деск, в свою очередь проверяет, что все действия, необходимые для разрешения инцидента, выполнены, пользователи удовлетворены и согласны закрыть инцидент. Это включает в себя следующее:
- закрытие категорирования - производится проверка корректности изначально установленной категории инцидента. Если она оказалось неправильной, ее исправление и занесение изменений в запись об инциденте;
- опрос удовлетворенности пользователей - - осуществляется по звонку или электронной почте для статистики и отображения эффективности работы сервис-деска;
- проверка полноты записи об инциденте;
- определение того, какая проблема вызвала инцидент, является она постоянной или периодически повторяющейся. Сюда относится также определение проактивных действий по предотвращению инцидентов этого типа в дальнейшем и формирование записи о проблеме, если она новая;
- формальное закрытие инцидента - формальное закрытие записи об инциденте.
В некоторых случаях инцидент может быть повторно открыт даже после формального закрытия. Правильным будет заранее определить правила о том, как, когда и при каких условиях инцидент может быть повторно открыт. Это используется, в частности, когда в один и тот же день возникают одинаковые инциденты. Для нового инцидента, тем не менее, необходимо сформировать новую запись со ссылкой на предыдущий инцидент. Запись о предыдущем инциденте может быть использована для разрешения нового.
Метриками эффективности процесса Управления инцидентами могут быть:
- общее количество инцидентов;
- количество инцидентов, находящихся на разных стадиях - закрыт, в работе, передан и т.п.
- размер текущего лога об инцидентах;
- количество значительных инцидентов;
- среднее время разрешения инцидентов;
- процент инцидентов, разрешенных в согласованное время разрешения инцидентов;
- средние затраты на инцидент;
- количество повторно открытых инцидентов и их процентное соотношение к общему количеству инцидентов;
- количество инцидентов, неправильно назначенных в команды поддержки;
- количество инцидентов, для которых были неправильно определены категории;
- количество удаленно разрешенных инцидентов (без персонального присутствия);
- количество инцидентов, разрешенных с использованием каждой Модели инцидентов;
- количество инцидентов в разрезе определенных интервалов дня.
Для эффективного Управления инцидентами необходимо обеспечить следующее:
- способность обнаруживать инциденты как можно раньше. Это включает в себя обучение пользователей немедленно сообщать об инцидентах и конфигурирование инструментов Управления событиями;
- убедить персонал в том, что все инциденты должны быть занесены в журнал;
- доступность информации об известных проблемах и ошибках. Это позволит персоналу использовать опыт предыдущих инцидентов;
- взаимодействие с CMS для определения взаимосвязей конфигурационных единиц и обращения к их истории для поддержки первого уровня;
- взаимодействие с SLM для корректной оценки инцидентов, расстановки приоритетов и выполнения процедур Эскалации. SLM в свою очередь может использовать информацию от Управления инцидентами для определения того, что целевые уровни производительности реалистичны и могут быть достигнуты.
Основные риски для процесса Управления инцидентами:
- большое количество инцидентов, которые не могут быть разрешены в установленные сроки в связи с недостатком ресурсов или их недостаточной подготовкой;
- приостановка разрешения инцидентов из-за некорректной работы поддерживающих инструментов;
- недостаточность или несвоевременность информации из-за некорректной работы поддерживающих инструментов или плохой взаимосвязи с другими процессами;
- несоответствия с основными контрактами и соглашениями, которые возникают вследствие их плохой проработки и нереалистичности согласованных целевых показателей.