Incident management (part 3)

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

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


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

Определите требуемые для работы CSIRT ресурсы –персонал, оборудование и инфраструктуру

Как инфраструктура CSIRT будет защищаться и мониториться?

Определите процессы сбора, записи, трекинга и архивирования информации

Опишите должностные обязанности сотрудников CSIRT

С указанием требуемых знаний и квалификации

Создайте план обучения и повышения квалификации

Определите необходимость аттестации персонала и его сертификации


Состав CSIRT

Лидер команды

Технический персонал

Обработчик инцидентов

Аналитик уязвимостей

Аналитик артефактов

«Первый реагент» ;-)

Сотрудник hotline, service\help 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?

Если да, то как они будут защищены?


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

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

Каковы критерии взаимодействия?

Есть ли общие для всех сервисов?

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


Приоритет

Приоритезация очень важна в условиях нехватки ресурсов

Важен не только приоритет событий, но и приоритет функций внутри сервиса, а также сервисов между собой

Приоритезация возможна по различным критериям

Тип атакуемого ресурса

Критичность для бизнеса

Количество атакуемых систем

Тип атаки/инцидента

Тип цели атаки

Квалификация злоумышленника / сложность атаки


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


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


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


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

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


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

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


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



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

В частности необходимо определить

Какие сервисы зависят от информации других сервисов или предоставляют информацию другим сервисам

Какие сервисы имеют общие источники информации или являются общими для каких-либо функций 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 уровень

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

2 уровень

Начинается вторжение (или неминуемо начнется), которое может привести к простоям, росту задержек в обслуживании или перебоев в сетевом взаимодействии

3 уровень

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

4 уровень

Вторжение серьезно влияет на инфраструктуру и ключевые бизнес-приложения


Определите методы оценки эффективности


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

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

Self Improvement

Transcript of Incident management (part 3)