3.8 Взаимодействие с людьми при организации защиты

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

3.8.1 Обучение пользователей

Пользователи должны быть осведомлены о том, как ожидается использовать АС, и как им самим защититься от несанкционированных пользователей.

3.8.1.1 Правильное использование регистрационного имени и СВТ

Все пользователи должны быть информированы о том, что считается "правильным" использованием их регистрационного имени или рабочей станции ("правильное" использование рассматривается в разделе 2.3.2). Легче всего это сделать тогда, когда пользователь получает регистрационное имя, показав ему документ, описывающий ПРД. Правила правильного использования обычно определяют, можно ли использовать регистрационное имя или рабочую станцию для личных дел (написание письма), можно ли запускать задачи с личной выгодой для себя, можно ли играть в игры, и т.д. Этот документ может также использоваться для краткого описания лицензионных программ; например, многие университеты имеют образовательные лицензии, которые явно запрещают коммерческое использование АС. Более полный список вопросов, которые нужно учитывать при написании этого документа, приведен в разделе 2.3

3.8.1.2 Процедуры управления регистрационным именем и рабочей станцией

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

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

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

3.8.1.3 Выявление неправильного использования регистрационного имени

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

Командные интерпретаторы в некоторых ОС (например, С-оболочка в UNIX) хранят имена нескольких последних команд. Пользователям следует проверять эти списки, чтобы быть уверенным, что кто-либо не выполнил другие команды под их регистрационным именем.

3.8.1.4 Процедуры доклада о возникших проблемах

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

3.8.2 Обучение администраторов СВТ

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

3.8.2.1 Процедуры контроля регистрационных имен

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

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

Если операционная система поддерживает средство "теневых" паролей, которое сохраняет пароли в отдельном файле, доступном только привилегированным пользователям, это средство следует использовать. UNIX System V, SunOS 4.0 и выше, и версии Berkeley UNIX после 4.3BSD, а также другие системы поддерживают это средство. Оно защищает пароли с помощью скрытия их зашифрованных значений от непривилегированных пользователей. Это не позволяет атакующему скопировать ваш файл паролей на его или ее СВТ, а затем попытаться расшифровать его содержимое.

Контролируйте за тем, кто имеет доступ к привилегированным регистрационным именам( например, "root" в UNIX или "MAINT" в VMS). Всякий раз, когда привилегированный пользователь покидает организацию или перестает нуждаться в привилегированном регистрационном имени, пароли всех привилегированных регистрационных имен следует изменить.

3.8.2.2 Процедуры контроля за конфигурацией

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

Сетевые службы также должны проверяться при первой установке. Многие производители создают файлы полномочий работы пользователей сети, которые делают все СВТ "надежными", что на самом деле не так, особенно при соединении с глобальными сетями, такими как Интернет.

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

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

3.8.2.3 Процедуры восстановления - архивные копии

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

Архивные копии, особенно ежедневные, могут быть полезны при слежении за действиями злоумышленника. Просмотр старых архивных копий поможет установить, когда он в первый раз проник в вашу систему. Злоумышленники могут создавать файлы, которые потом уда- ляют, но эти файлы могут сохраниться на архивной ленте. Архивные копии могут также использоваться для протоколирования деятельнос- ти злоумышленника при описании ее сотрудникам МВД.

Хорошая стратегия архивных копий должна определять, что как минимум один раз в месяц производится сброс информации всей АС на ленты. Частичные дампы должны производиться как минимум два раза в неделю, а в идеале ежедневно. Следует использовать специальные команды, предназначенные для выполнения архивных копий (например, "dump" в UNIX или "BACKUP" в VMS), а не простые команды копирования файлов при производстве архивных копий, так как эти средства разработаны для облегчения восстановления.

3.8.2.4 Процедуры докладов о проблемах

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

Назад | Содержание | Вперед