Руководство по выработке правил разграничения доступа к ЭВМ
Другие методы и устройства защиты
Защита - это динамический, а не статический процесс. Отслеживание нового в области защиты в компьютерной индустрии будет гарантировать ответственному за защиту, что он использует новейшие достижения технологии.
Книги, списки, информационные источники
Сделайте в организации библиотечку книг, списков и других информационных источников, а также руководств по защите АС. Обновляйте ее. Напомним, что как только АС меняется, меняются и методы и проблемы.
Образуйте подгруппу
Образуйте подгруппу среди системных администраторов, которая будет заниматься защитой. Это позволит обсуждать проблемы защиты и иметь несколько точек зрения на защиту организации. Эта подгруппа может также выступить разработчиком ПРД и СРД.
| |
Храните журнал защиты
Как уже говорилось в , журнал защиты может оказаться самой ценной вещью на этапе ликвидации уязвимых мест. Здесь стоит отметить два момента; во-первых нужно записывать в журнале обо всех мерах, использованных для восстановления защиты АС. В журнал нужно включать информацию о командных процедурах, которые периодически запускаются для проверки защищенности. Во-вторых, нужно делать записи о важных системных событиях. Впоследствии они могут оказаться справочным материалом при определении разрушенной части АС.
| |
Ликвидация уязвимых мест
Ликвидировать все уязвимые места при возникновении инцидента трудно. Ключевым при этом является знание и понимание того, где находится брешь. В некоторых случаях самым разумным будет запретить доступ вообще, а затем восстановить постепенно нормальный режим работы. Помните, что запрет доступа в ходе инцидента ясно покажет всем пользователям, включая злоумышленников, что администрация знает о проблеме; это может сделать невозможным исследование. Тем не менее, позволив инциденту продолжаться, вы можете вызвать еще большие разрушения.
Если выявлено, что брешь возникла в результате ошибок в оборудовании или системном программном обеспечении, то следует уведомить производителя. Рекомендуется включить в ПРД соответствующие номера телефонов (а также адреса электронной почты или факса). Для удобства понимания ошибка должна быть описана как можно детальнее, включая то, как она была использована.
Как только брешь обнаружена, вся АС и все ее компоненты должны находиться под подозрением. Самым подозрительным должно быть системное программное обеспечение. Главным при восстановлении является соответствующая подготовка. Она включает в себя расчет контрольных сумм всех для всех носителей дистрибутивов, используя алгоритм, устойчивый к подмене[10] (смотрите разделы и ). При условии, что имеются оригинальные дистрибутивы, проводится анализ всех системных файлов, и любые несоответствия должны быть записаны и сообщены всем, кто участвует в улаживании инцидента. В некоторых случаях может оказаться трудным решить, с каких архивных копий восстанавливать систему; ведь инцидент может продолжаться месяцы и годы до того, как его обнаружат. В любом случае нужно провести предварительную подготовку к инциденту, чтобы восстановление стало возможным. В худшем случае произведите восстановление с дистрибутивов.
Учет уроков инцидента всегда приводит к изменению ПРД и СРД для отражения в них нововведений.
Обзор
После инцидента следует предпринять несколько действий. Эти действия могут быть обобщены следующим образом:
Следует произвести инвентаризацию ценностей АС, то есть нужно точно определить, каковы последствия инцидента для АС. Уроки, вынесенные из инцидента, следует включить в пересмотренные ПРД и СРД для предотвращения повтора инцидента. Следует произвести новый анализ риска в свете инцидента. Привлечение к судебной ответственности людей, вызвавших инцидент, если это требуется.
Все эти четыре шага обеспечивают обратную связь с ПРД организации, приводя к ее пересмотру.
| |
Очистка
Как только определены разрушения в АС, необходимо разработать план очистки АС. В большинстве случаев необходимо вести восстановление служб в порядке важности для того, чтобы наименьшее число пользователей ощущало неудобство. Нужно понимать, что правильные процедуры восстановления АС являются крайне важными и должны быть специфичны для каждой организации.
Может оказаться необходимым восстановить АС с дистрибутивов и заново настроить ее. Для облегчения действий в этом случае нужно вести записи о начальной установке АС и каждом изменении в ней.
Процедуры сообщения о проблемах
Следует реализовать процедуру сообщения о проблеме, чтобы можно было описать инцидент и то, как его улаживали. Каждый инцидент должен быть рассмотрен подгруппой по защите для понимания инцидента и выработки предложений по изменению ПРД.
| |
Разрушение ценностей
Перед тем, как начинать очистку, надо получить точное представление о разрушениях в АС. Это может потребовать много времени, но поможет глубже разобраться в природе инцидента. Лучше всего сравнить АС с архивной копией или оригиналом, если они есть; важно подготовиться к этому заранее. Если система поддерживает централизованную регистрацию входа в АС, просмотрите все журналы и выявите ненормальные ситуации. Если ведется учет запускаемых процессов и времени работы, то выявите типовое использование АС. При маленьком инциденте характер использования диска может пролить свет на инцидент. Учет работы может дать много ценной информации при анализе инцидента.
Учтите опыт инцидента
После инцидента разумно написать отчет, описывающий инцидент, метод его обнаружения, меры по исправлению ситуации, меры по наблюдению, и главные уроки. Это поможет четкому пониманию проблемы. Напомним, что трудно вынести из инцидента уроки, если вы не понимаете его причин.
и на будущее
Даже если вы решили, что АС восстановлена и находится в безопасном состоянии, вполне возможно, что бреши и ловушки все еще остались в АС. На следующем этапе нужно произвести наблюдение за АС с целью выявления того, что могло быть упущено на предыдущих этапах. Будет разумным использовать некоторые из средств наблюдения, описанных в разделе . Напомним, что эти средства не отменяют необходимости постоянного наблюдения за АС и хороших мер по ее администрированию.
Установление механизмов обновления ПРД и СРД
Если инцидент произошел из-за плохих ПРД, и ПРД не изменены, то нет гарантии, что он не повторится в будущем. Как только организация восстановила АС, нужно пересмотреть ПРД и СРД с целью внесения в них изменений, предотвращающих подобные инциденты. Даже если инцидентов не было, следует регулярно проводить пересмотр ПРД и СРД. Обзоры необходимы из-за постоянно меняющейся компьютерной среды.
