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

5.3.1 Обработка Инцидента.

Большинство ИТ-подразделений и специализированных групп в той или иной степени вовлечены в обработку Инцидентов. Служба Service Desk отвечает за мониторинг процесса разрешения всех зарегистрированных Инцидентов и фактически является владельцем всех Инцидентов. Этот процесс в большей части работает по принципу реагирования. Для того чтобы продуктивно и эффективно реагировать, требуются формальные методы работы, которые могут поддерживаться программными средствами.

Инциденты, которые Служба Service Desk сразу не может разрешить, могут быть переданы для обработки одной из специализированных групп. Разрешение или Обходное решение должно быть представлено в максимально короткие сроки для того, чтобы восстановить обслуживание Пользователей с минимальным влиянием на их работу. После устранения причины Инцидента и восстановления согласованной услуги Инцидент закрывается.

На Рисунке 5.2 показаны процессы, происходящие в течение жизненного цикла Инцидента. В Приложении 5Д эти процессы представлены с другой точки зрения.

Рисунок 5.2 - Жизненный цикл Инцидента.

Статус Инцидента отражает его текущее положение в жизненном цикле, иногда называемое «позицией в диаграмме последовательности выполняемых действий». Каждый сотрудник должен знать все возможные статусы и их значения. Несколько примеров категорий статусов:.

■ новый;.

■ принят;.

■ определены сроки;.

■ назначен/передан специалисту;.

■ в работе (Work In Progress, WIP);.

■ ожидание;.

■ разрешен;.

■ закрыт.

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

■ обновить исторические сведения;.

■ изменить статус (например, со статуса «новый» на статус «в работе» или «ожидание»);.

■ изменить влияние на бизнес и приоритет;.

■ ввести потраченное время и затраты;.

■ отследить статус эскалации.

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

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

■ имя человека, сделавшего изменение в записи;.

■ дата и время изменения;.

■ что именно этот человек изменил (например, приоритет, статус, историю);.

■ почему было внесено изменение;.

■ потраченное время.

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

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

5.3.2 Первая, вторая и третья линии поддержки.

Часто подразделения и (специализированные) группы поддержки, не входящие в состав Службы Service Desk, называются группами поддержки второй или третьей линии. Они обладают более специализированными навыками, дополнительным временем или другими ресурсами для разрешения Инцидентов. Исходя из этого, Служба Service Desk называется первой линией поддержки. На Рисунке 5.3 показано, как эта терминология связана с действиями в процессе Управления инцидентами, о которых говорилось в предыдущих параграфах.

Заметьте, что третья и/или N-я линия поддержки могут со временем включать внешних поставщиков, которые могут иметь прямой доступ к средствам регистрации Инцидентов (в зависимости от правил безопасности и технических вопросов).

Рисунок 5.3 ~ Первая, вторая и третья линии поддержки.

5.3.3 Сравнение функциональной и иерархической эскалации.

«Эскалация» - механизм, способствующий своевременному разрешению Инцидента. Он может сработать на любом этапе процесса разрешения.

Передача Инцидента от групп поддержки первой линии к группам поддержки второй линии или дальше называется «функциональной эскалацией» и происходит по причине недостатка знаний или квалификации. Предпочтительно, чтобы функциональная эскалация происходила в случаях, когда истекает согласованное время, отведенное на разрешение Инцидента. Автоматическая функциональная эскалация, которая вызывается по истечении определенного периода времени, должна быть тщательно спланирована и не должна превышать согласованное (в SLA) время разрешения.

«Иерархическая эскалация» может произойти в любой момент процесса разрешения, если существует вероятность того, что разрешение Инцидента не удастся завершить вовремя или оно окажется неудовлетворительным. В случае, если не хватает знаний или квалификации, иерархическая эскалация обычно производится вручную (Службой Service Desk или другим персоналом поддержки). Возможность проведения автоматической иерархической эскалации может рассматриваться после некоторого критичного периода времени, когда становится очевидным, что своевременно разрешить Инцидент не удастся. Предпочтительно, чтобы эскалация происходила задолго до истечения времени, отведенного (в SLA) на разрешение. Это позволит линейному руководству, имеющему соответствующие полномочия, принять меры по исправлению ситуации, например нанять специалистов внешнего поставщика.

5.3.4 Приоритет.

