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

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

срочность инцидента : приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.

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

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

Рис. 4.2. Определение степени воздействия, срочности и приоритета

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

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

Таблица 4.1. Пример системы кодирования приоритетов

Эскалация

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

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

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

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

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

Первая, вторая и n-линия поддержки

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

Рис. 4.3. Эскалация инцидента (источник: OGC)

4.2. Цель

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

4.2.1. Преимущества использования процесса

Для бизнеса в целом:

Своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;

Повышение производительности работы пользователей;

Независимый, ориентированный на потребности заказчика мониторинг инцидентов;

Доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

Для ИТ-организации:

Улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);

Эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

Эффективное использование персонала;

Предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;

Повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI);

Повышение удовлетворенности пользователей и заказчиков.

Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:

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

Пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;

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

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

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

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

4.3. Процесс

На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.

Рис. 4.4. Положение Процесса Управления Инцидентами

4.3.1. Входы процесса

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

4.3.2. Управление конфигурациями

Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB.

4.3.3. Управление Проблемами

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

4.3.4. Управление Изменениями

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

4.3.5. Управление Уровнем Услуг

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

4.3.6. Управление Доступностью

Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает» . Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.

4.3.7. Управление мощностями

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

Ни рис. 4.5. показаны этапы процесса:

Рис. 4.5. Процесс Управления Инцидентами

Прием и регистрация инцидента (Acceptance and Recording) – принимается сообщение и создается запись об инциденте.

Классификация и начальная поддержка (Classification and Initial Support) – присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.

Если вызов касается Запроса на Обслуживание (Service Request) , то инициируется соответствующая процедура.

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

Расследование и диагностика (Investigation and Diagnosis) – при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.

Решение и восстановление (Resolution and Recovery) – если решение найдено, то работа может быть восстановлена.

Закрытие (Closure) – с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.

Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.

4.4. Виды деятельности

4.4.1. Прием и регистрация

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

Трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

Мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;

Зарегистрированные инциденты помогают при диагностике новых инцидентов;

Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;

Легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;

Без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);

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

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

Обнаружен пользователем : он докладывает об инциденте в Службу Service Desk.

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

Обнаружен сотрудником Службы Service Desk : сотрудник производит регистрацию инцидента.

Обнаружен кем-либо в другом подразделении ИТ : этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.

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

Если есть (и они касаются того же инцидента) , информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.

Если нет (отличается от открытого инцидента) , производится регистрация нового инцидента.

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

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

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

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

Запись дополнительной информации об инциденте : добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).

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

4.4.2. Классификация

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

Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.

Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.

Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.

Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.

Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).

Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет

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

Приоритет = Срочность х Степень воздействия.

Услуги (сервисы)

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

Группа поддержки

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

Сроки решения

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

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

Запланирован;

Назначен;

Активный;

Отложен;

Разрешен;

4.4.3. Привязка (сопоставление)

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

4.4.4. Расследование и диагностика

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

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

4.4.5. Решение и восстановление

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

4.4.6. Закрытие

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

4.4.7. Мониторинг хода решения и отслеживание

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

4.5. Контроль процесса

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

Руководителю Процесса Управления Инцидентами отчет необходим для :

Идентификации недостающих звеньев процесса;

Идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);

Отслеживания хода выполнения процесса;

Определения тенденций развития.

Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:

Прогресс в решении инцидентов;

Время разрешения инцидентов в различных группах поддержки.

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

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

Число обнаруженных и зарегистрированных инцидентов;

Число разрешенных инцидентов, с разделением по времени разрешения;

Статус и число неразрешенных инцидентов;

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

4.5.1. Критические факторы успеха

Для успешного Управления Инцидентами необходимо следующее:

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

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

Общее количество инцидентов;

Среднее время разрешения инцидентов;

Среднее время разрешения инцидентов по приоритетам;

Среднее число инцидентов, разрешенных в рамках соглашений (SLA);

Процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

Средняя стоимость поддержки на инцидент;

Число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

Инциденты, решенные без посещения пользователя (удаленно);

Число (или процент) инцидентов с первоначально некорректной классификацией;

Число (или процент) инцидентов, неправильно распределенных в группы поддержки.

4.5.3. Функции и роли

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

Руководитель Процесса Управления Инцидентами

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

Мониторинг эффективности и рациональности работы процесса;

Контроль работы групп поддержки;

Развитие и сопровождение системы Управления Инцидентами.

Персонал групп поддержки

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

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

4.6. Затраты и проблемы

4.6.1. Затраты

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

4.6.2. Проблемы

При внедрении Управления Инцидентами могут возникнуть следующие проблемы:

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

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

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

Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.

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

Примечания:

Под «цепочкой» понимается цепь создания прибавочной стоимости. – Прим. ред.

В литературе по ITIL понятие «функция» ассоциировано с вертикальным (линейным) подразделением организации, выполняющим соответствующие функциональные обязанности и фактически является его синонимом. – Прим. ред.

Service Request.

Request for Change (RFC).

Configuration Item (CI).

Key Performance Indicators – KPI.

Performance Indicators.

Effectiveness and Efficiency.

Т.е. программного обеспечения. – Прим. ред.

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

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

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

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

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

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

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

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

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

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

Действует Редакция от 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.

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

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

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

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

Муж и жена.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот и все!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11 октября 2012 в 10:58

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

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

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

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

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

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

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. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.