Руководство по обработке инцидентов компьютерной безопасности (NIST SP 800-61 R2)

Руководство по обработке инцидентов компьютерной безопасности.

(Ключевые моменты)

 NIST Special Publication 800-61 Revision 2. Computer Security Incident Handling Guide

1. Введение.

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

2.1. События и инциденты.

2.2. Необходимость реагирования на инциденты.

2.3. Разработка Политики, Плана, Процедур реагирования на инциденты.

2.3.1. Элементы политики.

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

  • Заявление о поддержке со стороны руководства.
  • Цель и задачи политики.
  • Область действия политики (к кому и для чего она применяется и при каких обстоятельствах).
  • Термины и определения (например, что такое инцидент компьютерной безопасности).
  • Организационная структура и определение ролей, распределение обязанностей и уровней полномочий; должны включать:

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

o   требования к отчетности для определенных типов инцидентов,

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

o   условия эскалации процесса управления инцидентами.

  • Приоритезация и оценка степени серьезности инцидентов.
  • Показатели деятельности (в разделе 3.4.2).
  • Отчетность и контактные формы.

2.3.2. Элементы плана.

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

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

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

 

2.3.2. Элементы процедуры.

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

 

2.3.4. Взаимодействие с внешними сторонами.

Внешними сторонами, с которыми может возникнуть необходимость взаимодействия, могут быть:

  • Средства массовой информации.
  • Интернет сервис провайдер.
  • Надзорные органы.
  • Компании-поставщики ПО и услуг.
  • Пользователи.
  • и др.

 

2.3.4.1. Средства массовой информации.

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

Следующие действия рекомендуются для подготовки ответственного за взаимодействие со СМИ лица:

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

o   Кто вас атаковал? Почему?

o   Когда это случилось? Как это произошло? Произошло ли это потому, что у вас слабая система информационной безопасности?

o   Насколько серьезен этот инцидент? Какие шаги вы предпринимаете, чтобы определить, что произошло, и, чтобы предотвратить повтор инцидента в будущем?

o   Каково влияние этого инцидента? Произошла ли утечка персональных данных? Какова ориентировочная стоимость этого инцидента?

 

2.4. Структура команды реагирования на инциденты.

2.4.1. Модель команд.

Возможны следующие структуры организации команды реагирования на инциденты

  • Централизованная. Одна команда обрабатывает инциденты во всей организации.
  • Децентрализованная (распределенная). В организации есть различные команды реагирования на инциденты, ответственные за отдельный логический или физический сегмент организации.
  • Координационная. Команда, которая предоставляет помощь и советы другим командам реагирования на инциденты (например, CSIRT).

При создании команды реагирования на инциденты могут использоваться три модели найма:

  • Собственная команда, состоящая из сотрудников организации.
  • Частично отданная на аутсорсинг команда.
  • Полностью отданная на аутсорсинг.

 

2.4.2. Выбор модели команды.

При выборе модели команды, необходимо учесть следующие факторы:

  • Необходимость доступности 24/7.
  • Полностью или частичная занятость членов команды.
  • Мораль сотрудников.
  • Стоимость.
  • Компетенции сотрудников.

При рассмотрении аутсорсинга, необходимо учитывать следующие вопросы:

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

 

2.4.3. Персонал, участвующий в реагировании на инциденты.

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

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

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

 

2.4.4. Зависимости в пределах организации.

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

  • Менеджмент.
  • Подразделение информационной безопасности.
  • IT подразделение.
  • Юридический отдел.
  • Служба по взаимодействию с общественностью.
  • Отдел кадров.
  • Управлению непрерывностью бизнеса.
  • Подразделения физической и объектовой безопасности.

 

2.5. Сервисы, предоставляемые командой реагирования на инциденты.

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

  • Обнаружение вторжений.
  • Распространение рекомендаций.
  • Обучение и повышение осведомленности.
  • Обмен информацией.

 

2.6. Рекомендации

Ниже представлены перечень ключевых рекомендаций, по созданию возможности организации реагировать на инциденты:

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

 

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

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

Жизненный цикл реагирования на инциденты представлен на рисунке ниже:

IRLS

3.1. Подготовка.

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

 