Приоритет Инцидента первоначально определяется его влиянием на бизнес и срочностью, с которой необходимо обеспечить разрешение или Обходное решение. Целевые показатели для разрешения Инцидентов или обработки запросов обычно включаются в SLA. На практике целевые показатели разрешения Инцидентов часто связаны с категориями. Примеры категорий и приоритетов, а также систем их кодирования, можно найти в Приложениях 5А и 5Б соответственно.

Службе Service Desk отводится важная роль в процессе Управления инцидентами:.

■ обо всех Инцидентах сообщается в Службу Service Desk, и ее сотрудники регистрируют Инциденты; в случаях, когда Инциденты генерируются автоматически, процесс все равно должен включать регистрацию через Службу Service Desk;.

■ основная масса Инцидентов (возможно, до 85% при высоком уровне навыков персонала) будет разрешена Службой Service Desk;.

■ Служба Service Desk - «независимое» подразделение, которое наблюдает за ходом разрешения всех зарегистрированных Инцидентов.

Ниже приведен перечень основных действий, которые выполняются Службой Service Desk после получения уведомления об Инциденте:.

■ запись основных сведений - включая время и полученные подробности о симптомах;.

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

■ для дополнения записи об Инциденте на основе CMDB происходит выбор Учетных элементов (УЭ), являющихся, по сообщению, причиной Инцидента;.

■ установка соответствующего приоритета и передача Пользователю уникального номера Инцидента, автоматически генерируемого системой (чтобы сообщать его при дальнейших обращениях в службу);.

■ оценка Инцидента и, по возможности, предоставление рекомендаций по его разрешению: часто это возможно для стандартных Инцидентов или, когда его причиной является известная Проблема/ошибка;.

■ закрытие записи об Инциденте после его успешного разрешения: добавление сведений о действиях, связанных с разрешением, и установка соответствующего кода категории;.

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

5.3.5 Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

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

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

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

Влияние такой Проблемы часто будет оцениваться на основе влияния (как реального, так и потенциального) на бизнес-услуги, а также на основе числа заявленных похожих Инцидентов, которые, возможно, имеют одну и ту же исходную причину. Создание учетной записи Проблемы может быть уместно даже тогда, когда последствия Инцидента были устранены. Следовательно, запись о Проблеме может рассматриваться независимо от связанных с ней записей об Инцидентах, и как запись о Проблеме, так и расследование ее причины может продолжаться даже после того, как первоначальный Инцидент был успешно закрыт.

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

Рисунок 5.4 - Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

Таким образом, мы имеем следующие определения:.

■ Проблема: неизвестная исходная причина одного и более Инцидентов.

■ Известная ошибка: Проблема, которая успешно диагностирована и для которой известно Обходное решение.

■ RFC: Запрос на Изменение любого компонента ИТ-инфраструктуры или любого аспекта ИТ-услуг.

Проблема может привести к множеству Инцидентов; также возможно, что Проблема не будет диагностирована до тех пор, пока не случится несколько Инцидентов в какой-нибудь период времени. Обработка Проблем значительно отличается от обработки Инцидентов и, следовательно, описана процессом Управления проблемами.

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

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

Рисунок 5.5 - Обработка Обходных решений и разрешений инцидента.

Также возможно, что группа Управления проблемами во время расследования Проблемы, связанной с Инцидентом, найдет Обходное решение или разрешение самой Проблемы и/или некоторых связанных с ней Инцидентов. В этом случае группа Управления проблемами должна сообщить об этом процессу Управления инцидентами для того, чтобы изменить статус открытых Инцидентов на «Известная ошибка» или «Закрыт».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИНЦИДЕНТ (от лат. incidens, родительный падеж incidentis — случающийся) , случай, происшествие (обычно неприятное); столкновение, недоразумение.

Поэтому давайте сегодня рассмотрим инцидент, который возникает сплошь и рядом между мужчиной и женщиной — через призму столкновения их интересов. И здесь совсем неважно был ли этот инцидент между мужем и женой, парнем и девушкой, подчиненной(женщиной) и начальником (мужчиной).

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

Муж и жена.

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

Но! Вместо традиционной и шутливой реакции с его стороны — КТО ТАМ? Она слышит затянувшееся молчание.

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

Три коротких шага из прихожей в зал показались ей вечностью. А ее бурные фантазии успели розыграться не на шутку.

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

Жене, совсем наоборот, хотелось не просто общения, а еще и внимания и благодарности в свой адрес по-поводу ее результатов.

Вот вам две полярности, две планеты, два разных уровня пребывания сознания, два разных желания.

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

