Обработка инцидентов информационной безопасности (Часть 3)

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

Стратегия противодействия распространению последствий инцидента

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

§ потенциальное возможное повреждение или кража актива

§ потребность в сохранности свидетельств инцидента

§ доступность актива

§ количество времени и необходимые ресурсы для реализации противодействия

§ эффективность стратегии противодействия (частичное или полное решение проблемы)

§ срок действия стратегии (неделя, месяц, квартал, и.т.д.)

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

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

Сбор свидетельств инцидента и их обработка

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

§ идентификация источника (местоположение, ID, имя хоста, MAC – address, IP – address, и.т.д.)

§ персональные данные сотрудников, обращавшихся за помощью

§ дата и время каждого свидетельства

§ местоположение ресурса хранения свидетельства

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

Идентификация нарушителя

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

Процедура ликвидации последствий инцидента информационной безопасности

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

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

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

Хранение материалов расследования инцидентов информационной безопасности

Типичными метриками для хранения данных инцидента являются:

§ количество обработанных инцидентов информационной безопасности

§ среднее время, затрачиваемое на обработку одного инцидента

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

§ субъективная оценка инцидента – качественная оценка действий команды реагирования, включая практическое применение политики расследования инцидентов, использование инструментария и ресурсов, использование внутренней документации, качество обучения на этапе подготовки

Правила хранения материалов расследования инцидента информационной безопасности

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

§ возможные разбирательства в суде

§ время хранения свидетельств

§ стоимость хранения (стоимость эксплуатации носителей и систем)

Контрольные листы мероприятий при проведении расследования инцидента информационной безопасности

В процессе расследования инцидента, хорошей практикой является ведение контрольных листов наблюдений (check lists), с целью управления процессом расследования. Данная практика хорошо применима в средних и крупных организациях, где количество одновременно расследуемых инцидентов может превышать десяток единиц. Структура контрольного листа может быть произвольной и разрабатываться экспертами команды реагирования с учётом особенности проводимых в организации мероприятий по расследованию инцидентов.

Литература

1. Материалы и публикации NIST: http://csrc.nist.gov/publications/nistpubs/index.html

2. BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила

3..BS ISO/IEC 27001:2005 Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования

4. ISO13335-1:2004Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)