3.1.1. Подготовка к обработке инцидентов.

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

 

Коммуникации членов команды реагирования на инциденты:

  • Контактная информация для членов команды и других внутри и за пределами организации.
  • Информация по эскалации инцидентов.
  • Механизм отчетности по инциденту, (например, номера телефонов, адреса электронной почты, онлайн-формы, и системы мгновенного обмена сообщениями, которые пользователи могут использовать для сообщения о предполагаемых инцидентах; по крайней мере, один механизм должен позволять людям сообщать о таких случаях анонимно).
  • Система управления проблемами для отслеживания информацию об инцидентах, их статусе и т.д.
  • Смартфоны, на членов команды для связи, как в рабочее, так и нерабочее время.
  • Программное обеспечение (ПО) шифрования, которое будет использоваться для связи между членами группы, в рамках организации так и с внешними сторонами (с соблюдением требований регуляторов, предъявляемых к средствам шифрования).
  • Специальная комната для управления и координации (War room).
  • Защищенные хранилища для обеспечения сохранности доказательств и других чувствительных материалов.

Оборудование и ПО для анализа инцидентов:

  • Специальная рабочая станция для проведения криминалистических процедур при расследовании инцидентов и/или устройства резервного копирования для создания образов дисков, сохраняющие файлы журналов, и сохранить другие соответствующие данные об инцидентах.
  • Ноутбуки для таких мероприятий, как анализ данных, снифинг пакетов и написание отчетов.
  • Запасные рабочие станции, серверы и сетевое оборудование, или виртуальные эквиваленты, которые могут быть использованы для различных целей, таких как восстановление резервных копий.
  • Чистые съемные носители.
  • Портативный принтер для печати копий файлов журналов и других доказательств из систем недоступных из сети.
  • Анализаторы пакетов и анализаторы протоколов для сбора и анализа сетевого трафика.
  • Криминалистическое ПО для анализа образов дисков.
  • Съемные носители с авторизованными версиями программ, которые будут использоваться для сбора доказательств из систем.
  • Другие средства для сбора доказательств, такие как, ноутбуки, цифровые камеры, диктофоны, формы для сбора свидетельств, пакеты для хранения доказательств, стикеры, и др.

Ресурсы для анализа инцидентов:

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

ПО для восстановления после инцидента:

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

 

3.1.2. Предотвращение инцидентов.

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

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

 

3.2. Обнаружение и анализ.

3.2.1. Векторы атаки.

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

  • Внешние/переносные устройства и носители информации.
  • Снижение производительности системы.
  • Веб-приложения.
  • Электронная почта.
  • Олицетворение (Impersonation): атаки с подменой чего-то доброкачественной чем-то вредоносным (например, спуфинг, атака человек по середине, SQL инъекция – это атаки связанные с олицетворением).
  • Недопустимое использование.
  • Потеря или кража оборудования
  • и др.

 

3.2.2. Признаки инцидента.

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

Примеры предшественников:

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

Примеры индикаторов:

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

 

3.2.3. Источники предшественников и индикаторов.

Сообщения, получаемые от:

  • Системы обнаружения/предотвращения вторжений.
  • Системы управления событиями безопасности.
  • Системы защиты от вредоносного ПО и антиспам-системы.
  • ПО для проверки целостности файлов.
  • Сервисов мониторинга от третьих сторон.

Журналы регистрации событий:

  • Операционных систем и приложений
  • Сетевого оборудования

Публично доступная информация о новых уязвимостях и эксплойтах.

Люди:

  • Сотрудники организации
  • Внешние стороны

 

3.2.4. Анализ инцидента

Ниже приведены рекомендации делающие процесс анализа инцидента проще и эффективнее:

  • Профилируйте сети и системы.
  • Создайте политику хранения журналов регистрации событий (дополнительно см. NIST SP 800-92, Guide to Computer Security Log Management).
  • Выполняйте корреляцию событий.
  • Поддерживайте синхронизацию времени в системах.
  • Поддерживайте в актуальности и используйте информационную базу знаний, которая может понадобиться команде реагирования на инциденты.
  • Используйте для исследования поисковые системы в Интернет.
  • Используйте сниферы для сбора дополнительных данных.
  • Фильтруйте данные.
  • Обращайтесь за помощью к экспертам.

 