Но прежде чем я покажу выход из данной ситуции. Давайте рассмотрим еще один пример.

Начальник, подчиненная.

Ей было дано производственное задание, которое нужно было сделать к определенному сроку. В силу разных обстоятельств (а главное благодаря своему бессознательному выбору) — сроки были упущены, а задание ни сделано во — время.

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

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

Идя на оперативку он и мысли не допускал о том, что оно может быть просрочено.

А теперь пустите в ход свое воображение и представьте какой произошел инцидент в этот день. К вашим фантазиям добавлю только один факт — эта девушка была уволена с работы.

Безусловно сейчас можно очень долго рассуждать по- этому поводу.

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

С одной стороны кажется, что это совсем разные ситуации и объединить их нельзя.

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

Я же хочу вам показать суть данных конфликтов и убедить вас в том, что она у них единая.

И так для начала рассмотрим причину конфликта .

Как в первом, так и во втором случае, причиной таких инцидентов стали — НЕ ОПРАВДАННЫЕ ОЖИДАНИЯ.

Да именно они являются охилесовой пятой в рассмотренных конфликтах (и не только).

Что здесь важно понять?

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

А какие программы лежат в этих словах (осмелюсь вам еще раз напомнить)?

О (ум) — ЖИД — дАН . НАД —ад -Е- ДА .

Вот и все!

Сначала мы запускаем остановку (Оум ЖИД) своей творческой энергии. А потом лелеем себя надеждой и начинаем играть в игру — пройти (НАД -Адом через ДА т.е. согласие).

Как в первом (у жены и у мужа), так и во — втором случае (у начальника и подчиненной), каждый игрок лелеял свои ожидания.

В итоге разность энергий вложенная в их ожидания вызвала взрыв (конфликт) «на макоронной» фабрике.

В задачке спрашивается, а как можно было избежать данного инцидента?

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

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

Главное было бы желание.

Однако мой ответ был бы не полным если бы я не сказала о главном.

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

Сутью такого КЛЮЧА является формирование у себя стратегического мышления или подхода. В переводе на русский язык — это означает, что перед любой встречей с кем бы то нибыло (с мужем, женой, начальником…), вы всегда заранее определяете суть своей игры (мы все здесь на Земле играем — это нужно понимать), в которой четко формулируете свой конечный результат.

Сейчас вы мне можете возразить и сказать: «Вот завернула! Это какой я еще должна (ен) определять результат при общении с мужем (женой)! Ведь каждый день замучаешься это делать!».

И тем ни менее, как подтверждает мой личный и опыт моих клиентов —

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

Поэтому мне не надо верить — это можно только проверить.

P.S. Сейчес самое благодатное время для изменения своих деструктивных программ.

Дело утопающих, дело рук самих утопающих.

С вами была Пеняйчева Любовь .

Данную книгу можно назвать практической энциклопедией. В ней дан максимальный охват проблематики обеспечения информационной безопасности, начиная с современных подходов, обзора нормативного обеспечения в мире и в России и заканчивая рассмотрением конкретных направлений обеспечения информационной безопасности (обеспечение ИБ периметра, противодействие атакам, мониторинг ИБ, виртуальные частные сети и многие другие), конкретных аппаратно-программных решений в данной области. Книга будет полезна бизнес-руководителям компаний и тем, в чью компетенцию входит решение технических вопросов обеспечения информационной безопасности.

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

mailto:%[email protected]

[email protected]

Кроме того, 26 ноября 2004 г. были задержаны остальные шестеро подозреваемых, в числе которых были трое сотрудников абонентской службы самой компании «Вымпелком». В ходе следствия выяснилось, что сайт был создан бывшим студентом Московского государственного университета, не работавшим в данной компании.

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

Возможности инсайдера

Двое из числа выявленных среди участников инцидента сотрудников компании «Вымпелком» работали операционистами в компании, а третий являлся бывшим сотрудником и на момент преступления работал на Митинском рынке.

Работа в самой компании операционистами свидетельствует о том, что данные сотрудники имели непосредственной доступ к информации, предлагаемой к продаже на сайте www.sherlok.ru. Кроме того, так как бывший сотрудник компании уже работал на Митинском рынке, то можно предположить, что со временем одним из каналов сбыта данной информации или какой-либо еще информации из баз данных компании «Вымпелком» мог стать и данный рынок.

Последствия

