Incident management (part 3)

Определите
требуемые
ресурсы

InfoSecurity 2008 © 2008 Cisco Systems, Inc. All rights reserved. 160/431

Определение ресурсов

 Определите требуемые для работы CSIRT ресурсы –
персонал, оборудование и инфраструктуру
 Как инфраструктура CSIRT будет защищаться и
мониториться?
 Определите процессы сбора, записи, трекинга и
архивирования информации
 Опишите должностные обязанности сотрудников
CSIRT
С указанием требуемых знаний и квалификации
 Создайте план обучения и повышения квалификации
 Определите необходимость аттестации персонала и
его сертификации

Состав CSIRT

 Лидер команды
 Технический персонал
Обработчик инцидентов
Аналитик уязвимостей
Аналитик артефактов
 «Первый реагент» ;-)
Сотрудник hotline, servicehelp desk
 Эксперты
Эксперты по ИБ, сетевые специалисты (частичная загрузка)
 Другой персонал


Квалификация членов CSIRT

 Базовые персональные навыки
Коммуникации – письменные, оральные
Умение читать презентации
Дипломатия
Умение следовать формальным процедурам/политикам
Работа в команде
Работа в условиях стресса
Решение проблем
Тайм-менеджмент


Квалификация членов CSIRT (окончание)

 Базовые технические навыки
Основы информационной безопасности
Знание Интернет
Знание сетевых протоколов, сервисов и приложений
Знание ОС, приложений
Понимание вредоносных программ и уязвимостей
Навыки программирования
 Навыки управления инцидентами
Понимание техник проникновения
Анализ инцидентов
Взаимодействие с третьими сторонами


Сколько человек надо?

 1 полностью загруженный «технический» сотрудник
CSIRT может отработать
1 новый «усредненный» инцидент в день и
20 открытых и расследуемых инцидентов
 Еще потребуются административный и
управленческий аппарат
 Учитывайте время работы одного человека в условиях
стресса
При режиме 24х7 вам понадобится не менее трех человек (24
/ 8). А резерв на время болезни? А разные часовые пояса?
 Учитывайте, что в разное время происходит разное
число инцидентов
Людей можно перевести на другой фронт работ

Сколько человек надо? (окончание)

 Только 2 сервиса – уведомления и обработка
инцидентов
Минимум 4 полностью загруженных сотрудников (31%)
 Все сервисы – в рабочее время
Минимум 6-8 полностью загруженных сотрудников (31%)
 Все сервисы – в режиме 24х7
Минимум 12 полностью загруженных сотрудников (21%)
С учетом резервирования на время праздников, отпусков и
болезни


Сколько инцидентов обычно бывает?

 Большинство CSIRT обрабатывает менее 10
инцидентов в день
38% CSIRT управляют 1-3 инцидентами в день
18% CSIRT управляют 4-8 инцидентами в день
18% CSIRT управляют более чем 15 инцидентами в день
10% CSIRT управляют около 50 инцидентами в год


Какое оборудование требуется?

 Телефон
 Автоответчик (IVR)
 Факс
 Шредер
 Сейф
 Резервные носители
 Информационная безопасность
 Service Desk (или корпоративный)
 Специализированное ПО и оборудование для
расследования


взаимодействия,
интерфейсы и
точки контакта


Взаимодействие

 Определите заранее все ключевые взаимодействия
и интерфейсы с ключевыми заказчиками,
заинтересованными сторонами
Уточните заранее контакты у вашего Интернет-провайдера,
ОВД, ФСБ (если необходимо)
Подпишитесь на списки рассылки производителей
«вашего» ПО и железа, а также на supporter’ов
Установите контакты с другими CSIRT (если они есть)
 Определите информационные потоки
 Определите методы взаимодействия и проверки
подлинности
 Определите формы документов, которыми вы
будете обмениваться

Взаимодействие (окончание)

 Для всех интерфейсов и видов взаимодействия
определите
Кто владелец передаваемых данных?
Кто имеет право передавать эти данные? Кто имеет право
контактировать с прессой и иными внешними сторонами?
Как распределяются данные?
Как защищаются, контролируются и хранятся данные?
Как контролируется доставка данных?


Взаимодействие с другими CSIRT


Определите роли
и ответственности


Роли и ответственность

 Определите роли и ответственность всех
участников CSIRT
 Определите интерфейсы и виды взаимодействия
между участниками/функциями CSIRT
 Определите процедуры эскалации конфликтов и
спорных ситуаций


Документируйте
сервисы/процессы
/функции CSIRT


