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

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

Как только брешь обнаружена, вся АС и все ее компоненты должны находиться под подозрением. Самым подозрительным должно быть системное программное обеспечение. Главным при восстановлении является соответствующая подготовка. Она включает в себя расчет контрольных сумм всех для всех носителей дистрибутивов, используя алгоритм, устойчивый к подмене[10] (смотрите разделы 3.9.4.1 и 3.9.4.2). При условии, что имеются оригинальные дистрибутивы, проводится анализ всех системных файлов, и любые несоответствия должны быть записаны и сообщены всем, кто участвует в улаживании инцидента. В некоторых случаях может оказаться трудным решить, с каких архивных копий восстанавливать систему; ведь инцидент может продолжаться месяцы и годы до того, как его обнаружат. В любом случае нужно провести предварительную подготовку к инциденту, чтобы восстановление стало возможным. В худшем случае произведите восстановление с дистрибутивов.

Учет уроков инцидента всегда приводит к изменению ПРД и СРД для отражения в них нововведений.

6.2.1 Разрушение ценностей

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

6.2.2 Очистка

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

Может оказаться необходимым восстановить АС с дистрибутивов и заново настроить ее. Для облегчения действий в этом случае нужно вести записи о начальной установке АС и каждом изменении в ней.

6.2.3 Уроки на будущее

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

6.2.4 Храните журнал защиты

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