Основными последствиями для компании «Вымпелком» от данного инцидента могли быть удар по репутации самой компании и потеря клиентов. Однако данный инцидент был предан огласке непосредственно благодаря активным действиям самой компании.

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

В марте 2005 г. Останкинский районный суд города Москва приговорил подозреваемых, в числе которых трое сотрудников компании «Вымпелком», к различным штрафам . Так, организатор группы оштрафован на 93 000 рублей. Однако работа сайта www.sherlok.ru была прекращена на неопределенный срок только с 1 января 2008 г.

Крупнейшая утечка персональных данных за всю историю Японии

Аннотация

Летом 2006 г. произошла самая крупная утечка персональных данных за всю историю Японии: сотрудник полиграфического и электронного гиганта Dai Nippon Printing украл диск с приватными сведениями почти девяти миллионов граждан.

Описание инцидента

Японская фирма Dai Nippon Printing, специализирующаяся на выпуске полиграфической продукции, допустила крупнейшую утечку в истории своей страны. Хирофуми Йокояма, бывший сотрудник одного из подрядчиков компании, скопировал на мобильный винчестер и украл персональные данные клиентов фирмы. В общей сложности под угрозу попали 8,64 млн человек, так как похищенная информация содержала имена, адреса, телефоны и номера кредитных карт. В похищенной информации содержались сведения о клиентах 43 различных компаний, например о 1 504 857 клиентах компании American Home Assurance, 581 293 клиентах компании Aeon Co и 439 222 клиентах NTT Finance .

После похищения данной информации Хирофуми открыл торговлю приватными сведениями порциями от 100 000 записей. Благодаря стабильному доходу инсайдер даже покинул постоянное место работы. К моменту задержания Хирофуми успел продать данные 150 000 клиентов крупнейших кредитных фирм группе мошенников, специализирующихся на онлайн-покупках. Кроме того, часть данных уже была использована для мошенничества с кредитными картами.

Более половины организаций, данные клиентов которых были похищены, даже не были предупреждены об утечке информации.

Последствия

В результате данного инцидента убытки граждан, которые пострадали из-за мошенничества с кредитными картами, ставшего возможным только вследствие этой утечки, составили несколько миллионов долларов. Всего пострадали клиенты 43 различных компаний, в том числе Toyota Motor Corp., American Home Assurance, Aeon Co и NTT Finance. Однако более половины организаций даже не были предупреждены об утечке.

В 2003 г. в Японии был принят закон Personal Information Protection Act 2003 (PIPA), но прокуратура не смогла его применить в реальном судебном разбирательстве по данному делу в начале 2007 г. Обвинение не смогло инкриминировать инсайдеру нарушение закона PIPA. Его обвиняют лишь в краже винчестера стоимостью 200 долларов.

Не оценили. Запорожский хакер против украинского банка

Аннотация

Бывший системный администратор одного из крупных банков Украины перевел через банк, в котором раньше работал, со счета региональной таможни на счет несуществующей днепропетровской фирмы-банкрота около 5 млн гривен.

Описание инцидента

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

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

Уволившись, бывший системный администратор решил вернуть у бывшего руководства интерес к своей персоне посредством использования несовершенства применяемой практически во всех банках Украины системы «Банк-Клиент» . План системного администратора состоял в том, что он решил разработать свою программу защиты и предложить ее банку, вернувшись на свое прежнее место работы. Реализация плана заключалась в проникновении в систему «Банк-Клиент» и внесении в нее минимальных изменений. Весь расчет был сделан на то, что в банке должны были обнаружить взлом системы.

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

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

Тогда системный администратор решил изменить свой план, внеся в него коррективы, которые бы не смогли остаться незамеченными. Он решил подделать платежное поручение и перевести по нему через компьютерную систему банка крупную сумму. С помощью ноутбука и мобильного телефона со встроенным модемом системный администратор около 30 раз проникал в компьютерную систему банка: просматривал документы, счета клиентов, движение денежных средств - в поисках подходящих клиентов. В качестве таких клиентов им были выбраны региональная таможня и днепропетровская фирма-банкрот .

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

В действительности системный администратор рассчитывал на то, что денежные средства не будут переведены, что факт взлома будет обнаружен до перевода средств, но на практике все оказалось по-другому и он стал преступником и его липовый перевод перерос в кражу.