Описание сервисов CSIRT
 Каждый сервис/процесс CSIRT должен быть описан и
это описание должно быть доступно всем
заинтересованным сторонам
 Для любого сервиса желательно иметь два описания
Для внешней аудитории – кому предоставляется сервис, как
делать запрос на оказание услуги, что ожидать от CSIRT
Для внутренней аудитории – повторение описания для
внешней аудитории, а также подробные рекомендации по
оказанию сервиса и описание управления сервиса
 Любой сервис должен описываться по двум
измерениям
Логическое
Техническое


Факторы описания сервисов CSIRT
Фактор Описание
Цель Цель сервиса
Определение Описание области применения сервиса
Функции Описание функций сервиса
Условия, при которых сервис доступен клиентам
Доступность
(кому, когда и как)
Гарантии качества Настройки и ограничения сервисов для клиентов
Взаимодействие между командами и
Взаимодействие и
заинтересованными сторонами, такими как клиенты,
раскрытие
другие команды или журналисты. Также включает
информации
стратегию раскрытия информации об инциденте
Интерфейс с
Информационные потоки между данным и другими
другими
сервисами CSIRT
сервисами
Описание приоритетов функций внутри сервиса и
Приоритет
сервиса относительно других сервисов

Цель сервиса

 Цель сервиса вытекает из миссии CSIRT, которая, в
свою очередь, вытекает из миссии отдела ИБ или
иной структуры, главенствующей над CSIRT
 Пример
Миссия CSIRT: Улучшение безопасности информационной
инфраструктуры предприятия и минимизация угрозы
нанесения ущерба вследствие вторжений и атак
Цель сервиса: Стать центром поддержки обработки
инцидентов для сетевых и системных администраторов и
пользователей предприятия
или
Обеспечение технической поддержки на месте в связи с
инцидентами, влияющими на системы предприятия, с
целью их изоляции и восстановления от вторжений и атак

Определение сервиса

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

 Сервис может быть ограничен
Целью
Ресурсами (финансовыми, человеческими, техническими)
Опытом и квалификацией персонала CSIRT
Полномочиями
Контактами с внешним миром
…


Функции

 У каждого сервиса CSIRT может быть свой набор
функций
 Например, для обработки инцидентов список
включает 4 основных функции
Систематизация
Обработка
Уведомление
Обратная связь
Данный сервис мы будем рассматривать далее более
детально


Функции (окончание)

 Данный раздел должен включать в себя
Цель функции
Детали реализации и ссылки на соответствующие
процедуры
Критерии приоритезации функций
Уровень оказываемых услуг
Критерии качества

 Детали реализации
Как срабатывает функция (снаружи или изнутри)? Какие
формы коммуникаций используются? Какие данные
необходимы для работы функции (вход и выход)?


Доступность

 Кто может получить доступ к сервису?
На каких условиях?

 В какое время доступен сервис?
Разные сервисы в разное время
Разные уровни сервиса в разное время
Разные типы/приоритеты инцидентов в разное время
Разные типы клиентов в разное время

 Условия предоставления сервиса
Заполненный по определенной форме отчет об инциденте
Обязательное прохождение процедуры проверки
подлинности клиента

Гарантии качества

 Каковы ожидания клиентов относительно качества
сервиса?
Для разных клиентов разное качество
Для разных функций разное качество
В разное время разное качество
Для разных приоритетов разное качество

 В течение какого времени CSIRT ответит на запрос
клиента?


Взаимодействие и раскрытие
информации

 Какое взаимодействие происходит между CSIRT и
участниками инцидента?
 Чего CSIRT ждет от пострадавшей стороны?
 Что будет с файлами, документами и материалами,
предоставленными пострадавшим CSIRT?
Будут ли они передаваться за пределы CSIRT?
Если да, то как они будут защищены?


Интерфейс с другими сервисами

 Какое взаимодействие происходит между одним
сервисом и другими?
Каковы критерии взаимодействия?

 Есть ли общие для всех сервисов?
Например, часто функция систематизации является единой
для всех сервисов?


Приоритет

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

InfoSecurity 2008
Квалификация злоумышленника / сложность атаки
© 2008 Cisco Systems, Inc. All rights reserved. 186/431

Критерии приоритезации


Критерии приоритезации (окончание)


Шкала воздействия (ущерба)


Приоритет инцидента

Источник: Университет Мельбурна

Матрица «Приоритет – Реагирование»

Источник: Университет Мельбурна


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


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

 Независимо от спектра предлагаемых сервисов