3.2.5. Документирование инцидента.

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

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

 

3.2.6. Приоритезация инцидента

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

Функциональное воздействие инцидента (Уровень – Описание)

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

Информационное воздействие инцидента (Категория – Описание)

  • Нет воздействия — Никакая информация не была, изменена, удалена или скомпрометирована.
  • Компрометация персональных данных – Персональные данные клиентов, сотрудников, бенефициаров и т.д. были скомпрометированы.
  • Нарушение конфиденциальности – Бала нарушена конфиденциальность чувствительной для организации информации (например, информации о системе защиты критической информационной инфраструктуры).
  • Потеря целостности — Чувствительная или конфиденциальная информации, была изменена или удалена.

Возможность восстановления после инцидента (Категория – Описание)

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

 

3.2.6. Уведомление об инциденте.

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

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

  • ИТ директор.
  • Директор по безопасности.
  • Другие команды реагирования на инциденты в пределах организации.
  • Внешние команды реагирования на инциденты (в случае применимости).
  • Владелец системы.
  • Отдел кадров.
  • Представитель по связям с общественностью.
  • Юристы.
  • Правоохранительные органы (в случае применимости).

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

  • Электронная почта.
  • Веб-сайт (внутренний, внешний, портал).
  • Телефонный звонок.
  • Личная встреча.
  • Голосовая почта.
  • Письменно (на бумажном носителе).

 

3.3. Сдерживание, устранение и восстановление.

3.3.1. Выбор стратегии сдерживания.

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

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

 

3.3.2. Сбор и обработка доказательств.

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

  • Идентификационная информация (например, расположение, серийный номер, номер модели, имя хоста, MAC-адрес и IP-адрес компьютера).
  • ФИО, должность и номер телефона каждого человека, который собирал доказательства или работал с ними в ходе расследования.
  • Время и дата (включая часовой пояс) каждого события связанного с доказательством.
  • Место хранения доказательств.

Дополнительнуюинформациюможнонайтив NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response.

 

3.3.3. Идентификация атакующего.

Ниже описаны наиболее часто выполняемые действия для определения атакующего:

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

 

3.3.4 Устранение и восстановление.

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

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

 

3.4. Деятельность после инцидента.

3.4.1. Полученные уроки.

Вопросы, которые можно обсудить при подведении итогов по инциденту:

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

 

3.4.2. Использование собранных по инцидентам данных.

Возможные метрики, которые необходимо отслеживать:

  • Число обработанных инцидентов.
  • Время, затраченное на обработку единичного инцидента.
  • Оценка эффективности обработки каждого инцидента (объективная).
  • Субъективная оценка каждого инцидента (например, мнение членов команды реагирования на инциденты).

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

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

 

3.5. Чек-лист обработки инцидента.

Обнаружение и анализ:

1. Определить, произошел ли инцидент.

1.1. Провести анализ предшественников и индикаторов.

1.2. Провести поиск информации для корреляции.

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

1.4. Как только обработчик убедиться в наличии инцидента — начать документировать расследование и сбор доказательств.

2. Приоритезировать инцидент.

3. Сообщить об инциденте соответствующим внутренним и внешним сторонам.

Сдерживание, устранение и восстановление:

4. Приобретать, сохранять, защищать и документировать доказательства.

5. Локализовать инцидент.

6. Устранить инцидент.

6.1. Обнаружить и устранить все уязвимости, которые были использованы.

6.2. Удалить вредоносное ПО, и другие нежелательные материалы и компоненты.

6.3. В случае обнаружения других пострадавших систем (хостов), повторить шаги обнаружения и анализа (1.1, 1.2), чтобы выявить других пострадавших, затем проведите для них локализацию (5) и устранение (6) инцидента.

7. Восстановление после инцидента.

7.1. Вернуть системы в состояние готовности к функционированию.

7.2. Убедиться, что системы функционируют должным образом.

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

Деятельность после инцидента:

8. Сделайте отчет по инциденту.

9. Проведите встречу для извлечения полезных уроков (для крупных инцидентов — обязательно, для других — опционально).