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

Меры по устранению внезапных сбоев и предотвращению их повторения в будущем

Инцидент — это событие, которое может привести к потере или нарушению деятельности, услуг или функций организации. Управление инцидентами ( IcM ) — это термин, описывающий действия организации по выявлению, анализу и устранению опасностей для предотвращения их повторного возникновения в будущем. Эти инциденты в структурированной организации обычно решаются либо группой реагирования на инциденты (IRT), либо группой управления инцидентами (IMT), либо системой управления инцидентами (ICS). Без эффективного управления инцидентами инцидент может нарушить бизнес-операции, информационную безопасность , ИТ-системы, сотрудников, клиентов или другие жизненно важные бизнес-функции. [1]

Описание

Инцидент — это событие, которое может привести к потере или нарушению деятельности, услуг или функций организации. [2] Управление инцидентами (IcM) — это термин, описывающий действия организации по выявлению, анализу и устранению опасностей для предотвращения их повторного возникновения в будущем. Если инцидент не управляется, он может перерасти в чрезвычайную ситуацию, кризис или катастрофу. Таким образом, управление инцидентами — это процесс ограничения потенциального нарушения, вызванного таким событием, с последующим возвратом к обычному режиму работы. Без эффективного управления инцидентами инцидент может нарушить работу бизнеса, информационную безопасность, ИТ-системы, сотрудников, клиентов или другие жизненно важные бизнес-функции. [1]

Физическое управление инцидентами

Национальная ассоциация противопожарной защиты утверждает, что управление инцидентами можно описать следующим образом: «Система управления инцидентами (IMS) — это «комбинация объектов, оборудования, персонала, процедур и коммуникаций, работающих в рамках общей организационной структуры, предназначенная для помощи в управлении ресурсами во время инцидентов». [3] [4]

Физическое управление инцидентами — это реагирование в режиме реального времени, которое может длиться часами, днями или дольше. Кабинет министров Соединенного Королевства разработал Национальное руководство по восстановлению (NRG), которое предназначено для местных спасателей в рамках реализации Закона о гражданских чрезвычайных ситуациях 2004 года (CCA). Оно описывает реагирование следующим образом: «Реагирование охватывает действия, предпринимаемые для устранения непосредственных последствий чрезвычайной ситуации. Во многих сценариях оно, скорее всего, будет относительно коротким и продлится несколько часов или дней — поэтому быстрое внедрение мер по сотрудничеству, координации и коммуникации имеет жизненно важное значение. Реагирование охватывает усилия по устранению не только прямых последствий самой чрезвычайной ситуации (например, тушение пожаров, спасение людей), но и косвенных последствий (например, нарушение, интерес СМИ)». [5] [6]

Международная организация по стандартизации (ИСО), которая является крупнейшим в мире разработчиком международных стандартов, также подчеркивает в описании своего документа по управлению рисками, принципам и рекомендациям ISO 31000 :2009, что «Использование ISO 31000 может помочь организациям повысить вероятность достижения целей, улучшить выявление возможностей и угроз, а также эффективно распределять и использовать ресурсы для обработки рисков». [7] Это еще раз показывает важность не только хорошего планирования, но и эффективного распределения ресурсов для обработки рисков.

Управление инцидентами компьютерной безопасности

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

В настоящее время более половины попыток взлома транснациональных корпораций (ТНК) в мире происходят в Северной Америке (57%). 23% попыток происходят в Европе. [8] Наличие хорошо оснащенной команды реагирования на инциденты компьютерной безопасности является неотъемлемой частью обеспечения безопасной среды для любой организации и становится важнейшей частью общей структуры многих современных сетевых команд.

Роли

Инциденты в структурированной организации обычно решаются либо группой реагирования на инциденты (IRT), либо группой управления инцидентами (IMT). Они часто назначаются заранее или во время события и берут на себя управление организацией, пока инцидент решается, для восстановления нормальных функций. Командир инцидента управляет реагированием на инцидент безопасности и руководит членами группы(-ями) реагирования на инциденты через процесс, как определено Системой управления инцидентами (ICS). [9]

Обычно, как часть более широкого процесса управления в частных организациях, управление инцидентами сопровождается пост-инцидентным анализом, где определяется, почему инцидент произошел, несмотря на меры предосторожности и контроль. Этот анализ обычно контролируется руководителями организации с целью предотвращения повторения инцидента посредством мер предосторожности и часто изменений в политике. Затем эта информация используется в качестве обратной связи для дальнейшей разработки политики безопасности и/или ее практической реализации. В Соединенных Штатах Национальная система управления инцидентами , разработанная Министерством внутренней безопасности , объединяет эффективные практики управления чрезвычайными ситуациями в комплексную национальную структуру. Это часто приводит к более высокому уровню планирования на случай непредвиденных обстоятельств, учений и обучения, а также оценки управления инцидентом. [10]

Анализ первопричин

Человеческий фактор

В ходе анализа первопричины следует оценить человеческий фактор. Джеймс Ризон провел исследование, посвященное пониманию неблагоприятных последствий человеческого фактора. [11] Исследование показало, что расследования крупных инцидентов, таких как Piper Alpha и Kings Cross Underground Fire , ясно показали, что причины аварий были широко распространены как внутри организации, так и за ее пределами. Существует два типа событий: активный отказ — действие, которое имеет немедленные последствия и может привести к аварии, — и скрытое или отложенное действие — события могут занять годы, чтобы оказать влияние, и обычно сочетаются с инициирующими событиями, которые затем вызывают аварию.