необходимо понимать как они связаны друг с
другом
 В частности необходимо определить
Какие сервисы зависят от информации других сервисов
или предоставляют информацию другим сервисам
Какие сервисы имеют общие источники информации или
являются общими для каких-либо функций CSIRT
Какие сервисы обрабатывают информацию, зависящую от
каких-либо условий (конфиденциальность,
законодательство)
Какие сервисы передают информацию за пределы CSIRT



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



 Разным запросам в рамках информационного
обмена могут быть присвоены разные приоритеты
В зависимости от автора запроса или иных критериев


Пример матрицы информационных
потоков для обработки инцидентов
Имя сервиса Входящий поток Исходящий поток
Уведомление Предупреждения о Статистика и отчеты о
текущих сценариях статусе, а также новые
атак профили атак для
исследований
Обработка Как защититься против Возможное
уязвимостей использования существование новых
определенных уязвимостей
уязвимостей?
Обработка артефактов Как распознать Статистика по
использование обнаруженным
определенных артефактам, а также
артефактов и какое примеры артефактов
влияние они могут
оказать?
Обучение / тренинги Знание, примеры из
практики, мотивация

Обнаружение Отчет о новом Новый профиль атак
вторжений инциденте
Аудит и оценка Уведомление о Общие сценарии атак
защищенности расписании начала и
окончания тестов на
проникновении
Консалтинг Информация об Практические
безопасности угрозах и величине примеры и опыт
потенциального
ущерба
Анализ рисков Информация об Статистика или
угрозах и величине сценарии или потери
потенциального
ущерба


Анализ технологий Предупреждение о Статистика или отчет
сценариях будущих о статусе, а также
атак или о новые профили атак
распространении для рассмотрения или
новых хакерских исследований
инструментов
Разработка средств Наличие новых Потребности в новых
защиты средств для продуктах, а также
использования анализ текущей
клиентами практики


Визуализация
процессов CSIRT


Визуализация процессов

 С целью облегчения внедрения процессов
управления инцидентами и эффективного их
применения на практике рекомендуется графически
визуализировать в виде диаграмм
последовательности выполняемых действий
(workflow diagram)
Это позволяет отобразить все процессы и подпроцессы, а
также связи между ними, входную и выходную
информацию, триггеры срабатывания, критерии перехода
из состояния в состояние, дополнительные требования,
роли и ответственность участников
 С диаграммами связаны описания выполняемых
действий (workflow descriptions), которые
разъясняют карты процессов


Визуализация процессов (продолжение)


Визуализация процессов в PWC


Визуализация процессов в
Университете Мельбурна


Другие примеры визуализации

Управление несанкционированной модификации Управление сканированием

Визуализация процессов (продолжение)


Визуализация процессов (окончание)

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


Разработайте
политики и
процедуры


Политики

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

Процедуры

 Детализация деятельности в пределах конкретной
политики («пошаговые инструкции, как это сделать»)
 Не существуют без политик
 Пример политики: «Будьте вежливы со СМИ; не врите
им; сообщайте только обезличенные сведения
общего характера»
За этой простой политикой скрывается достаточно подробная
процедура

 «Передаваемые данные должны быть зашифрованы
ГОСТ 28147-89» – это не политика
Технология может меняться. Правильнее - «Передаваемые
данные должны зашифрованы с помощью алгоритма,
обеспечивающего стойкость в течение 25 лет»

Атрибуты хорошей политики
Атрибут Описание
Поддержка и Как и миссия, политика не подлежит
одобрение исполнению, если она не поддержана
руководством руководством
Ясность Любой член целевой аудитории должен
понимать, о чем данная политика. Избегайте
жаргонизмов. Используйте короткие
предложения. Если допустимо, попросите
вашу жену прочитать политику. Если ей
непонятно, то замените ее (не жену ;-).
Краткость Хорошая политика – краткая политика.
Длинная политика либо плоха, либо включает
слишком много процедур, смешивая
управление (политика) с оперативной
деятельностью (процедуры).


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


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


Содержание политики (окончание)
Раздел Описание
Связи Определите связи с другими сервисами и
политиками
Поддержка Определите процедуру и ответственного за
пересмотр и поддержание политики
Термины, определения Определите все термины и сокращения,
и сокращения чтобы гарантировать, что новые члены CSIRT
понимают, о чем идет речь и общаются на
одном языке

 Хорошей практикой является сопровождение
политик примерами


Проверка политик

 Перед тем, как пускать политику в плавание,