Факт взлома и хищения денежных средств в особо крупных размерах были обнаружены только через несколько часов после перевода, когда работники банка позвонили на таможню - подтвердить перевод. Но там сообщили, что такую сумму никто не перечислял. Деньги в срочном порядке были возвращены назад в банк, а в прокуратуре Запорожской области заведено уголовное дело.

Последствия

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

В 2004 г. указом президента Украины была усилена уголовная ответственность за компьютерные преступления: штрафы от 600 до 1000 не облагаемых налогом минимумов, лишение свободы - от 3 до 6 лет. Однако бывший системный администратор совершил преступление до вступления в силу указа президента.

В начале 2005 г. состоялся суд над системным администратором. Его обвинили в совершении преступления по части 2 статьи 361 Уголовного кодекса Украины - незаконное вмешательство в работу компьютерных систем с нанесением вреда и по части 5 статьи 185 - кража, совершенная в особо крупных размерах. Но так как руководство банка отказалось от каких-либо претензий в его адрес, то статью за кражу с него сняли, а часть 2 статьи 361 поменяли на часть 1 - незаконное вмешательство в работу компьютерных систем.

Бесконтрольный трейдинг в банке Societe Generale

Аннотация

24 января 2008 г. Societe Generale объявил о потере 4,9 млрд евро из-за махинаций своего трейдера Жерома Кервьеля . Как показало внутреннее расследование, в течение нескольких лет трейдер открывал сверхлимитные позиции на фьючерсы на европейские фондовые индексы. Общая сумма открытых позиций составила 50 млрд евро.

Описание инцидента

С июля 2006 по сентябрь 2007 г. компьютерная система внутреннего контроля 75 раз (именно столько раз Жером Кервьель осуществлял несанкционированные операции либо его позиции превышали допустимый лимит) выдавала предупреждение о возможных нарушениях. Сотрудники отдела мониторинга рисков банка не осуществляли детальных проверок по этим предупреждениям .

Впервые экспериментировать с неавторизованным трейдингом Кервьель начал уже в 2005 г. Тогда он занял короткую позицию на акции Allianz, ожидая падения рынка. Вскоре рынок действительно упал (после террористических акций в Лондоне), так были заработаны первые 500 000 евро. О своих чувствах, которые он испытал от своего первого успеха, Кервьель впоследствии рассказал следствию: «Я уже знал, как закрыть мою позицию, и был горд за полученный результат, но вместе с тем и удивлен. Успех заставил меня продолжать, это было как снежный ком… В июле 2007 г. я предложил занять короткую позицию в расчете на падение рынка, но не встретил поддержки со стороны своего руководителя. Мой прогноз оправдался, и мы получили прибыль, на этот раз она была вполне легальной. Впоследствии я продолжал проводить такого рода операции на рынке либо с согласия начальства, либо при отсутствии его явного возражения… К 31 декабря 2007 г. моя прибыль достигла 1,4 млрд евро. В тот момент я не знал, как объявить об этом моему банку, так как это была очень большая, нигде не задекларированная сумма. Я был счастлив и горд, но не знал, как объяснить своему руководству поступление этих денег и не навлечь на себя подозрение в проведении несанкционированных сделок. Поэтому решил скрыть мою прибыль и провести противоположную фиктивную операцию…» .

В действительности в начале января того же года Жером Кервьель вновь вступил в игру с фьючерсными контрактами на три индекса Euro Stoxx 50, DAX и FTSE, помогавшими ему обыгрывать рынок в конце 2007 г. (правда, тогда он предпочитал занимать короткую позицию). По подсчетам, в его портфеле накануне 11 января было 707, 9 тыс. фьючерсов (каждый стоимостью по 42,4 тыс. евро) на Euro Stoxx 50, 93,3 тыс. фьючерсов (192,8 тыс. евро за 1 штуку) на DAX и 24,2 тыс. фьючерсов (82,7 тыс. евро за 1 контракт) на индекс FTSE. В целом спекулятивная позиция Кервьеля равнялась 50 млрд евро, т. е. была больше стоимости банка, в котором он работал .

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

Когда удалось выяснить астрономические размеры спекулятивной позиции, генеральный директор и председатель совета директоров Societe Generale Даниэль Бутон заявил о своем намерении закрыть открытую Кервьелем рискованную позицию . На это ушло два дня и привело к убыткам в 4,9 млрд евро.

Возможности инсайдера

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

