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

Сдерживание

Цель сдерживания - ограничить пространство атаки. Например, важно ограничить распространение сетевого вируса в сети как можно быстрее. Существенной частью сдерживания является принятие решения (например, определение того, отключать ли АС, отсоединять ли ее от сети, следить ли за работой АС или сети, установить ли ловушки, отключить ли такие функции, как удаленная передача файлов в UNIX, и т.д.). Иногда это решение тривиально; отключить АС, если подвергается риску секретная, критическая или частная информация! В других случаях, можно пойти на риск разрушения АС, если оставление АС работающей позволит идентифицировать злоумышленника.

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

Устранение

Как только инцидент выявлен, важно прежде всего подумать о сдерживании инцидента. Как только сдерживание удалось, пора переходить к уничтожению причины, вызвавшей его. У вас может быть в наличии программное обеспечение, которое поможет вам в этом. Например, имеется программное обеспечение для уничтожения вирусов в персональных ЭВМ. Если были созданы фальшивые файлы, пора их удалять. При заражении вирусом важно очистить и переформатировать все диски, содержащие зараженные файлы. Наконец надо удостовериться, что все архивные копии чистые. Многие АС, зараженные вирусами, периодически повторно заражаются из-за того, что люди не удаляют вирусы с архивных копий.

Восстановление

Как только причина инцидента уничтожена, наступает этап восстановления. Целью восстановления является приведение АС к нормальному состоянию. Если атака была сетевой, важно наложить заплатки на все использовавшиеся уязвимые места операционной системы.

Изучение опыта

Один из самых важных этапов ответных действий, который, как правило, упускается - это извлечение опыта на будущее. Этот этап важен, так как он помогает тем, кто участвовал в улаживании инцидента, выработать рекомендации на будущее (смотри раздел 6.3) для улучшения качества ответных действий в таких ситуациях на будущее. Этот этап также дает исходный материал для определения направлений развития ПРД организации.

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

5.4.1 Что вы будете делать?

• Восстановление контроля
• Связь с ПРД
• Какой уровень обслуживания требуется?
• Наблюдение за активностью
• Отключение или ограничение работы АС

5.4.2 Назначьте одного координатора

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

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

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

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