проверьте ее плавучесть
Основная задача, что все тезисы политики применимы на
практике
 Люди, создающие политику, должны отличаться от
тех, кто ее проверяет
Исключите конфликты интересов и необъективность
 Проверьте согласованность политики с другими
политиками
 Запустите пилотный проект с худшими сценариями
и реальным поведением людей
Совет «всегда будьте дружелюбны с собеседниками» надо
проверить на очень агрессивных оппонентах

Поддержка политик

 Не бывает идеальных политик, созданных «раз и
навсегда»
Все течет, все меняется
В ряде случаев политики могут создавать уже после
начала работы CSIRT или ее отдельных сервисов
 Любые изменения в политиках должны быть
проверены перед их утверждением
 Необходимо регулярно проверять
«работоспособность» политик
 Необходимо иметь ответственного за поддержание
политики в актуальном состоянии


Какие политики должны быть?

 Термины и определения
 Политика классификации информации/инцидентов
Включая порядок категорирования, приоритезации и
эскалации инцидентов
 Политика входящих звонков
 Политика раскрытия информации
 Политика безопасности CSIRT
 Политика общения с прессой
 Политика общения со сложными контактами
 Политика координации с другими CSIRT


Какие политики должны быть?

 Политика общения с неидентифицированными
абонентами
Вам звонит атакуемый или атакующий?
 Политика управления уязвимостями
 Политика разработки уведомлений


Создайте план
внедрения


План внедрения

 Создайте план внедрения и разошлите его всем
заинтересованным сторонам для получения
обратной связи
 Выберите время для запуска CSIRT
Учитывайте время, в которое не стоит запускать CSIRT –
годовой отчет, квартальный отчет, запуск системы, аудит
со стороны регуляторов и т.п.
 Получите поддержку руководства на запуск CSIRT


Анонсируйте
CSIRT


Реклама CSIRT среди клиентов
 CSIRT определила своих клиентов, но знают ли
клиенты о CSIRT?
Кто в компании отвечает за реагирование на инциденты?
Кому писать или звонить в случае получения подозрительного
письма или сообщения от системы?
О чем сообщать и в какой форме?
Надо ли клиенту самому пытаться сделать что-то?
Можно ли позвонить другу из ИТ-департамента или службы
ИБ?
 Клиенты должны знать о существовании CSIRT, ее
задачах и полномочиях
Особенно если CSIRT является единой точкой контакта


Анонсирование

 Подготовьте формальное сообщение от имени
руководства о запуске CSIRT
 Подготовьте маркетинговые материалы,
руководства и процедуры, описывающие
Что такое CSIRT?
Как клиенты могут взаимодействовать с CSIRT?
Какие показатели качества используются?
 Включите раздел о CSIRT в корпоративную
программу обучения новых сотрудников
Создайте отдельный курс (ролик) для всех желающих
 Распространите информацию о CISRT


Как себя рекламировать?
 Электронная почта и списки рассылки
 Внутренний портал
 Презентации и семинары
 Скринсейверы, календари, ручки/карандаши, плакаты
в «людных» местах
 Телефония (массовые голосовые сообщения)
 Медиа (Digital Media Signage)


Отображение уровня угрозы
 Визуализация уровня угрозы облегчает понимание
неквалифицированных пользователей текущего
статуса в области безопасности организации


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


методы оценки
эффективности


Контроль качества

 Очевидно, что наличие каталога услуг, матрицы
информационных потоков, а также разработанных
политик и процедур недостаточно для того, чтобы
оказывать услуги CSIRT на качественном уровне
 Требуется контроль качества (quality assurance)