Скрытые сбои возникают в результате решений, принятых на высших уровнях организации. Их разрушительные последствия могут оставаться неявными в течение длительного времени, становясь очевидными только тогда, когда они объединяются с локальными факторами-триггерами (например, весенним приливом , трудностями погрузки в порту Зебрюгге и т. д.), чтобы нарушить защиту системы. Решения, принятые на высших уровнях организации, могут спровоцировать события, которые сделают аварию более вероятной; планирование, составление графиков, прогнозирование, проектирование, разработка политики и т. д. могут иметь медленное воздействие. Фактическое небезопасное действие, которое вызывает аварию, можно отследить по всей организации, и последующие сбои могут быть выявлены, показывая накопление скрытых сбоев в системе в целом, что привело к тому, что авария стала более вероятной и в конечном итоге произошла. Можно применить более эффективные действия по улучшению и снизить вероятность повторения события. [12]

Реализация, специфичная для конкретных областей

Управление ИТ-услугами

Управление инцидентами является важной частью области процесса управления ИТ-услугами (ITSM). [13] Первой целью процесса управления инцидентами является восстановление нормальной работы сервиса как можно быстрее и минимизация влияния на бизнес-операции, тем самым гарантируя поддержание наилучших возможных уровней качества и доступности сервиса. «Нормальная работа сервиса» определяется здесь как работа сервиса в рамках соглашения об уровне обслуживания (SLA). Это одна область процесса в более широкой среде ITIL и ISO 20000 .

ISO 20000 определяет цель управления инцидентами (часть 1, 8.2) как: восстановить согласованное обслуживание бизнеса как можно скорее или ответить на запросы на обслуживание. [14]

ITIL 2011 определяет инцидент как:

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

Процесс управления инцидентами ITIL гарантирует, что нормальная работа сервиса будет восстановлена ​​как можно быстрее, а влияние на бизнес будет сведено к минимуму. ITIL Service Operation . AXELOS. 30 мая 2007 г. ISBN 978-0113310463.

Основными трудностями и причинами проблем при управлении инцидентами являются:

  1. Постоянно растущий уровень шума оповещений и событий
  2. Сложный и длительный процесс решения ИТ-проблем
  3. Неспособность эффективно прогнозировать и предотвращать ухудшение или сбои в работе ИТ-сервисов [16]

Смотрите также

Ссылки

  1. ^ ab "Что квалифицируется как 'инцидент'?". Business Link . Архивировано из оригинала 2011-06-15 . Получено 2018-01-04 .
  2. ^ "Словарь терминов управления непрерывностью бизнеса" (PDF) . Институт непрерывности бизнеса . Архивировано из оригинала (PDF) 2015-04-30 . Получено 2015-09-03 .
  3. ^ "Список кодексов и стандартов NFPA". Национальная ассоциация противопожарной защиты . 2013. Получено 10 апреля 2013 г.
  4. ^ "Управление инцидентами". Ready.gov . 2012. Архивировано из оригинала 12 апреля 2013 года . Получено 10 апреля 2013 года .
  5. ^ "Национальное руководство по восстановлению". GOV.UK. 2007. Получено 10 апреля 2013 г.
  6. ^ "Закон о гражданских обстоятельствах 2004 года". laws.gov.uk . 2012 . Получено 10 апреля 2013 .
  7. ^ "ISO 31000 Управление рисками". Международная организация по стандартизации . 2009. Получено 13 апреля 2013 г.
  8. ^ "Hacking Incidents 2009 – Interesting Data". Блог Roger's Security . Блоги TechNet. 12 марта 2010 г. Архивировано из оригинала 24 сентября 2012 г. Получено 17 ноября 2012 г.
  9. ^ FEMA. "Система управления инцидентами" (PDF) . Получено 2024-01-30 .
  10. ^ "О подразделении планирования действий в чрезвычайных ситуациях и управления инцидентами". Homeland Security . Архивировано из оригинала 2 апреля 2012 года . Получено 2012-11-17 .
  11. ^ Reason J (июнь 1995 г.). «Понимание неблагоприятных событий: человеческий фактор». Качество в здравоохранении . 4 (2): 80– 9. doi :10.1136/qshc.4.2.80. PMC 1055294. PMID  10151618 . 
  12. ^ О'Каллаган, Кэтрин Мэри, Управление инцидентами: человеческий фактор и минимизация среднего времени восстановления. Архивировано 17 сентября 2011 г. в Wayback Machine , докторская диссертация, Австралийский католический университет, 2010 г.
  13. ^ «Управление инцидентами теперь стало необходимостью для предприятия».
  14. ^ "Приложение BPM-D". Gov.UK Digital Marketplace .
  15. ^ ITIL Service Operation . Великобритания: The Stationery Office. 2011. ISBN 9780113313075.
  16. ^ «Почему автоматическое обогащение контекста для управления оповещениями и инцидентами имеет решающее значение для операций?». 3 декабря 2019 г.
  • Национальный консорциум системы управления инцидентами в США
  • Законодательство правительства Соединенного Королевства, Закон о гражданских непредвиденных обстоятельствах (CCA) 2004 г. (2012 г.)
  • Федеральное агентство по чрезвычайным ситуациям (FEMA). (2012)

Дальнейшее чтение

  • Адам Круг (16.09.2014), «Исследования практических примеров систем программного обеспечения для управления инцидентами», Исследования практических примеров 1–34
  • Уэрн С.Х. и Уайт-Хант К. (2010), Управление срочными и неожиданными ситуациями, Gower Publishing – Практические примеры

Библиография

  • Брутон, Ноэль, Как управлять службой ИТ-поддержки — Руководство для менеджеров служб поддержки пользователей и колл-центров . ISBN 0-7506-4901-1 . 
Retrieved from "https://en.wikipedia.org/w/index.php?title=Incident_management&oldid=1259670840"