В 2005 г. Кервьеля повысили. Он стал настоящим трейдером. В непосредственные обязанности молодого человека входили элементарные операции по минимизации рисков. Работая на рынке фьючерсных контрактов на европейские биржевые индексы, Жером Кервьель должен был следить за тем, как меняется инвестиционный портфель банка. А его основной задачей, как объяснил один из представителей Societe Generale, было сокращать риски, играя в противоположном направлении: «Грубо говоря, видя, что банк ставит на красное, он должен был ставить на черное». Как у всех младших трейдеров, у Кервьеля был лимит, превышать который он не мог, за этим следили его бывшие коллеги по бэк-офису. В Societe Generale существовало несколько уровней защиты, например трейдеры могли открывать позиции только со своего рабочего компьютера. Все данные об открытии позиций автоматически в реальном времени передавались в бэк-офис. Но, как говорится, лучший браконьер - бывший лесничий. И банк совершил непростительную ошибку, поставив бывшего лесничего в положение охотника. Жерому Кервьелю, имевшему за плечами почти пятилетнюю практику контроля за трейдерами, не составило большого труда обойти эту систему. Он знал чужие пароли, знал, когда в банке проходят проверки, хорошо разбирался в информационных технологиях .

Причины

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

Последствия

Его деятельность по итогам 2007 г. принесла банку около 2 млрд евро прибыли. Во всяком случае так говорит сам Кервьель, утверждая, что руководство банка наверняка знало, чем он занимается, но предпочитало закрывать глаза до тех пор, пока он был в прибыли .

Закрытие открытой Кервьелем рискованной позиции привело к убыткам в 4,9 млрд евро.

В мае 2008 г. Даниэль Бутон покинул пост генерального директора Societe Generale, на этой должности его сменил Фредерик Удеа . Год спустя он был вынужден уйти и с поста председателя совета директоров банка. Причиной ухода стала острая критика со стороны прессы: Бутона обвиняли в том, что подконтрольные ему топ-менеджеры банка поощряли рискованные финансовые операции, осуществляемые сотрудниками банка.

Несмотря на поддержку совета директоров, давление на господина Бутона усиливалось. Его отставки требовали акционеры банка и многие французские политики. Президент Франции Никола Саркози также призвал Даниэля Бутона уйти с поста, после того как стало известно, что в течение полутора лет до скандала компьютерная система внутреннего контроля Societe Generale 75 раз, т. е. всякий раз как Жером Кервьель осуществлял несанкционированные операции, выдавала предупреждение о возможных нарушениях .

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

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

Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей.

Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования.

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

Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что:

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

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

ITIL вводит также понятие Модель инцидентов, которая включает в себя:

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

Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих "стандартных" инцидентов. "Нестандартные" случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. В отдельную категорию выделяются "значительные инциденты", которые должны разрешаться максимально быстро. Значительный инцидент (Major Incident ) наивысшая категория влияния для инцидента. Значительный инцидент означает значительные потери для бизнеса. То, какие инциденты будут считаться значительными, каждая организация решает индивидуально.

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

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

Запись об инциденте должна включать:

• уникальный идентификатор инцидента;
• категорию инцидента;
• срочность инцидента. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета.
• влияние инцидента;
• приоритет инцидента;
• дата и время записи;
• Имя/ID человека или группы, сделавшей запись об инциденте;
• метод уведомления;
• имя/отдел/номер/расположение пользователя;
• метод обратной связи;
• описание симптомов;
• статус инцидента;
• связанные конфигурационные единицы;
• группа поддержки/сотрудник, к кому переадресован инцидент;
• связанная с инцидентом проблема/известная ошибка;
• деятельности, осуществленные для разрешения инцидента;
• время и дата разрешения инцидента;
• категория закрытия;
• время и дата закрытия.

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

Рис. 12.3.

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

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

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

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

В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить.

Таблица 12.1.

		Влияние
		Высокое	Среднее	Низкое
Срочность	Высокая	1	2	3
	Средняя	2	3	4
	Низкая	3	4	5

Таблица 12.2.

Приоритет	Характеристика	Время разрешения
1	Критичный	1 час
2	Высокий	8 часов
3	Средний	24 часа
4	Низкий	48 часов
5	Планируемый	Запланировать

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

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

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

Эскалация (Escalation) - деятельность , направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация.

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

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

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

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

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

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

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

Метриками эффективности процесса Управления инцидентами могут быть:

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

Для эффективного Управления инцидентами необходимо обеспечить следующее:

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

Основные риски для процесса Управления инцидентами:

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