На практике он реализуется не часто ;-(
Стандартные формы – приоритезация инцидентов и
отсутствие жалоб со стороны руководства
 Определение показателей качества должно
начинаться «сверху вниз», от миссии
Которая может содержать такие качественные показатели,
как «своевременно», «гибко», «все возможные сценарии» и
т.л.


Контроль качества (окончание)

 Каждая услуга, политика, процедура,
информационный поток могут иметь свои
показатели качества
 Вспомните курс по измерению эффективности

Взаимодействие
• Скорость • Скорость
выпуска реагирования
способа • Скорость на первичный
закрытия оповещения о доклад об
уязвимости новой инциденте
уязвимости
Обработка Обработка
уязвимостей инцидентов


Примеры показателей качества
Для инцидента

 Время отклика на события из сферы действия
сервиса (инцидент, уязвимость)
 Приоритет события
 Уровень информации, предоставляемой для
событий (краткосрочная перспектива)
 Уровень информации, предоставляемой для
событий в долгосрочной перспективе (отчет,
резюме, анонс…)
 Уровень конфиденциальности
…


Примеры показателей качества
Для CSIRT

 Число инцидентов, открытых и закрытых
 Число «звонков о помощи»
Звонки, сообщений e-mail, сообщений через Web
 Среднее время реагирования на инцидент
Для разных приоритетов
 Распределение инцидентов по приоритетам
 Тренды
Рост/падение числа инцидентов по разным срезам


Значение показателей качества

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

Параметр качества Значение
Время реагирования на Для всех не критичных уязвимостей CSIRT
сообщение об уязвимости будет выпускать рекомендации в течение
двух дней с момента первичного сообщения
Время реагирования на Каждый высокоприоритетный инцидент
высокоприоритетый инцидент должен быть признан в течение 2-х часов.
Анализ начнется в течение первого часа
после получения сообщения об инциденте
Время реагирования на Каждый низкоприоритетный инцидент должен
низкоприоритетный инцидент быть признан в течение 4-х часов. Анализ
начнется в течение первых 48-и часов после
получения сообщения об инциденте

Динамичность показателей качества

 Система контроля качестве нестатична
Значения одного параметра могут влиять на значения других
(например, в кризис время отклика может быть гораздо
жестче, чем при обычном инциденте)
Значения параметров качества могут быть гибкими
(например, 95% всех неприоритетных инцидентов будут
обрабатываться в течение 5 дней)
При необходимости стоит уведомить об изменении значения
параметров качества заинтересованных лиц


Проверка показателей качества

 Система контроля качества также должна включать
проверку показателей
Это нетривиальная задача должна подразумевать набор
процедур и инструментов по измерению показателей
качества и генерацию соответствующих отчетов
 Что проще измерять и проверять количественные или
качественные показатели качества?
«Реагировать надо быстро» или «Реагировать надо в течение
2-х часов»?
 Частота проверки также требует проработки
Слишком редко – можно снизить качество работы CSIRT
Слишком часто – отнимает время у CSIRT и требует ресурсов


Проверка показателей качества (продолжение)

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

Проверка показателей качества (окончание)

 Не забудьте при изменении показателей качества
обновить и процедуры проверки
 Пример: проверка связи с клиентом, сообщившим об
инциденте
Первичный показатель качестве – «Ответ на сообщение
клиента об инциденте должен быть в течение 2-х часов с
момента получения сигнала»
Внедрена система автоматического ответа по e-mail и ответ
направляется сразу же
Показатель должен поменяться на «Автоматический ответ
отправляется сразу после получения сообщения об
инциденте. Личный ответ сотрудника CSIRT должен быть в
течение 24-х часов с момента получения сигнала»


Опубликование показателей качества

 Надо ли публиковать список показателей качества
перед клиентами?
Если они знают, как вас контролировать, то они могут на вас
давить!
Если они не знают, как вас контролировать, то они могут
думать, что вы что-то скрываете!
 Выберите часть показателей качества и опубликуйте
их
Это покажет вашу открытость
Не занимайтесь показухой
Помните, что клиенты не любят непонятных им слов и
терминов


Противовес

 Нужен баланс между процедурами, проверками и
необходимостью делать свое дело
 Что делать, если процедуры CSIRT не могут помочь
решить проблему или члены CSIRT выполняют свою
работу некачественно?
Нужна процедура эскалации, а также положение об
ответственности и наказании, которые являются
противовесом стандартным процедурам CSIRT
Штрафные санкции часто стимулируют работать хорошо без
всяких процедур
 Аналогичный противовес должен быть и в отношении
клиентов, которые не выполняют своих обязательств
Таких клиентов можно отключать от CSIRT или снижать
уровень их обслуживания

Пример: число звонков в Service Desk

 Задача: оценить время реагирования на звонок об
инциденте
 Поощрение за снижение времени реагирования
Сотрудники могут класть трубку сразу после звонка!

 Поощрение за число разрешенных инцидентов
Сотрудники будут самостоятельно пытаться закрыть
инцидент, не эскалируя его правильному специалисту
Увеличение длительности звонков и ожидания клиентов на
линии
Меньше доступных специалистов – ниже удовлетворенность

 Комбинируйте метрики
Время реагирования на звонок + длительность звонка

Incident Management Capability Metrics


Incident management (part 3)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Incident management (part 3) (20)

More from Aleksey Lukatskiy (17)

Incident management (part 3)