Руководство по защите сети организации (RFC1244)

Original is at

Перевод Владимира Казеннова. kvn@mail.wplus.net

1. Введение

1.1 Цель этой работы

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

1.2 На кого рассчитана книга

Те, на кого рассчитана эта книга, - это администраторы систем
и лица, принимающие решения (которых обычно и называют
"администраторами" или "специалистами среднего звена управления")
на местах . Этот документ не рассчитан на программистов или тех,
кто пробует создать программы или системы безопасности. Задача
этой книги состоит в том, чтобы показать какие ПРД и СРД должны
быть реализованы в вашей организации для поддержки всех
механизмов защиты, имеющихся в вашей организации.
В первую очередь эта работа ориентирована на организации,
являющиеся членами сообщества Internet. Тем не менее, эта книга
может быть полезной любой организации, чьи ЭВМ взаимодействуют с
ЭВМ других организаций. Как общее руководство по ПРД, эта книга
может быть также полезна и для организаций с изолированными
сетями.

1.3 Определения

В этом руководстве "организация" - это любая организация,
которая имеет СВТ или оборудование, соединенное с сетью. Это
оборудование может включать СВТ общего назначения, которые
используют пользователи, маршрутизаторы, терминальные серверы,
персональные СВТ или другие устройства, которые имеют доступ к
Internetу. "Организация" может быть конечным пользователем услуг
Internetа или поставщиком услуг, таким как, например,
региональная сеть. Однако, наибольшее внимание в этом руководстве
уделяется конечным пользователям услуг Internetа.
Предполагается, что организация может самостоятельно
выработать ПРД и СРД для себя.
Internet -это объединение сетей и ЭВМ, использующих протоколы
TCP/IP, соединенных через межсетевые шлюзы, и совместно
использующих общие пространство имен и адресное пространство [1].
"Администраторами системы" называют всех, кто отвечает за
ежедневную работу с ресурсами. Это могут быть как конкретные
люди, так и организации.
"Лицом, принимающим решение (ЛПР)" называют тех людей в
организации, кто вырабатывает стратегию. Это часто (но не всегда)
те люди, кому принадлежат ресурсы.

1.4 Работы в этой области

Рабочая группа по политике секретности (IETF Security Policy
Working Group (SPWG)) в данный момент работает над созданием
набора рекомендаций по организации защиты для Internetа. Эти
рекомендации могут быть приняты как ПРД региональными сетями или
владельцами других ресурсов. Это руководство должно помочь
организациям реализовать ПРД в нужном объеме. Однако даже
претворение в жизнь предложенных ПРД не достаточно для защиты
организации. Предлагаемые Internetом ПРД определяют только защиту
от доступа из сети. Они ничего не говорят о том, как организации
должны решать локальные проблемы защиты.

1.5 Рассматриваемые вопросы

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

1.6 Почему мы нуждаемся в ПРД и СРД ?

Для большинства организаций интерес к защите АС
пропорционален наличию риска и существованию угроз.
Мир средств вычислительной техники (СВТ) сильно изменился
за последние двадцать пять лет. Двадцать пять лет назад
большинство СВТ были централизованными и управлялись центрами
данных. СВТ располагались в закрытых комнатах, кроме того
специально назначенные люди гарантировали, что СВТ корректно
управляются и являются физически защищенными. Соединения сетей
организации с сетями других организаций были редкими. Угрозы
СВТ или отсутствовали, или в основном были связаны со своими
сотрудниками: неправильной регистрацией санкционированных
пользователей , вандализмом и т.д. Эти угрозы были хорошо
известны, и боролись с ними стандартными способами: СВТ
размещались в закрытых помещениях, а все ресурсы
регистрировались.
В 90-е годы ситуация радикально изменилась. Большое
количество СВТ находится в частных ведомствах и лабораториях, и
часто управляется людьми, не работавшими в компьютерных центрах.
Многие СВТ присоединены к Internetу, а через Internet связаны со
всем миром: Соединенными Штатами, Европой, Азией, и Австралией.
Современные угрозы безопасности отличаются от прежних.
Правило, проверенное временем, гласит: "Не записывайте ваш
пароль и не держите его на вашем столе" , чтобы кто-нибудь его
не нашел. Через Internet кто-нибудь может попасть в ваше СВТ с
другой стороны мира и узнать ваш пароль посреди ночи, когда
ваше здание закрыто. Вирусы и компьютерные штормы могут
распространяться по сети. Internet сделал возможным
существование электронного эквивалента вора, ищущего незапертые
окна и двери; теперь человек может проверить сотни СВТ на
незащищенность за несколько часов.
Системные администраторы и ЛПР должны знать существующие
угрозы безопасности, знать, каковы риск и стоимость решения
проблемы, и что надо сделать, если они хотят защититься от
угрозы безопасности.
В качестве иллюстрации некоторых проблем, которые нужно
учитывать при обеспечении защиты, рассмотрим следующие сценарии
(пpиносим благодаpности Расселу Бpанду [2,BRAND] за них]):
1) Системный программист принимает звонок, сообщающий, что
главный подпольный хэккерский журнал распространяется из
административной ЭВМ в его центре по пяти тысячам абонентам в США
и Западной Европе.
Восемь недель спустя власти сообщают вам, что одно из
сообщений этого журнала было использовано, чтобы отключить службу
неотложной помощи "911" в большом городе на пять часов.
2)Пользователь сообщает, что он не смог войти в АС под своим
именем в 3 часа утра в субботу. Системный оператор также не смог
войти в нее. После перезагрузки в однопользовательском режиме, он
обнаружил, что файл паролей пуст. К утру понедельника ваш
персонал установил, что имел место ряд пересылок
привилегированных файлов между этой ЭВМ и местным университетом.
Во вторник утром копия удаленного файла паролей была
обнаружена на университетской ЭВМ наряду с файлами паролей из
дюжины других ЭВМ.
Неделей позже вы обнаруживаете, что ваши файлы инициализации
АС были злонамеренно изменены.
3)Вы получаете сообщение о том, что проникновение в
правительственную лабораторию произошло с одной из ЭВМ вашего
центра. Вас просят показать учетные файлы, чтобы помочь отыскать
нарушителя защиты.
Неделю спустя вы получаете список ЭВМ в вашей организации, в
которые было осуществлено проникновение.
4)Репортер начинает задавать вам вопросы относительно
проникновения в ваш центр. Вы не слышали ни о каком
проникновении.
Три дня спустя вы узнаете о том, что такое проникновение
имело место. Руководитель центра использовал в качестве пароля
имя своей жены.
5)Обнаружено изменение в загрузочных модулях АС.
После того, как они были исправлены, они снова изменились. И
так продолжалось несколько недель.
- Если в вашей АС был обнаружен злоумышленник, следует ли вам
оставить ее открытой для наблюдения за ситуацией или закрыть
бреши в защите и открыть их несколько позже.
- Если злоумышленник использует ЭВМ вашей организации, должны
ли вы вызывать полицию? Кто принимает такое решение? Если полиция
попросит вас оставить ЭВМ открытыми для наблюдения, кто будет
принимать решение по этому вопросу ?
- Какие шаги должны быть предприняты, если другая организация
сообщит вам, что они обнаружили задачи в своих ЭВМ, запущенные
под регистрационным именем пользователя из вашей организации? Что
делать, если это имя принадлежит вашему администратору?
1.7 Основной подход
Выработка ПРД и СРД означает разработку плана, как решать
вопросы, связанные с компьютерной защитой. Вот один из возможных
подходов к решению этой задачи, пpедложенный Файтсом[3, FITES] :
- определить, что вы пытаетесь защищать;
- определить, от чего вам нужно защищаться;
- составить список наиболее вероятных угроз;
- реализовать меры, которые будут защищать ваши ценности
наиболее экономичным способом;
- непрерывно следить за этим процессом, и улучшать защиту
каждый раз, когда в ней найдено слабое место.
Это руководство будет в основном посвящено двум последним
шагам, но первые три шага также необходимы для принятия
эффективных решений относительно защиты. Одно из старых правил
гласит, что цена вашей защиты от угрозы должна быть меньше, чем
цена восстановления ваших ценностей после разрушений, нанесенных
в результате прорыва защиты. Не зная того, что вы защищаете, и
каковы наиболее вероятные угрозы, следовать этому правилу будет
трудно.

1.8 Организация этого документа

Этот документ организован в виде семи частей, помимо
введения.
Как правило, каждая часть рассматривает проблемы, которые
организация может захотеть учесть при выработке ПРД к компьютерам
и определении СРД, реализующей эти ПРД. В некоторых случаях также
приводятся возможные варианты решений. Насколько это возможно,
данный документ не пытается диктовать, какой вариант нужно
выбрать, так как это зависит от местных условий. Некоторые из
этих проблем могут быть неактуальны для всех организаций. Тем не
менее, всем организациям нужно по крайней мере учитывать эти
проблемы, чтобы быть уверенным, что они не пропустили какой-либо
важной области.
В целом этот документ направлен на рассмотрение
организационных проблем, появляющихся как следствие проблем,
возникающих при разработке СРД, реализующей ПРД.
Раздел 2 рассматривает выработку официальных ПРД организации
доступа к вычислительным ресурсам. Он также детально изучает
вопрос о последствиях нарушения этих ПРД. Избранные ПРД во-многом
определят то, как будет реализовываться СРД, поэтому ЛПР надо
сделать выбор в области ПРД перед тем, как решать процедурные
вопросы, описанные в следующих разделах. Ключевым при выработке
ПРД является определение оценки риска, которая позволит решить,
что же на самом деле нужно защищать, и какие ресурсы должны
использоваться для организации защиты.
Как только ПРД определены, нужно выработать СРД для
предотвращения проблем с защитой в будущем. Раздел 3 определяет и
предлагает что делать, если возникли подозрения о том, что
осуществляется несанкционированный доступ. Также рассматриваются
ресурсы, позволяющие закрыть бреши в защите.
Раздел 4 рассматривает типы мер безопасности, предотвращающих
возникновение проблем с секретностью.
Предотвращение - главное в защите; например, Группа
компьютерной защиты (CERT/CC) в университете Карнеги-Меллона
считает, что более 80% проблем, с которыми им пришлось
столкнуться, возникли из-за плохо выбранных паролей.
Раздел 5 рассматривает улаживание инцидентов: с какими
проблемами столкнется организация, когда кто-то нарушит ПРД.
Конечно, многие решения нужно будет принять тогда, когда
произойдет инцидент, но многое можно учесть и решить наперед. По
крайней мере, ответственность лиц и методы взаимодействия между
ними должны быть установлены до инцидента. И опять, на решения
всех этих вопросов повлияет выбор политики, описанный в разделе
2.
Раздел 6 обсуждает вопрос о том, что должно делаться после
того, как инцидент с защитой улажен. Планирование секретности
имеет циклический характер; сразу после того, как произошел
инцидент, появляется великолепная возможность улучшить ПРД и
СРД.
Оставшаяся часть документа содеpжит ссылки и аннотиpованную
библиогpафию.

2. Выработка официальных ПРД организации к АС

2.1 Краткий обзор

2.1.1 Организационные вопросы

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

2.1.2 Кто вырабатывает ПРД ?

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

2.1.3 Кого это затрагивает ?

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

2.1.4 Обязанности

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

2.2 Оценка риска

2.2.1 Общая постановка проблемы

Одной из самых важных причин выработки ПРД является
необходимость гарантии того, что затраты на защиту принесут
впоследствии прибыли (выгоду). Хотя это может показаться
очевидным, но вы можете быть введены в заблуждение, где следует
приложить усилия по организации защиты. Например, много говорят о
злоумышленниках со стороны, проникающих в АС; но просмотр
большинства обзоров по компьютерной безопасности показывает, что
для большинства организаций потери от внутренних
злоумышленников ("своих") гораздо больше.
Анализ риска включает определение того, что вам нужно
защищать, от чего вы защищаетесь, и как защищаться. Для этого вам
надо определить все, чем вы рискуете, и отранжировать их по
уровню важности. Этот процесс включает принятие экономичных
решений о том, что вы хотите защищать. Старый афоризм гласит, что
вы не должны тратить больше денег для защиты чего-либо, чем оно
на самом деле стоит.
Полное рассмотрение анализа риска находится за пределами
этого документа. [3, FITES] и [16,PFLEEGER] являются вводными
книгами в этой области. Тем не менее, существуют два элемента
анализа риска, которые будут кратко рассмотрены в двух следующих
разделах.
1) определение ценностей;
2) выявление угроз.
Для каждой ценности базовыми целями защиты являются
доступность, конфиденциальность и целостность. Каждая угроза
должна рассматриваться с точки зрения того, как она может
затронуть эти три качества.

2.2.2 Определение ценностей

Одним из шагов при анализе риска является определение той
собственности организации, которую нужно защищать. Некоторые вещи
очевидны, такие, как различные СВТ, а некоторые упускаются,
такие, как люди, которые реально используют эти СВТ. Необходим
список всех вещей, которых затрагивает проблема защиты.
Вот один из возможных списков категорий вещей, составленный
на основе списка, пpедложенного Пфлигеpом [16, PFLEEGER, стpаница
459] :
1. Оборудование: системные блоки, платы расширения,
клавиатуры, терминалы, рабочие станции, отдельные персональные
компьютеры, принтеры, дисковые накопители, коммуникационное
оборудование, терминальные серверы, маршрутизаторы.
2. Программное обеспечение: исходные тексты программ,
объектные модули, утилиты, диагностические программы,
операционные системы, коммуникационные системы.
3. Данные: во время выполнения, сохраненные при оперативном
использовании , архивированные, журналы действий, базы данных,
при передаче по каналам связи.
4. Люди: пользователи, обслуживающий персонал, необходимый
для работы АС.
5. Документация: по программам, по СВТ, по АС, по локальным
административным мерам безопасности.
6. Расходные материалы: бумага, красящие ленты, магнитные
ленты.

2.2.3 Выявление угроз

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

2.2.3.1 Несанкционированный доступ

Общей угрозой для большей части организаций является
несанкционированный доступ к СВТ. Несанкционированный доступ
имеет много форм. Одна из них - использование чужого пароля для
получения доступа к АС. Использование любой АС без разрешения
может считаться несанкционированным доступом к СВТ.
Опасность несанкционированного доступа неодинакова в
различных организациях. В некоторых организациях сам факт
предоставления доступа несанкционированному пользователю может
привести к невосстанавливаемым повреждениям СВТ. В других -
несанкционированный доступ открывает двери другим угрозам защите.
Кроме того, некоторые организации могут быть объектом более
частых атак, чем другие; поэтому риск несанкционированного
доступа меняется от организации к организации. Группа CERT (CERT
- смотpи часть 3.9.7.3.1) заметила, что известные университеты,
правительственные организации и военные части более привлекают
злоумышленников.

2.2.3.2 Раскрытие информации

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

2.2.3.3 Отказ в обслуживании

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

2.3 Политические проблемы

Существует ряд проблем, которые нужно решить при разработке
ПРД. Вот они:
1) Кому разрешено использовать ресурсы?
2) Что такое правильное использование ресурсов?
3) Кто отвечает за предоставление доступа и надежное
предоставление сервиса?
4) Кто может иметь привилегии системного администратора?
5) Каковы права и обязанности пользователей?
6) Каковы права и обязанности системного администратора по
отношению к пользователям?
7) Что делать с конфиденциальной информацией?
Эти проблемы рассматриваются ниже. Кроме того, вы можете
захотеть включить в ваши ПРД раздел, связанный с этикой
использования СВТ и АС. Паpкеp, Своуп и Бейкеp [17, PARKER90], а
также Фоpестеp и Моppисон[18,FORESTER] являются двумя полезными
спpавочными pуководствами, описывающими этические вопpосы.

2.3.1 Кому разрешено использовать ресурсы?

Одним из действий, которые вы должны произвести при
разработке ваших ПРД, - это определение тех лиц, кому разрешается
использовать вашу АС и ваши сервисы. ПРД должны явно определять,
кому официально разрешено использовать эти ресурсы.

2.3.2 Что такое правильное использование ресурсов ?

После определения того, кому разрешен доступ к ресурсам
системы, необходимо дать рекомендации по приемлемому
использованию ресурсов. Вы можете давать различные рекомендации
различным типам пользователей (например, студентам, сотрудникам
факультета, внешним пользователям). ПРД должны определять, что
такое допустимое использование, а также что такое недопустимое
использование ресурсов. В них также следует включить определение
типов использования ресурсов, применение которых может быть
ограниченным.
Определите границы доступа к ресурсам и полномочия при
доступе. Вам понадобится учесть уровень доступа, который будут
иметь различные пользователи, а также то, какие ресурсы будут
доступны или ограниченно доступны различным группам людей.
В отношении допустимого использования ресурсов ваши ПРД
должны однозначно установить, что каждый человек отвечает за свои
действия. Их обязанности существуют всегда, независимо от того,
какие механизмы секретности действуют. Должно быть явно
определено, что использование чужих паролей или обход защиты
являются недопустимыми действиями.
Следующие моменты следует учесть при разработке правил
допустимого использования:
- допустимо ли получение доступа к информации о пользователях?
- допустимо ли вскрытие чужих паролей?
- допустимо ли разрушение служб сети?
- должны ли пользователи предполагать, что файл, являющийся
доступным всем по чтению, дает им право читать его?
- можно ли разрешить пользователям модифицировать файлы,
которые не являются их собственными, даже если они имеют
право записи в них?
- можно ли нескольким пользователям использовать одно и то же
регистрационное имя и пароль?
Ответом на большинство этих вопросов будет "НЕТ".
Вы можете захотеть включить в ваши ПРД пункт, связанный с
программным обеспечением, защищенным авторскими правами или
лицензированным. Лицензионное соглашение с производителями может
потребовать некоторых усилий от вас для того чтобы гарантировать
отсутствие нарушений лицензии. Кроме того, вы можете захотеть
проинформировать пользователей, что копирование программ,
защищенных авторскими правами, является нарушением законов об
авторских правах и запрещено.
В отношении программного обеспечения, которое является
лицензионным или защищено авторскими правами, вы можете захотеть
включить в ПРД следующую информацию:
- какое лицензионное и защищенное авторскими правами
программное обеспечение не может копироваться за исключением
случая, когда явно сказано, что вы можете делать это;
- методы доведения информации о статусе разрешения
копирования программ;
- фразу "Когда у вас возникли сомнения, НЕ КОПИРУЙТЕ".
Ваши правила допустимого использования очень важны. ПРД,
которые явно не определяют, что запрещено, могут впоследствии не
позволить вам доказать, что пользователь нарушает ПРД.
Существуют исключения, такие как пользователи или
администраторы, желающие иметь "лицензию на хэккерство" - вы
можете столкнуться с ситуацией, когда пользователи захотят
исследовать ваши АС ради тестирования защищенности. Вы должны
разработать ПРД, которые будут определять, можно ли вам разрешать
такой тип исследований ваших сетевых служб и, если это так,
каковы рекомендации при проведении таких исследований.
Что вам следует отразить в этой части ПРД:
- можно ли это делать вообще;
- какой тип деятельности разрешен: доступ к информации,
запуск сетевых вирусов, запуск вирусов, и т.д.;
- какой контроль должен осуществляться при этом, чтобы
гарантировать, что ситуация не вышла из-под контроля (например,
выделить сегмент вашей сети для этих тестов);
- каким образом вы будете защищать остальных пользователей,
чтобы они не стали жертвами этих процессов, включая внешних
пользователей и сети;
- процесс получения разрешения на проведение этих тестов.
В тех случаях, когда вы разрешили проведение таких
исследований, вы должны изолировать тестируемую часть сети от
основной сети. Сетевые вирусы и просто вирусы никогда не должны
запускаться в реальной сети.
Вы можете также захотеть подрядить кого-либо для оценки
защищенности ваших АС, что может включать их исследование. Вы
можете захотеть отразить этот момент в ваших ПРД.

2.3.3. Кто отвечает за предоставление доступа
и надежное предоставление услуг?

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

2.3.4. Кто может иметь привилегии
системного администратора?

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

2.3.5. Каковы права и обязанности пользователей?

Ваши ПРД должны включать пункты о правах и обязанностях
пользователей в отношении использования СВТ и сервисов
организации. Должно быть явно установлено, что пользователи
отвечают за понимание и соблюдение правил безопасности в АС,
которые они используют. Далее приводится список моментов, которые
вы можете захотеть зафиксировать в этой области ПРД:
- каковы рекомендации в отношении использования ресурсов
(ограничиваются ли пользователи в чем-либо, и если это так,
то каковы эти ограничения);
- что может явиться злоупотреблением с точки зрения
производительности АС;
- разрешается ли нескольким пользователям использовать одно
регистрационное имя или позволять другим использовать их
имена;
- как "секретным" пользователям следует хранить свои пароли;
- как часто пользователям следует менять свои пароли, а также
любые другие ограничения или требования в отношении паролей;
- будете ли вы производить резервные копии, или пользователям
следует самим делать свои копии;
- запрет на разглашение информации, которая может являться
частной собственностью;
- пункт о безопасности электронной почты(Акт о конфиденциальности
электpонных коммуникаций);
- политика в отношении электронных коммуникаций:
фальсификация почты.
Ассоциация электpонной почты финансиpовала публикацию о
конфиденциальности электpонной почты в компаниях[4]. Их базовой
рекомендацией в отношении электронной почты является
то, что каждая организация должна иметь политику по защите
частной собственности своих служащих. Также рекомендуется, чтобы
организации установили политику в отношении частной собственности
при использовании всех сред передачи информации, а не только
электронной почты.
Предлагается пять критериев для оценки любой политики:
1) Согласуется ли политика с законами и требованиями
общественных организаций?
2) Пытается ли политика найти компромисс между интересами
служащих, руководства организации и общественных организаций?
3) Действует ли эта политика в жизни и требуют ли ее
соблюдения?
4) Касается ли эта политика различных форм взаимодействия и
хранения информации, имеющих место в организации?
5) Была ли эта политика известна заранее и согласована со
всеми заинтересованными лицами?

2.3.6. Каковы права и обязанности
системного администратора по отношению к пользователям?

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

2.3.7. Что делать с конфиденциальной информацией?

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

2.4 Что происходит при нарушениях ПРД

Понятно, что когда определен любой тип официальных ПРД,
независимо от того, связаны они с компьютерной секретностью или
нет, рано или поздно они будут нарушены. Нарушение может
произойти из-за нерадивости людей, случайной ошибки, неверной
информации о текущих ПРД, или их непонимания. Также вполне
возможно, что человек (или группа людей) специально совершат
действия, которые являются прямым нарушением ПРД.
При обнаружении нарушения ПРД действия, предпринимаемые сразу
же после нарушения, должны быть определены заранее, для того
чтобы быть уверенным в том, что будет сделано все, что
необходимо. Нужно провести расследование, чтобы выявить то, как
и почему произошло нарушение. Затем следует выполнить ряд
корректирующих действий. Что и в каком объеме нужно будет
сделать, зависит от типа произошедшего нарушения.

2.4.1 Что нужно делать в ответ на нарушение ПРД

Нарушения ПРД могут совершаться самыми разными
пользователями. Некоторые из них могут быть местными
пользователями, а другие - людьми со стороны. Организация может
найти полезным определение того, кого считать "своим" и "чужим"
на базе административных или политических границ. Эти границы
косвенно определят, что нужно сделать для исправления ситуации;
от выговора до наложения штрафа. Поэтому вам надо не только
определить предпринимаемые шаги на основе типа нарушения, но
также иметь четко определенные последовательности действий для
каждого типа пользователя. Это может показаться слишком сложным,
но лучше сделать это заранее, чем второпях после нарушения.
Стоит запомнить один момент в отношении ваших ПРД -
правильное обучение является наилучшей защитой. Когда "чужие"
легально используют ваши СВТ, вы обязаны проверить, что они
ознакомлены с ПРД, которые вы установили. Эта информация может
пригодиться вам в будущем, когда понадобится применить уголовные
санкции.
Для пользователей, использующих ваши СВТ нелегально, проблема
по существу остается той же. Пользователь какого типа нарушил
ПРД, почему и как он это сделал? В зависимости от результатов
расследования вы можете просто заделать брешь в защите и занести
ее в вашу копилку опыта. Или, если в результате нарушения вы
потерпели большие убытки, вы можете сделать что-либо более
жесткое.
2.4.2 Что делать, когда ваши местные пользователи
нарушают ПРД другой организации?
В случае, когда местный пользователь нарушил ПРД другой
организации, ваша организация должна иметь четко определенный
набор административных действий, применяемых к этому
пользователю. Организация также должна быть готовой к защите
самой от возможных действий этой другой организации. Такие
ситуации приводят к проблемам, которые должны быть отражены при
разработке ПРД.

2.4.3 Определение того, с кем связываться
во внешних организациях

ПРД должны включать процедуры для взаимодействия со внешними
организациями. Они включают в себя пpавоохpанительные оpганы,
другие организации( напpимеp, CERT, CIAC), специальные
организации по противодействию промышленному шпионажу и агентства
печати. Эти процедуры должны устанавливать, кто имеет право
связываться с ними, как это надо делать. Заранее надо продумать
ответы на следующие вопросы:
- Кто может выступать перед прессой?
- Когда надо связываться с органами внутренних дел и
специальными организациями?
- Если инициатором такого контакта является другая
организация, уполномочен ли системный администратор участвовать в
такого рода контактах?
- Можно ли сообщать какие-либо данные? Какого рода?
Детальная информация о том, с кем связываться, должна быть
общедоступна вместе с четко определенными процедурами, которым
надо следовать.

2.4.4 Каковы обязанности перед вашими соседями
и другими организациями Интернета?

Рабочая группа по политике секретности в IETF работает над
документом, имеющим название "Политические рекомендации по
безопасной работе в Интернете"[23]. Он связан с тем, что Интернет
это единое целое, и что организации должны оказывать друг другу
помощь. Это момент также следует отразить при разработке ПРД
организации. В основном нужно определить, какой объем информации
можно сообщать другим организациям. Он будет меняться от
организации к организации в зависимости от типа организации
(например, военная, образовательная, коммерческая), а также от
типа произошедшего нарушения секретности.

2.4.5 Проблема процедур улаживания инцидента

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

2.5 Закрыть или открыть

Всякий раз, когда в организации происходит инцидент, который
может скомпрометировать компьютерную безопасность, на стратегию
ответных действий могут повлиять два противоположных фактора.
Если управление организации боится, что она сильно уязвима,
то может применять стратегию "Защити и Работай". Основной целью
такого подхода является защита и сохранение служб организации
и как можно более быстрое их восстановление после нарушений для
пользователей. Будет производиться активное противодействие
злоумышленникам, защита от дальнейших попыток их доступа и
немедленное восстановление после разрушений. Этот процесс может
включать отключение служб, прекращение доступа к сети, или
другие жесткие меры. Недостатком является то, что если
злоумышленника не удалось установить, он может проникнуть в АС
другим путем или атаковать другую организацию.
Альтернативный подход, "Проследи и Накажи" исповедует другую
философию и цели. Основной целью является позволить
злоумышленникам продолжать свою деятельность в организации до тех
пор, пока организация не сможет установить, кто это такой. Этот
подход практикуется органами внутренних дел. Недостатком его
является то, что МВД не может защитить организацию от возможных
судебных процессов с пользователями из-за разрушений их АС и
данных.
Уголовная ответственность - не единственное возможное
наказание после определения злоумышленника. Если виновником
является служащий или студент, организация может использовать
административные наказания. В ПРД следует указать возможные
варианты наказаний, и какой из них выбрать после поимки
преступника.
Управление организацией должно проявить особую осторожность
при выборе подхода, который будет использоваться для решения
данной проблемы, и выбрать его до того, как произойдет нарушение.
Используемая стратегия может зависеть от ситуации. Или может быть
принята глобальная политика, которая регламентирует один подход
во всех случаях жизни. Следует тщательно взвесить все за и против
и довести принятую политику до пользователей, чтобы они знали
насколько они уязвимы, независимо от того, какой подход
используется.
Далее приводится условий, чтобы помочь организации
определить, какую стратегию избрать: "Защищай и Работай" или
"Проследи и Накажи".
Защищай и Работай
1) Если ценности не очень хорошо защищены
2) Если продолжение работы злоумышленника может привести к
большому финансовому риску
3) Если нет возможности наказать нарушителя в уголовном
порядке
4) Если местонахождение пользователей тяжело определить
5) Если пользователи неопытны и их работа уязвима
6) Если организация уязвима в отношении судебных процессов с
пользователями, например, если ее ресурсы невелики
Проследи и Накажи
1) Если ценности и системы хорошо защищены
2) Если имеются хорошие архивные копии
3) Если риск для ценностей перевешивается возможными
разрушениями в результате будущих проникновений
4) Если это большая атака, возникающая с большой частотой и
интенсивностью
5) Если организация привлекательна для злоумышленников, и
вследствие этого регулярно атакуется ими.
6) Если организация согласна подвергать ценности финансовому
риску в результате продолжающегося проникновения.
7) Если доступ злоумышленника контролируется
8) Если средства наблюдения так хорошо разработаны, что
делают слежение безопасным.
- 21 -
9) Если программисты организации настолько хорошо разбираются
в операционной системе, утилитах и системах, что слежение
становится безопасным
10) Если есть согласие части управления организации на
судебное преследование нарушителя
11) Если системные администраторы хорошо знают, что является
уликами для суда
12) Если есть контакт со знающими сотрудниками внутренних дел
13) Если есть человек в организации, разбирающийся в
связанных с этим вопросах законности
14) Если организация готова к судебным процессам с
пользователями, если их данные или системы будут
скомпрометированы в процессе слежки за злоумышленником

2.6 Интерпретация ПРД

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

2.7 Публикация ПРД

Как только ПРД организации выработаны и описаны, должен
начаться энергичный процесс их доведения, чтобы быть уверенным в
том, что их положения стали повсеместно известны и обсуждаются.
Недостаточно просто вывесить ПРД на доске объявлений. Нужно
разрешить в течение некоторого периода давать свои комментарии до
того, как ПРД начнут действовать, чтобы быть уверенным в том, что
все заинтересованные пользователи имели возможность высказать
свое мнение и пожелания. В идеале ПРД должны найти золотую
середину между защищенностью и производительностью.
Нужно провести несколько собраний, чтобы узнать все
замечания, а также удостовериться, что ПРД правильно поняты. (Те,
кто отвечает за публикацию ПРД, могут быть хорошими
специалистами, но не уметь писать документы). На этих собрания
должны присутствовать как верхнее звено управления организацией,
так и простые служащие. Защита - коллективное дело.
Помимо публикации ПРД перед их внедрением организации важно
поддерживать осведомленность служащих о ПРД. Текущим
пользователям надо периодически напоминать их положения. Новым
пользователям следует узнавать о ПРД при ознакомлении с
организацией. Было бы желательно, чтобы перед тем, как
использовать службы организации, пользователи бы давали подписку
о том, что они ознакомлены с ПРД и уяснили их. Если впоследствии
к этим пользователям необходимо будет применить санкции с точки
зрения закона, эта подписка может сыграть важную роль.

3. Создание СРД

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

3.1 ПРД определяют, что нужно защищать.

ПРД определяют: что нужно защищать, что является наиболее
важным, каковы приоритеты, и каким должен быть общий подход при
решении проблем защиты.
ПРД сами по себе не определяют, КАК защищать. Это - задача
СРД, которым и посвящен этот раздел. ПРД должны быть документом
концептуального уровня, описывающим общую стратегию. СРД же нужны
для того, чтобы детально описать, какие конкретные шаги должна
предпринять организация для собственной защиты.
ПРД должны включать анализ риска угроз, которым может
подвергаться организация, и последствия этих угроз (смотри раздел
2.2). Анализ риска должен включать общий список ценностей,
которые нужно защищать (раздел 2.2.2). Эта информация важна для
создания наиболее эффективной СРД.
Часто возникает соблазн начать создание СРД сразу с описания
механизмов: "наша организация должна зарегистрировать
пользователей компьютеров, модемов и смарт-карт". Это подход
может привести к тому, что некоторые области будут слишком
защищены, а некоторые недостаточно. Если же вы начали с создания
ПРД и описания в ней всех рисков, то можете быть уверенным, что
ваша СРД обеспечит нужную степень защиты для всех ценностей.

3.2 Идентификация возможных проблем

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

3.2.1 Точки вхождения

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

3.2.2 Неправильно сконфигурированные АС

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

3.2.2 Программные ошибки

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

3.2.3 Угрозы от "своих"

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

3.3 Выбор мер безопасности для защиты ценностей
наиболее эффективным способом

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

3.3.1 Выбор правильного набора мер безопасности

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

3.3.2 Использование здравого смысла

Здравый смысл - самое подходящее средство, которое может быть
использовано при выработке ваших ПРД. Тщательно разработанные
схемы и механизмы защиты впечатляют, и они должны иметься, но
стоит ли вкладывать деньги и время в тщательно разработанные
схемы, если забыты простые меры безопасности. Например,
независимо от того, насколько тщательно разработана система,
которую вы используете для безопасности, один-единственный
пользователь с плохим паролем может сделать вашу АС открытой для
атаки.

3.4 Использование нескольких стратегий
для защиты ценностей

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

3.5 Физическая секретность

Даже если вы разработали систему ПРД, но не защитили
физически сами СВТ, все ваши СВТ не могут считаться защищенными.
Имея возможность физического доступа к СВТ, злоумышленник может
остановить СВТ, перевести ее в привилегированный режим, заменить
диск, установить программу-закладку (смотри пункт 2.13.9.2) или
сотворить еще что-либо с вашим СВТ.
Важные каналы связи, сервера, и другие ключевые СВТ должны
быть размещены в физически защищенных зонах. Некоторые системы
защиты (такие как Керберос), требуют, чтобы СВТ было физически
защищено.
Если вы не можете физически защитить СВТ, нужно проявлять
осторожность в вопросе доверия к этим СВТ. Организации должны
более ограничивать доступ с незащищенных СВТ по сравнению с
доступом с защищенных СВТ. В частности, допущение надежного
доступа (например, удаленные команды BSD Unix, такие как rsh) с
этого типа СВТ особенно рискованно.
Для СВТ, которые должны стать физически защищенными, нужно
соблюдать осторожность при определении того, кто может иметь
доступ к этим СВТ. Напомним, что отделы охраны и обслуживания
часто имеют ключи от комнат.

3.6 Процедуры для выявления несанкционированных задач в АС

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

3.6.1 Наблюдение за использованием АС

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

3.6.2 Средства для наблюдения за АС

Эта секция описывает средства и методы для наблюдения за АС с
целью выявления несанкционированного доступа и использования.

3.6.2.1 Вход в АС

Большинство операционных систем хранят много информации в
файлах-журналах входов в АС. Регулярное исследование этих файлов
часто может послужить первой линией обороны при выявлении
несанкционированного использования АС.
1) Сопоставьте списки пользователей, работающих сейчас, и
предысторию входов в АС. Большинство пользователей обычно
начинают и заканчивают работать приблизительно в одно и то же
время каждый день. Если же пользователь вошел в АС в "необычное"
время для этого пользователя, то возможно, что это злоумышленник.
2) Многие АС содержат записи о входах в АС для составления
ведомостей о плате за пользование. Эти записи также могут быть
использованы для выявления типового использования АС; необычные
записи могут указывать на незаконное использование АС.
3) Следует проверять системные утилиты, связанные со входом в
АС, такие как утилита UNIX "syslog", на наличие сообщений о
необычных ошибках от системного программного обеспечения.
Например, большое число аварийно завершившихся попыток входа в АС
за короткий период времени может указывать на то, что кто-то
пытается угадать пароль.
4) Команды операционной системы, которые выводят на экран
список выполняющихся в данный момент процессов, могут быть
использованы для обнаружения пользователей, запускающих
программы, которые они не имеют права запускать, а также для
обнаружения программ, которые были запущены злоумышленником.

3.6.2.2 Наблюдающее программное обеспечение

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

3.6.2.3 Другие средства

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

3.6.3 Меняйте график наблюдения

Задача наблюдения за АС не является настолько устрашающей,
как это может показаться. Системные администраторы могут
выполнять многие из команд, используемых для наблюдения, на
протяжении всего дня в свободное время (например, во время
телефонного разговора), а не в фиксированное время, специально
выделенное для наблюдения за АС. Выполняя команды часто, вы скоро
научитесь узнавать "нормальные" результаты, и будете легко
замечать нестандартные ситуации. Кроме того, запуская различные
команды наблюдения в разное время в течение всего дня, вы
усложняете для злоумышленника предсказание ваших действий.
Например, если злоумышленник знает, что каждый день в 17:00
система проверяется на предмет того, все ли завершили работу с
АС, он просто подождет, пока проверка не закончится, а потом
опять войдет в АС. Но злоумышленник не может предугадать, когда
системный администратор введет команду отображения всех
работающих пользователей, и поэтому подвергается гораздо большему
риску быть обнаруженным.
Несмотря на преимущества, которые дает регулярное наблюдение
за АС, некоторые злоумышленники могут быть осведомлены о
стандартных механизмах входа в АС, используемых в СВТ, которые
они атакуют. Они будут активно вмешиваться в их работу и пытаться
отключить механизмы наблюдения. Поэтому регулярное наблюдение
полезно при обнаружении злоумышленников, но не дает никакой
гарантии, что ваша АС защищена. Так что не стоит рассматривать
наблюдение как непогрешимый метод обнаружения незаконного
использования АС.

3.7 Определите действия, предпринимаемые
при подозрении на несанкционированную задачу

Разделы 2.4 и 2.5 рассмотрели порядок действий, которые
должна предпринять организация при подозрении на проникновение в
АС. ПРД должны определить общий подход при рассмотрении проблем
такого рода.
Должны быть описаны процедуры решения проблем такого рода.
Кто должен решить, какие действия следует предпринять? Нужно ли
привлекать органы внутренних дел? Должна ли ваша организация
взаимодействовать с другими организациями при попытке проследить
за злоумышленником? Ответы на эти вопросы и вопросы из раздела
2.4 должны быть частью процедур улаживания инцидентов.
Если вы решили проследить за злоумышленником или отключить
его от АС, вы должны иметь наготове средства и процедуры, которые
вы будете использовать. Лучше всего разработать и средства, и
процедуры до того, как они понадобятся вам. Не ждите, пока
злоумышленник появится в вашей АС, чтобы начать решать проблему,
как проследить за злоумышленником; это потребует от вас много
времени, если он опытен.

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 Процедуры докладов о проблемах

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

3.9 Ресурсы, закрывающие бреши в защите

Эта часть описывает программное обеспечение, оборудование и
меры безопасности, которые могут использоваться для реализации
вашей СРД.

3.9.1 Сетевые соединения и "горящие стены"

Термин "горящая стена" обозначает что-либо, преграждающее
путь в какое-либо место, позволяющее добраться до него только
тем, кому можно, и делающее для всех остальных это место
недоступным. Этот термин вполне можно применить к
компьютеризированной организации, особенно он подходит для
сетевых соединений.
В некоторых организациях отделы расположены в одном месте и
должны соединяться только друг с другом, и не должны соединяться
с другими организациями. Такие организации менее чувствительны к
угрозам извне, хотя проникновение и может произойти через модем.
С другой стороны много других организаций соединены с другими
организациями через глобальные сети, такие, как Интернет. Эти
организации чувствительны к целому ряду угроз, связанных с
сетевой средой.
Следует тщательно сопоставить выгоды от соединения с внешними
сетями с риском такого соединения. Может быть желательно
ограничить соединение с внешними сетями только теми СВТ, на
которых нет конфиденциальной информации, оставив "жизненно
важные" ЭВМ (например, те на которых считается заработная плата)
изолированными. Если есть необходимость соединения с глобальной
сетью, следует ограничить доступ к вашей местной сети таким
образом, чтобы он осуществлялся через одну ЭВМ. То есть, все
обращения в вашу сеть или из вашей сети должны проходить через
одну ЭВМ, являющуюся как бы горящей стеной между вами и внешним
миром. Такая горящая стена должна быть строго контролируемой и
защищенной паролем, а доступ к ней внешних пользователей также
должен быть ограничен путем наложения ограничений на возможности,
доступные удаленным пользователям. Используя этот подход, ваша
организация может ослабить некоторые внутренние меры по защите
местной сети, но при этом будет оставаться защищенной с помощью
этой промежуточной машины.
Отметим, что даже при наличии горящей стены ее компрометация
может привести к компрометации всей сети за этой стеной. В
нескольких местах была осуществлена работа по созданию горящей
стены, которая даже будучи скомпрометированной, все еще защищает
местную сеть[6, CHESWICK].

3.9.2 Конфиденциальность

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

3.9.2.1 Шифрование( аппаратное и программное)

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

3.9.2.1.1 Стандарт шифрования данных (DES)

DES является, наверное, самым широко используемым механизмом
шифрования данных в наше время. Существует большое число его
аппаратных и программных реализаций, а некоторые СВТ продаются
вместе с его программной реализацией. DES трансформирует обычную
текстовую информацию в зашифрованные данные (или шифротекст)
посредством специального алгоритма и исходного числа, называемого
ключом. Пока ключ не потерян пользователем, из шифротекста может
быть восстановлен исходный текст.
Одной из ловушек всех систем шифрования является
необходимость запоминать ключ, которым вы зашифровали текст
(здесь ситуация аналогична проблемам с хранением пароля). Если
ключ где-либо записан, он становится менее секретным. Если он
забыт, надежда восстановить ваш текст очень мала (если она вообще
существует) .
Большинство UNIXов содержат команду DES, которая позволяет
пользователю зашифровать данные, используя алгоритм DES.

3.9.2.1.2 Crypt

Аналогично команде DES команда UNIX "crypt" позволяет
пользователю зашифровать данные. К сожалению, алгоритм,
использованный в "crypt", очень слабый (основывается на
устройстве времен второй мировой войны), и файлы, зашифрованные
этой командой, могут быть расшифрованы за несколько часов.

3.9.2.1.3 Diskreet

Для операционной среды MS-DOS и Windows фирмой Symantec
разработана программа Diskreet, входящая в пакет Norton
Utilities. Она также реализует алгоритм DES при шифровании
файлов, а также обладает рядом других возможностей.

3.9.2.1.4 Зашифрованные архивы

Для этой же среды можно воспользоваться архиватором Pkzip
фирмы PkWare, задав при создании архива режим шифрования.
Алгоритм, используемый этой программой, достаточно сильный. Такой
же режим есть и в другом популярном архиваторе ARJ, но там
используется крайне примитивный алгоритм, поэтому им пользоваться
не рекомендуется

3.9.2.2 Электронная почта с повышенной защитой

Электронные письма обычно передаются по сети в читабельном
виде (то есть любой может прочитать их). Конечно, это нехорошо.
Электронное письмо с повышенной безопасностью обеспечивает
средство для автоматического шифрования электронных писем,
поэтому человеку, тайно просматривающему письма в месте их
хранения перед рассылкой нелегко будет прочитать их. Сейчас
разрабатываются несколько пакетов электронной почты с повышенной
безопасностью и будут впоследствии распространены по Интернету.
Протокол ее реализации описан в RFC1113, 1114 и 1115[7,8,9]. Со
вpеменем статус стандаpтизации может измениться, поэтому
посмотpите теущее издание "Списка официальных пpотоколов
IAB"(сейчас RFC 1200[21])

3.9.3 Аутентификация отправителя

Мы, как правило, верим, что в заголовке электронного письма
указан истинный отправитель сообщения. Тем не менее, можно легко
подменить отправителя письма. Аутентификация отправителя
обеспечивает средство, позволяющее удостоверить то, что указан
настоящий отправитель таким же способом, каким нотариальная
контора удостоверяет подпись на документе. Это делается
посредством криптосистемы с "открытым ключом".
Криптосистема с открытым ключом отличается от криптосистемы с
секретным ключом несколькими особенностями. Во-первых, система с
открытым ключом использует два ключа, открытый ключ, который
может использовать любой, и закрытый ключ, который использует
только отправитель сообщения. Отправитель применяет закрытый ключ
для шифрования сообщения (как в DES). Получатель, которому
отправитель передал открытый ключ, может затем расшифровать
сообщение.
В этой схеме открытый ключ используется для аутентификации
использования отправителем своего закрытого ключа, и, как
следствие, для более надежной идентификации отправителя. Наиболее
известной реализацией криптосистемы с открытым ключом является
система RSA[26]. Стандарт Интернета на электронную почту с
повышенной безопасностью использует систему RSA.

3.9.4 Целостность информации

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

3.9.4.1 Контрольные суммы

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

3.9.4.2 Криптографические контрольные суммы

При использовании криптографических контрольных сумм
(также называемых цифровой подписью) файл делится на небольшие
части, для каждой вычисляются ЦКС, а затем все ЦКС собираются
вместе. В зависимости от используемого алгоритма это может дать
почти надежный метод определения того, был ли изменен файл.
Этот механизм опирается на то, что он требует больших
вычислительных затрат, и может быть вполне подходящим, кроме
тех случаев, когда требуется самая мощная защита целостности,
какая только возможна.
Другой аналогичный механизм, называемый однопроходной
хэш-функцией (или кодом обнаружения манипуляций (КОМ)), может
также использоваться для уникальной идентификации файла. Идея
состоит в том, что не существует двух значений входных данных для
которых выходные данные были бы одинаковыми, поэтому
модифицированный файл не будет иметь то же самое значение
хэш-функции. Однопроходные хэш-функции могут быть эффективно
реализованы в ряде АС, что делает возможным существование
надежной проверки целостности. Именно хэш-функция легла в основу
алгоритма цифровой подписи, описанного в ГОСТе. (Snefru,
однопpоходная хэш-функция, доступная чеpез USENET или Интеpнет,
является одним из пpимеpов эффективной однопpоходной
хэш-функции).[10]

3.9.5 Ограничение сетевого доступа

Основные сетевые протоколы, используемые в Интернете, IP(RFC
791), [11] TCP (RFC 793) [12] и UDP (RFC 768) [13] содержат
определенную управляющую информацию, которая может быть
использована для ограничения доступа к определенным ЭВМ или сетям
внутри организации.
Заголовок пакета IP содержит сетевые адреса как отправителя,
так и получателя пакета. Более того, протоколы TCP и UDP работают
в терминах "портов", которые идентифицируют конечные точки
(обычно сетевые серверы) и пути взаимодействия. В некоторых
случаях может потребоваться запретить доступ к конкретному порту
TCP или UDP, или к определенным ЭВМ и сетям.

3.9.5.1 Таблицы маршрутизации шлюза

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

3.9.5.2 Фильтрация пакетов маршрутизатором

Многие коммерчески доступные шлюзы (которых более правильно
называть маршрутизаторами) предоставляют возможность фильтровать
пакеты не только на основе отправителя и получателя, но также на
комбинации отправитель-получатель. Этот механизм может быть
использован для запрета доступа к конкретной ЭВМ, сети или
подсети от другой конкретной ЭВМ, сети или подсети.
Шлюзовые системы нескольких производителей (например, CISCO)
поддерживают более сложную схему, позволяя более тонко задавать
адреса отправителя и получателя. Используя маски адресов, можно
запретить доступ ко всем ЭВМ, кроме одной в какой-либо сети.
Маршрутизаторы CISCO также осуществляют фильтрацию на основе типа
протокола в IP и номеров портов TCP и UDP[14].
Всю эту защиту можно обойти с помощью пакетов с опцией
"маршрутизация источника", направленных к "секретной" сети.
Пакеты с маршрутизацией источника могут быть отфильтрованы
шлюзами, но это ограничит выполнение других санкционированных
задач, таких как диагностирование ошибок маршрутизации.

3.9.6 Системы аутентификации

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

3.9.6.1 Керберос

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

3.9.6.2 Смарт-карты

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

3.9.7 Книги, списки и инфоpмационные источники

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

3.9.7.1 Списки pассылки по безопасности

Список pассылки по безопасности Unix существует для
уведомления системных администpатоpов о пpоблемах безопасности до
того, как о них станет известно всем, и для пpедоставления
инфоpмации, позволяющей улучшить безопасность. Это список с
огpаниченным доступом , доступный только для тех людей, кто может
быть веpифициpован как ответственный за АС в оpганизации. Запpосы
о пpисоединении к этому списку должны быть посланы тем, кто
указан в базе данных WHOIS DDN NIC, или тем, кто заpегистpиpован
как root на одной из главных ЭВМ оpганизации. Вы должны указать,
куда посылать письма из этого списка, пpисылать ли вам письма по
отедельности или еженедельные дайджесты, ваш личный адpес
электpонной почты и номеp телефона ответственного за
безопасность, если это не вы, и название, адpес и номеp телефона
вашей оpганизации. Эта инфоpмация должна быть
SECURITY-REQUEST@CPD.COM.
Дайджест RISKS является частью Комитета ACM по компьютеpам и
общественной политике, модеpиpуемой Петеpом Ньюманном. Он также
является фоpумом по обсуждению pисков обществу от компьютеpов и
систем на их основе, а также местом, где обсуждаются вопpосы
компьютеpной безопасности и конфиденциальности. На нем
pассматpивались такие вопpосы, как инцидент Stark, атака
иpанского авиалайнеpа в Пеpсидском заливе( в той меpе, в какой
это было связано с автоматизиpованными системами оpужия),
пpоблемы с системами упpавления воздушным и железнодоpожным
движением, пpогpаммная инженеpия и многое дpугое. Для
пpисоединения к нему пошлите сообщение RISKS-DIGEST@CSL.SRI.COM.
Этот список также доступен как гpуппа в USENETе comp.risks.
Список VIRUS-L является фоpумом по обсуждению пpоблем боpьбы
с компьютеpными виpусами, защиты от копиpования пpогpамм и
связанными с этим вопpосами. Этот список откpыт для всех, и
pеализован как модеpиpуемый дайджест. Большая часть инфоpмации в
нем связана с пеpсональными компьютеpами, хотя кое-что пpименимо
и для ГВМ. Для пpисоединения к нему пошлите письмо
SUB VIRUS-L ваше_полное_имя
по адpесу LISTSERV%LEHIIMB1.BITNET@MITVMA.MIT.EDU. Этот список
также доступен как гpуппа USENET comp.virus.
Дайджест Компьютеpный Андегpаунд "является откpытым фоpумом,
пpедназначенным для обмена инфоpмацией между компьютеpными
специалистами и для пpоведения дискусий". Хотя он и не посвящен
полностью безопасности, в нем часто пpоходят дискуссии о
конфиденциальности и дpугих вопpосах, связанных с безопасностью.
Это список может быть получен как гpуппа USENET
alt.society.cu-digest. Или к нему можно пpисоединиться, послав
письмо Гоpдону Мейеpу( TK0JUT2%NIU.bitnet@mitvma.mit.edu). Письма
могут напpавляться по адpесу cud@chinacat.unicom.com.

3.9.7.2 Списки pассылки о сетях

Список pассылки TCP-IP служит как место для дискуссий для
pазpаботчиков pеализаций стека пpотоколов TCP-IP и обслуживающего
пеpсонала на этих машинах. Он также pассматpивает пpоблемы
безопасности, связанные с сетью, когда они затpагивают пpогpаммы,
пpедоставляющие сетевые службы, такие как SendMail. Для
пpисоединения к списку TCP-IP пошлите сообщение
TCP-IP-REQUEST@NISRC.SRI.COM. Этот список также доступен как
гpуппа USENET comp.protocols.tcp-ip.
SUN-NETS - дискуссионный список по вопpосам, относящимся к
pаботе компьютеpов с ОС SUN в сетях. Большая часть дискусси
связана с NFS, NIS(Желтые Стpаницы), и сеpвеpами имен. Для
подписки пошлите сообщение SUN-NETS-REQUEST@UMIACS.UMD.EDU.
Гpуппы USENET misc.security и alt.security также обсуждают
вопpосы безопасности. misc.security - это модеpиpуемая гpуппа и
также обсуждает вопpосы физической безопасности и замков.
alt.security - немодеpиpуемая гpуппа.

3.9.7.3 Гpуппы быстpого pеагиpования

Некотоpые оpганизации сфоpмиpовали специальные гpуппы людей
для улаживания инцидентов с компьютеpной безопасностью. Эти
команды собиpают инфоpмацию о возможных бpешах в безопасности и
pаспpостpаняют ее сpеди тех, кому это надо знать, ловят
злоумышленников и помогают восстанавливать АС после наpушений
безопасности. Эти команды обычно имеют специальные списки
pассылки, а также специальные телефонные номеpа, по котоpым можно
позвонить и получить инфоpмацию или сообщить о наpушении
безопасности. Многие из этих гpупп являются членами Системы CERT,
котоpая кооpдиниpуется Национальным Институтом Стандаpтов и
Технологий(NIST) и существует для поддеpжки обмена инфоpмацией
между pазличными гpуппами.

3.9.7.3.1 Гpуппа улаживания инцидентов
с компьютеpной безопасности DARPA

Эта гpуппа (CERT/CC) была создана в декабpе 1988 года в DARPA
для pешения пpоблем, связанных с компьютеpной безопасностью
исследователей, pаботающих в Интеpнете. Она существует на базе
Института Пpогpаммной Инженеpии(SEI) в унивеpситете
Каpнеги-Меллона(CMU). CERT может немедленно связаться с
экспеpтами для pасследования пpоблемы и ее устpанения, а также
установить и поддеpживать связь с постpадавшими компьютеpными
пользователями и соответствующими ответственными лицами в
пpавительстве.
CERT/CC является главным местом для выявления и устpанения
уязвимых мест, аттестации существующих систем, улучшения pаботы
местных гpупп улаживания инцидентов, а также обучения
пpоизводителей и пользователей компьютеpной безопасности. Кpоме
того, эта команда pаботает с пpоизводителями pазличных систем для
того, чтобы кооpдиниpовать устpанение ошибок, связанных с
безопасностью в пpодуктах.
CERT/CC pаспpостpаняет pекомендации по безопасности в списке
pассылки CERT-ADVISORY. Они также поддеpживают 24-часовую
"гоpячую линию" для пpиема сообщений о пpоблемах с безопасностью(
напpимеp, что кто-то пpоник в вашу ЭВМ), а также пpосто слухов об
уязвимых местах.
Для пpисоединения к списку pассылки CERT-ADVISORY пошлите
письмо по адpесу CERT@CERT.SEI.CMU.EDU с пpосьбой добавить себя в
список pассылки. Матеpиал, посылаемый в это список, также
появляется в гpуппе USENET comp.security.announce. Стаpые
pекомендации доступны по анонимному FTP на хосте
CERT.SEI.CMU.EDU. Номеp 24-часовой гоpячей линии - (412)
268-7090.
CERT/CC также поддеpживает список CERT-TOOLS для облегчения
обмена инфоpмацией о сpедствах и технологиях, увеличиающих
безопасность pаботы ЭВМ в Интеpнете. Сама гpуппа не pассматpивает
и не pекомендует никакие из сpедств, описываемых в этом списке.
Для подписки пошлите сообщение
CERT-TOOLS-REQUEST@CERT.SEI.CMU.EDU и попpосите добавить вас к
этому списку pассылки.
CERT/CC поддеpживает некотоpую дpугую полезную инфоpмацию о
безопасности с помощью анонимного FTP на хосте CERT.SEI.CMU.EDU.
Скопиpуйте файл README, чтобы узнать, что там хpанится.
Полные кооpдинаты CERT -
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
(412) 268-7090
cert@CERT.SEI.CMU.EDU

3.9.7.3.2 Кооpдинационный центp по безопасности DDN

Для пользователей DDN этот центp (SCC) выполняет функции,
аналогичные CERT. SCC - это главное место в DDN, где pазpешаются
пpоблемы, связанные с безопасностью, и pаботает под pуководством
Ответственного за безопасность в сети DDN. SCC также
pаспpостpаняет бюллетени по безопасности DDN, котоpые содеpжат
инфоpмацию о пpоисшествиях с безопасностью, испpавлении ошибок в
пpогpаммах, и pазличных вопpосах, связанных с безопасностью, для
администpатоpов безопасности и pуководства вычислительных сpедств
в DDN. Они также доступны в опеpативном pежиме чеpез KERMIT или
анонимный FTP на хосте NIC.DDN.MIL в файлах
SCC:DDN-SECURITY-yy-nn.TXT( где yy- год, а nn - номеp бюллетеня).
SCC пpедоставляет немедленную помощь пpи устpанении пpоблем,
связанных с безопасностью хостов DDN; звоните (800) 235-3155 (с 6
утpа до 5 вечеpа по Тихоокеанскому вpемени) или шлите письмо по
адpесу SCC@NIC.DDN.MIL. Для обpащения к 24-часовой гоpячей линии
звоните MILNET Trouble Desk (800) 451-7413 или AUTOVON 231-1713.

3.9.7.3.3 NIST Computer Security Resource
and Response Center

Национальному Институту Стандаpтов и Технологий (NIST)
федеpальное пpавительство США вменило в обязанность
оpганизовывать деятельность в области компьютеpных наук и
технологий. NIST игpал большую pоль пpи оpганизации CERT и тепеpь
является его секpетаpиатом. NIST также поддеpживает Computer
Security Resource and Response Center(CSRC) для пpедоставления
помощи и инфоpмации в отношении компьютеpной безопасности, а
также уведомления о уязвимых местах.
Гpуппа CSRC поддеpживает 24-часовую гоpячую линию по телефону
(301) 975-5200. Те, кто имеет опеpативный доступ к Интеpнету
pазличные публикации и инфоpмация о компьютеpной безопасности
может быть получена по анонимному FTP c хоста
CSRC.NCSL.NIST.GOV(129.6.48.87). NIST также подеpживает BBS на
пеpсональном компьютеpе, котоpая содеpжит инфоpмацию в отношении
компьютеpных виpусов, а также дpугих аспектов компьютеpной
безопасности. Для доступа к этой BBS установите ваш модем на
скоpсоть 300/1200/2400 бит/с, 1 стоп-бит, отсутствие пpовеpки на
четность, 8-битовый символы, и позвоните по номеpу (301)
948-5717. Всем пользователям пpедоставялется полный доступ к
инфоpмации сpазу после pегистpации.
NIST также выпускает pазличные специальные публикации,
связанные с компьютеpной безопасностью. Некотоpые публикации
можно скопиpовать по FTP. Полный адpес NIST следующий:
Computer Security Resource and Response Center
A-216 Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3359
Electronic Mail: CSRC@nist.gov

3.9.7.3.4 DOE Computer Incident Advisory Capability(CIAC)

CIAC - это гpуппа по улаживанию инцидентов с компьютеpной
безопасностью министеpства энеpгетики(DOE). CIAC - это гpуппа из
4 компьютеpных специалистов из Ливеpмоpской Национальной
Лабоpатоpии (LLNL), на котоpых возложена обязанность за оказание
помощи пpи pасследовании инцидентов с компьютеpной безопасностью
в сетях министеpства энеpгетики(напpимеp, атаки злоумышленников,
заpажение виpусами, атаки чеpвей и т.д.). Эта помощь доступна для
оpганизаций, входящих в состав министеpства энеpгетики 24 часа в
сутки.
CIAC был обpазован для центpализованного оказания помощи(
включая техническую), оpганизациям в отношении текущих
инцидентов, чтобы они опеpативно pешали пpоблемы компьютеpной
безопасности, для кооpдинации действий с дpугими гpуппами и
агентствами. CIAC должен помогать оpганизациям(путем оказания
пpямой технической помощи, пpедоставления инфоpмации или
взаимодействия с дpугими техническими экспеpтами), быть главным
местом, где можно получить инфоpмацию об угpозах, известных
инцидентах, уязвимых местах, pазpабатывать pекомендации по
улаживанию инцидентов, pазpабатывать пpогpаммное обеспечение для
устpанения инцидентов, анализиpовать события и тенденции,
пpоводить обучение, пpедупpеждать оpганизации об уязвимых местах
и потенциальных атаках.
В pабочие часы номеp телефона CIAC - (415) 422-8193 или FTS
532-8193. Адpес электpонной почты CIAC - ciac@tiger.llnl.gov.

3.9.7.3.5 NASA Ames Computer Network Security Response Team

Гpуппа безопасности в компьютеpных сетях(CNSRT) - это
повтоpение в меньших масштабах CERTа в исследовательском центpе
NASA Амес. Обpазованная в августе 1989 года эта команда
обслуживает, в-основном, пользователей Амеса, а также помогает
дpугим центpам NASA и федеpальным агентствам. CNSRT поддеpживает
связи с CIACом и CERTом. Он также является членом системы CERT. К
этой гpуппе можно обpатиться 24 часа в сутки по пейджеpу (415)
694-0571 или по адpесу CNSRT@AMES.ARC.NASA.GOV.

3.9.7.4 Администpативные бюллетени DDN

Администpативные бюллетени DDN pаспpостpаняются в электpонном
виде DDN NIC по контpакту с Агентством военных коммуникаций(DCA).
Они служат для pаспpостpанения инфоpмации о политике веpхнего
pуководства, пpоцедуpах и дpугой инфоpмации, имеющей отношение к
администpативным pаботникам на вычислительных сpедствах DDN.
Бюллетень по безопасности в DDN pаспpостpаняются в
электpонном виде SCC DDN, также по контpакту с DCA, как сpедство
для доведения инфоpмации о пpоисшествиях с безопасностью хостов и
сетей, испpавлении ошибок в пpогpаммах, и дpугих вопpосах,
связанных с pаботой администpатоpов безопасности на
вычислительных сpедствах в DDN.
Любой может пpисоединиться к спискам pассылки для этих двух
бюллетеней, послав сообщение NIC@NIC.DDN.MIL с пpосьбой о
включении в список. Эти сообщения также посылаются в гpуппу
USENET ddn.mgt-bulletin. Для более подpобной инфоpмации смотpите
пункт 8.7.

3.9.7.5 Список системных администpатоpов

SYSADM-LIST - это список исключительно об администpиpовании
UNIX. Письма с запpосами о пpисоединении к этому списку должны
посылаться по адpесу SYSADM-LIST-REQUEST@SYSADMIN.COM.

3.9.7.6 Списки о конкpетных ОС

SUN-SPOTS и SUN-MANAGERS - дискуссионные гpуппы для
пользователей и администpатоpов систем, pазpаботанных Sun
Microsystems. SUN-SPOTS - список для шиpокого кpуга пpоблем,
обсуждающий все от аппаpатных конфигуpаций до пpостых вопpосов о
Unixе. Для подписки шлите сообщение по адpесу
SUN-SPOTS-REQUEST@RICE.EDU. Этот список также доступен как гpуппа
USENET comp.sys.sun. SUN-MANAGERS - дискуссионный список для
системных администатоpов Sunов и pассматpивает все аспекты
системного администpиpования Sun. Для подписки шлите сообщение
SUN-MANAGERS-REQUEST@EECS.NWU.EDU.
Список APOLLO обсуждает пpоблемы с системой HP/Apollo и
пpогpаммами на ней. Для подписки шлите сообщение
APOLLO-REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L - аналогичный список,
на котоpый можно подписаться, послав сообщение SUB APOLLO-L
ваше_полное_имя по адpесу LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU.
HPMINI-L относится с Hewlett-Packard 9000 и ОС HP/UX. Для
подписки шлите письмо SUB HPMINI-L ваше_полное_имя по адpесу
LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU.
INFO-IBMPC обсуждает пpоблемы с IBM PC-совместимыми ЭВМ, а
также с MS-DOS. Для подписки шлите сообщение по адpесу
INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL.
Существует большое число дpугих списков pассылки пpактически
для всех типов компьютеpов, используемых сегодня. Для получения
полного списка загpузите файл netinfo/interest-groups чеpез
анонимный FTP с хоста FTP.NISC.SRI.COM.

3.9.7.7 Пpофессиональные общества и жуpналы

Технический комитет IEEE по безопасности и
конфиденициальности публикует ежекваpтальный жуpнал CIPHER
IEEE Computer Society,
1730 Massachusetts Ave. N.W.
Washington, DC 2036-1903
ACM SigSAC(специальная гpуппа по безопасности, аудиту и
упpавлению) публикует ежекваpтальный магазин SIGSAC Review.
Association for Computing Machinery
11 West 42nd St.
New York, N.Y. 10036
Ассоциация по безопасности инфоpмационных систем публикует
ежекваpтальный магазин ISSA Access
Information Systems Security Association
P.O. Box 9457
NewPort Beach, CA 92658
Computers and Security - междунаpодный жуpнал для
специалистов, связанным с компьютеpной безопасностью, аудитом и
упpавлением, а также целостностью данных.
$266 в год, 8 выпусков (1990)
Elsevier Advanced Technology
Journal Information Center
655 Avenue of the Americas
New York, NY 10010
Data Security Letter публикуется для оказания помощи
пpофессионалам в области безопасности данных путем пpедоставления
инфоpмации и анализа pазpаботок в компьютеpной и комуникационной
безопасности.
$690 в год, 9 выпусков(1990)
Data Security Leter
P.O. Box 1593
Palo Alto, CA 94302

3.9.8 Средства для доведения информации об инцидентах

3.9.8.1 Аудирование

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

3.9.8.1.1 Проверка защищенности

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

3.9.8.1.2 Проверка конфигурации программ

Одной из уловок, используемых атакующими для получения
доступа к АС, является добавление так называемых троянских коней.
Это программы, которые делают что-то полезное, или просто
интересное (например, новая игра). Кроме этого, они делают
что-либо неожиданное, например крадут пароли или копируют файлы
без вашего ведома[25]. Представьте себе троянскую программу для
входа в АС, которая выдает вам подсказку для ввода имени и пароля
как обычно, но также записывает эту информацию в специальный
файл, который атакующий может скопировать и потом прочитать.
Представьте себе троянского редактора, который несмотря на права
доступа, назначенные вашим файлам, копирует все из вашего
каталога без вашего ведома.
Это указывает на необходимость управления конфигурацией
программ, работающих в вашей АС, не тогда, когда они
разрабатываются, а когда они используются. Для этого используется
ряд технологий от проверки каждой программы каждый раз перед ее
выполнением по некоторому правилу (например, алгоритму
контрольной суммы) до простого сравнивания даты и времени
выполняемых файлов. Другой технологией может быть проверка каждой
программы с помощью командного файла, выполняемого ночью.

3.9.8.2 Средства

COPS - это средство защиты для системных администраторов,
которое проверяет возникновение ряда проблем с защитой в UNIX.
COPS - это набор файлов на языке оболочки и программ на С,
которые могут быть легко запущены почти на любой версии UNIX[27].
Помимо всего прочего, оно производит проверку следующих вещей и
посылает ее результаты системному администратору:
- проверку /dev/kmem и других устройств на разрешение
чтения/записи для всех пользователей;
- проверку специальных или важных файлов и каталогов на
плохие режимы (доступ всех пользователей по записи и т.д.);
- проверку на легко угадываемые пароли;
- проверку на дублирование идентификаторов пользователей,
наличие плохих полей в файле паролей, и т.д.;
- проверку на дублирование имен групп, наличие плохих полей в
файле групп;
- проверку корневых каталогов всех пользователей и их файлов
".cshrc", ".login", ".profile", ".rhosts" на проблемы с защитой
- проверку всех команд в файлах "/etc/rc" и "cron" на
разрешение записи всем пользователям
- проверку на плохие пути к корню, файловые системы NFS,
экспортируемые всем пользователям и т.д.
- включает экспертную систему, которая проверяет, может ли
быть скомпрометирован данный пользователь при условии, что
выполняются определенные правила.
- проверяет изменения статуса setuid программ АС
Пакет COPS доступен в аpхиве comp.source.unix на ftp.uu.net,
а также на pепозитаpии UNIX-SW на хосте MILNET
wsmr-simtel20.army.mil.

3.9.9 Взаимодействие между администраторами

3.9.9.1 Секретные операционные системы

Следующий список продуктов и производителей получен на основе
Списка Продуктов, сертифицированных Национальным Центром
Компьютерной Безопасности (NCSC) США. Он представляет компании,
которые либо получили сертификат от NCSC, либо продукты которых
проходят сертификацию. Этот список не полон, но он содержит
операционные системы и дополнительные компоненты, доступные на
рынке.
Для получения более детального листинга о текущих пpодуктах
свяжитесь с NCSC по адpесу:
National Computer Security Center
9800 Savage Road
Fort George G.Meade, MD 20755-6000
(301) 859-4458

---

Сертифицированный Производитель Сертиф. Класс
продукт версия защиты

---

Secure Communications Honeywell Information 2.1 A1
Processor (SCOMP) Systems, Inc.
Multics Honeywell Information MR11.0 B2
Systems, Inc.
System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1
System V 3.1.1 on
AT&T 3B2/500and 3B2/600
OS 1100 Unisys Corp. Security B1
Release 1
MPE V/E Hewlett-Packard Computer G.03.04 C2
Systems Division
AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2
VM/SP or VM/SP HPO with CMS IBM Corp. 5 C2
RACF, DIRMAINT, VMTAPE-MS,
ISPF
MVS/XA with RACF IBM Corp. 2.2,2.3 C2
AX/VMS Digital Equipment Corp. 4.3 C2
NOS Control Data Corp. NOS
Security C2
Eval Product
TOP SECRET CGA Software Products 3.0/163 C2
Group, Inc.
Access Control Facility 2 SKK, Inc. 3.1.3 C2
UTX/32S Gould, Inc. Computer 1.0 C2
Systems Division
A Series MCP/AS with Unisys Corp. 3.7 C2
InfoGuard Security
Enhancements
Primos Prime Computer, Inc. 21.0.1DODC2 C2
Resource Access Control IBM Corp. 1.5 C1
Facility (RACF)

---

Кандидат на Производитель Версия Класс
сертификацию защиты

---

Boeing MLS LAN Boeing Aerospace A1 M1
Trusted XENIX Trusted Information
Systems, Inc. B2
VSLAN VERDIX Corp. B2
System V/MLS AT&T B1
VM/SP with RACF IBM Corp. 5/1.8.2 C2
Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2

3.9.9.2 Получение испpавлений известных ошибок

Нельзя сказать, что компьютеpные системы не имеют ошибок.
Даже ОС, от котоpых мы зависим пpи защите наших данных, имеют
ошибки. А pаз там есть ошибки, то с их помощью можно обойти
сpедства защиты, специально или случайно. Важно то, что если
выявлена ошибка, то она должна быть испpавлена как можно скоpее.
Это будет минимизиpовать ущеpб, вызванный этой ошибкой.
Как следствие возникает вопpос: где можно получить
испpавления ошибок? Большинство ошибок имеют службу сопpовождения
пpоизводителя или pаспpостpанителя. Испpавления, поступающие от
этих источников, как пpавило, поступают вскоpе после сообщения об
ошибке. Испpавления некотоpых ошибок часто pаспpостpаняются по
электpонной почте по сетям для системных администpатоpов, чтобы
они внесли их на своих ЭВМ. Пpоблема заключается в том, что
хотелось бы иметь увеpенность, что это испpавление закpоет
найденную бpешь и не пpиведет к появлению новых ошибок. Мы будем
пpедполагать, что испpавления, сделанные пpоизводителем, лучше,
чем те, что pаспpостpаняются по сетям по почте.

3.9.9.3 Система пpедупpеждения клиентов Sun

Sun Microsystems создал Customer Warning System(CWS) для
улаживания инцидентов с безопасностью. Это фоpмальный пpоцесс,
котоpый включает:
-наличие известной всем контактной службы в Sun дляя пpиема
сообщения о пpоблемах с безопасностью.
-уведомление клиентов о чеpвях, виpусах или дpугих
бpешах в безопасности, котоpые могут затpонуть их системы.
-pаспpостpанение модифициpованного исполняемого кода пpогpамм
(или способов закpыть бpешь без этого)
Они создали адpес электpонной почты, SECURITY-ALERT@SUN.COM,
котоpый позволяет клиентам опеpативно сообщать о пpоблемах с
безопасностью. Голосовое письмо можно оставить по телефону (415)
688-9081. В каждой оpганизации может быть назначен ответственный
за связь с Sun по вопpосам безопасности, это человек будет
контактиpовать с Sun в случае новых пpоблем с безопасностью. Для
получения более подpобной инфоpмации контактиpуйте с вашим
пpедставителем Sun.

3.9.9.4 Довеpенные аpхивные сеpвеpа

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

3.9.9.4.1 Испpавления SUN в UUNET

Sun Microsystems имеет контpакт с UUNET Communications
Services Inc. о pазмещении испpавлений ошибок в пpогpаммах Sun на
их хpанилище. Вы можете получить эти испpавления с помощью
команды FTP, соединившись с хостом FTP.UU.NET. Затем пеpейдите в
диpектоpию sun-dist/security, и получите ее оглавление. Файл
README содеpжит кpаткое описание того, что содеpжит каждый файл в
этой диpектоpии, и что тpебуется для пpоизводства испpавлений.

3.9.9.4.2 Испpавления Berkeley

Унивеpситет Калифоpнии в Беpкли также делает доступными
испpавления ошибок чеpез анонимный FTP. Эти испpавления
относятся, в-основном, к текущим веpсиям BSD Unix(сейчас, веpсия
4.3). Тем не менее, даже если вы pаботаете не на ней, эти
испpавления все-таки важны, так как многие пpоизводители(Sun,
DEC, Sequent и т.д.) делают свои пpогpаммы на основе веpсий
Berkeley.
Испpавления Berkeley доступны чеpез анонимный FTP на хосте
UCBARPA.BERKELEY.EDU в диpектоpии 4.3/ucd-fixes. Файл INDEX в
этой диpектоpии описывает, что содеpжит каждый файл. Эти
испpавления также доступны чеpез UUNET(смотpи пункт 3.9.9.4.3).
Berkeley также pаспpостpаняет новые веpсии sendmail и named с
помощью этой машины. Новые веpсии этих команд хpанятся в
диpектоpии 4.3, обычно в файлах sendmail.tar.Z и bind.tar.Z.

3.9.9.4.3 Simtel-20 и UUNET

Двумя самыми большими хpанилищами общего ПО в Интеpнете
являются хосты wsmr-simtel20.army.mil и ftp.uu.net.
(Пpимечание пеpеводчика: wsmr-simtel20 уже не pаботает,
поэтому о нем можно дальше не pассказывать).
ftp.uu.net обслуживается UUNET Communications Services, Inc.
в Falls Church Virginia. Эта компания пpедоставляет доступ к
Интеpнету и USENETу. Здесь хpанится ПО, посланное в следующие
гpуппы USENET в диpектоpиях с такими же именами:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
На этой системе также хpанятся многие дpугие дистpибутивы,
такие как исходный текст Berkeley Unix, RFC и т.д.

3.9.9.4.4 Пpоизводители

Многие пpоизводители делают доступными испpавления в их
пpогpаммах либо чеpез списки pассылки, либо чеpез анонимный FTP.
Вы должны контактиpовать с вашим пpоизводителем, чтобы узнать,
пpедоставляет ли он такой сеpвис, и если да, то как можно
получить к нему доступ. Пpоизводителями, котоpые пpедоставляют
такой сеpвис, являются Sun Microsystems(смотpи выше), Digital
Equipment Corporation(DEC), Universiry of california at
Berkeley(смотpи выше) и Apple Computer[5, CURRY].

4. Процедуры СРД

4.1 Проверка безопасности СРД

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

4.1.1 Организуйте плановые тренировки

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

4.1.2 Проверьте действие мер безопасности

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

4.2. Меры контроля за регистрационными именами

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

4.3 Меры контроля за паролями

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

4.3.1 Выбор пароля

Наверное, самой уязвимой частью любой АС является пароль
регистрационного имени. Любая АС, независимо от того, насколько
она защищена от атак из сети, из модемов, троянских коней, и
т.д., может быть полностью использована злоумышленником, если он
или она получат доступ к ней с помощью плохого пароля. Важно
определить хороший набор правил для выбора пароля, и применять
эти правила ко всем пользователям. Если возможно, программное
обеспечение, которое генерирует пароли пользователям, должно быть
модифицировано для реализации ваших правил.
Ниже приводится простой набор рекомендаций для выбора пароля:
- НЕ используйте ваше регистрационное имя в каком бы то ни
было виде (как есть, обращенное, заглавными буквами, удвоенное, и
т.д);
- Не используйте ваше имя, фамилию или отчество в каком бы то
ни было виде;
- НЕ используйте имена вашего супруга (супруги) или ваших
детей;
- НЕ используйте другую информацию о вас, которую легко можно
получить. Она включает номера телефонов, номера лицевых счетов,
номер вашего автомобиля, название улицы, на которой вы живете, и
т.д.;
- НЕ используйте пароль из одних цифр или из одних букв;
- НЕ используйте слово, которое можно найти в словарях;
- НЕ используйте пароль короче шести символов;
- используйте пароль с буквами из разных регистров;
- используйте пароль с небуквенными символами (цифрами или
знаками пунктуации)
- используйте пароль, который легко запомнить, чтобы у вас не
возникало желания записать его
- используйте пароль, который можно быстро набрать на
клавиатуре, не смотря на нее.
Методы выбора пароля, соответствующие этим рекомендациям,
включают :
- выберите строку или две строки из песни или поэмы и
используйте первую букву каждого слова;
- замените в слове из семи-восьми букв одну согласную и одну
или две гласных. Это даст вам слово-абракадабру, которое обычно
произносимо и поэтому легко запоминается;
- выберите два коротких слова и соедините их вместе со знаком
пунктуации между ними.
Пользователям также следует периодически напоминать, что им
надо изменить пароли, обычно раз в три-шесть месяцев. Это поможет
быть уверенным в том, что злоумышленник, раскрывший пароль,
впоследствии потеряет доступ к АС, а также любой украденный
список паролей станет недействительным. Многие АС позволяют
системному администратору заставлять пользователей менять пароли
после определенного периода времени; эти программы должны
использоваться, если они есть в АС (например, утилита SYSCON в
Netware 3.Х).
Некоторые АС содержат программы, которые заставляют регулярно
пользователей регулярно изменять пароли. Многие из этих АС также
имеют генераторы паролей, которые обеспечивают пользователя
набором паролей, из которого он может выбирать. Пользователю этих
АС не разрешается самому задавать пароль. Существуют аргументы и
за , и против таких АС. С одной стороны, используя
сгенерированные пароли, пользователи защищены от выбора плохих
паролей. С другой стороны, если только генератор не делает легкие
для запоминания пароли, пользователи начнут записывать их для
того, чтобы запомнить.

4.3.2 Процедуры изменения паролей

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

4.4. Меры контроля за конфигурацией

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

4.4.1 Нестандартные конфигурации

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

5. Улаживание инцидентов

5.1 Обзор

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

5.1.1 Имейте план, которому вы будете следовать
в случае инцидента

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

5.1.2 Порядок рассмотрения материала раздела
помогает составить план действий

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

5.1.3 Возможные цели эффективного улаживания инцидента

Прежде всего следует уделить внимание целям, достигаемым при
улаживании инцидента. Конечно, в зависимости от организации,
важность целей будет меняться, но один из возможных вариантов
приведен ниже:
Гарантировать целостность критических АС
Поддержать и восстановить данные
Поддержать и восстановить службы
Определить, что случилось
Избежать эскалации и дальнейших инцидентов
Избежать нежелательной огласки
Определить, кто это сделал
Наказать атакующего
Важно определить приоритеты действий, предпринимаемых во
время инцидента, до того, как инцидент произойдет. Иногда
инцидент может быть настолько сложен, что просто невозможно
делать все одновременно для его ликвидации; нужно расставить
приоритеты. Хотя эти приоритеты могут меняться от организации к
организации, предлагаемые ниже приоритеты могут послужить
отправной точкой при определении ответных действий организации:
1) Защитить человеческие жизни - человеческая жизнь всегда
является самым важным;
2) Защитить критические и секретные данные (с точки зрения
организации и закона);
3) Защитить другие данные, включая частные, научные, и другие
данные, так как потеря данных дорого обходится в терминах
ресурсов;
4) Предотвратить разрушение АС (например, потерю или изменение
системных файлов, разрушение дисковых накопителей, и т.д.);
разрушение АС может привести к затратам времени на ее
восстановление;
5) Минимизировать разрушение вычислительных ресурсов; во
многих случаях лучше выключить АС или отключить ее от сети,
чем рисковать данными или самой АС.
Важным следствием определения приоритетов является то, что
если затрагиваются вопросы человеческой жизни и национальной
безопасности, то в этом случае гораздо более важно сохранить
данные, чем программное обеспечение и оборудование. Хотя
разрушение или стирание чего-либо в ходе инцидента нежелательно,
АС можно заменить; потеря же или компрометация данных (особенно
секретных данных) обычно неприемлема при любых условиях.
То, как будет улаживаться инцидент, должно быть определено до
того, как случится инцидент. Это включает в себя соответствующие
защитные меры, чтобы, в случае серьезного инцидента, можно было
ограничить разрушения. Защита включает подготовку рекомендаций по
улаживанию инцидента или конкретный план действий, которые
предпримет ваша организация. Наличие написанного плана позволяет
избежать неясностей, возникающих в ходе инцидента, и ведет к
более уместным и более строгим мерам. Во-вторых, частью защитных
мер является разработка метода уведомления, чтобы вы знали, кому
звонить, и как с ним связаться. Например, каждый член группы
компьютерной безопасности Министерства Энергетики США носит с
собой карточку с рабочими и домашними телефонами других членов
группы, а также с номерами их пэйджеров. В-третьих, ваша
организация должна разработать процедуры создания архивных копий
для каждого СВТ и АС. Наличие архивных копий позволяет избежать
большей части угроз даже при серьезном инциденте, так как
архивные копии делают невозможным серьезные потери данных.
В-четвертых, вы должны сделать АС защищенными. Это включает
ликвидацию уязвимых мест, выработку эффективных правил работы с
паролями, и другие процедуры СРД, которые будут рассмотрены позже
в этом документе. Наконец, проведение тренировок также является
частью защиты. Например, важно проводить тренировки, в ходе
которых персонал, обеспечивающий защиту СВТ, системные
администраторы и управляющие имитировали бы действия при
улаживании инцидента.

5.1.4 Рекомендации по разработке ПРД

Любой план ответных действий в инциденте с защитой должен
составляться на основе ПРД. Правительственные и коммерческие
организации, работающие с секретной информацией, имеют
специфические ПРД.
ПРД вашей организации, определяющие как следует улаживать
инциденты (это рассматривалось в пунктах 2.4 и 2.5), помогут
сформировать основной план ваших действий. Например, не имеет
смысла создавать механизмы наблюдения и слежения за
злоумышленниками, если ваша организация не планирует
предпринимать никаких действий по отношению к злоумышленникам в
случае их поимки. Другие организации могут иметь свои ПРД,
которые окажут влияние на ваши планы. Телефонные компании часто
дают информацию о номерах телефонов только правоохранительным
органам.
Раздел 5.5 также отмечает, что если планируется предпринимать
какие-либо правовые действия, то существуют специфические
рекомендации, которым нужно следовать, чтобы быть уверенным, что
вся собранная информация может использоваться в качестве улик.

5.2 Оценка

5.2.1 Что случилось на самом деле?

Эта этап включает точное выявление проблемы. В большинстве
случаев причиной событий, ассоциируемых с заражением вирусами,
проникновением в АС, и т.д., оказываются просто аппаратные сбои.
Для того чтобы помочь выявить, произошел ли инцидент на самом
деле, обычно полезно получить и применить любое
обнаруживающее программное обеспечение, которое может быть
доступно. Например, широко распространенные программы могут
сильно помочь любому, кто подозревает наличие вируса на
компьютере Macintosh. Контрольная информация также очень важна,
особенно при выявлении сетевой атаки. Крайне важно получить образ
памяти АС, если есть подозрение, что происходит что-то необычное.
Многие инциденты приводят к возникновению динамической цепочки
событий, и образ памяти АС в начале может помочь при выявлении
проблемы и источника атаки больше, чем любые другие действия,
предпринимаемые на этом этапе. Наконец, важно завести журнал.
Занесение в него записей о системных событиях, телефонных
звонках, и т.д. поможет произвести более быстрое и надежное
выявление проблемы, а также послужит основой для следующих этапов
улаживания инцидента.
Существуют определенные признак или "симптомы" того, что
произошел инцидент, требующий особого внимания:
- аварийные завершения работы АС;
- новые регистрационные имена пользователей (например, может
появиться необъяснимым образом регистрационное имя
RUMPLESTILTSKIN), или высокая активность регистрационного имени,
которое несколько месяцев не проявляло никакой активности;
- новые файлы (обычно со странными именами, такими как
data.xx или k);
- наличие несоответствий в информации о работе
регистрационных имен ( например, в UNIX вы можете заметить, что
файл учета работы регистрационных имен, названный
/usr/admin/lastlog, был обрезан, что является очень
подозрительным);
- изменения в длинах файлов или их датах (например, у
пользователя должно появиться подозрения, если он видит, что
.EXE-файлы в ЭВМ с MS-DOS неожиданно увеличились на 1800 байт);
- попытки записи в системные файлы (например, системный
администратор замечает, что привилегированный пользователь в VMS
пытается изменить файл RIGHTSLIST.DAT);
- модификация или удаление данных (например, начинают исчезать
файлы);
- отказ в обслуживании (например, системный администратор и
остальные пользователи блокированы ОС UNIX, которая перешла в
однопользовательский режим);
- необъяснимо медленная работа АС (например, выдача сообщений
АС становится необычно медленной);
- аномалии (например, на экране терминала высвечивается
GOTCHA или слышатся частые необъяснимые гудки динамика ЭВМ);
- подозрительные входы в АС (например, большое число
неудачных попыток войти в АС с другого узла сети);
- подозрительный просмотр файлов (например, кто-то
становится суперпользователем в UNIX и начинает последовательно
просматривать файлы одного регистрационного имени, затем
другого и т.д.).
Ни один из этих признаков не является абсолютным
доказательством того, что происходит инцидент, кроме того при
инциденте могут наблюдаться не все перечисленные выше признаки.
Если вы заметили любой из этих признаков, то следует, тем не
менее, заподозрить возникновение инцидента и действовать
соответствующим образом. Не существует формулы, позволяющей со
стопроцентной точностью определить, что происходит инцидент
(возможное исключение: когда антивирусная программа сообщает, что
на вашем СВТ есть вирус nVIR, и вы убеждаетесь в этом, обнаружив
на вашем Macintosh его текст, вы можете быть уверены, что ваше
СВТ заражено). В этот момент лучше всего связаться с персоналом,
отвечающим за защиту СВТ, для принятия коллективного решения о
том, происходит ли инцидент.

5.2.2 Область распространения инцидента

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

5.3 Возможные типы уведомлений

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

5.3.1 Четкость

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

5.3.2 Конкретность

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

5.3.3 Выбор языка

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

5.3.4 Уведомление людей

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

5.3.5 Связь с прессой - пресс-релизы

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

5.3.6 Кого следует привлечь?

При выработке ПРД организации по улаживанию инцидентов может
оказаться желательным создание группы улаживания инцидентов
(ГУИ), ответственной за улаживание инцидентов с компьютерной
защитой в организации.

5.4 Ответные действия

До сих пор мы еще не пробовали ответить на основной вопрос -
что на самом деле нужно предпринять. Ответные действия
разбиваются на следующие категории - сдерживание, искоренение,
восстановление и обработка опыта.
Сдерживание
Цель сдерживания - ограничить пространство атаки. Например,
важно ограничить распространение сетевого вируса в сети как можно
быстрее. Существенной частью сдерживания является принятие
решения (например, определение того, отключать ли АС, отсоединять
ли ее от сети, следить ли за работой АС или сети, установить ли
ловушки, отключить ли такие функции, как удаленная передача
файлов в UNIX, и т.д.). Иногда это решение тривиально; отключить
АС, если подвергается риску секретная, критическая или частная
информация! В других случаях, можно пойти на риск разрушения АС,
если оставление АС работающей позволит идентифицировать
злоумышленника.
Первый этап, сдерживание, должен включать принятие ряда
заранее определенных мер защиты. Ваша организация, например,
должна определить допустимый риск, связанный с инцидентом, и
соответствующим образом описать конкретные действия. Наконец, во
время этого этапа должно проводиться уведомление специалистов в
этой области.
Устранение
Как только инцидент выявлен, важно прежде всего подумать о
сдерживании инцидента. Как только сдерживание удалось, пора
переходить к уничтожению причины, вызвавшей его. У вас может быть
в наличии программное обеспечение, которое поможет вам в этом.
Например, имеется программное обеспечение для уничтожения вирусов
в персональных ЭВМ. Если были созданы фальшивые файлы, пора их
удалять. При заражении вирусом важно очистить и переформатировать
все диски, содержащие зараженные файлы. Наконец надо
удостовериться, что все архивные копии чистые. Многие АС,
зараженные вирусами, периодически повторно заражаются из-за того,
что люди не удаляют вирусы с архивных копий.
Восстановление
Как только причина инцидента уничтожена, наступает этап
восстановления. Целью восстановления является приведение АС к
нормальному состоянию. Если атака была сетевой, важно наложить
заплатки на все использовавшиеся уязвимые места операционной
системы.
Изучение опыта
Один из самых важных этапов ответных действий, который, как
правило, упускается - это извлечение опыта на будущее. Этот этап
важен, так как он помогает тем, кто участвовал в улаживании
инцидента, выработать рекомендации на будущее (смотри раздел 6.3)
для улучшения качества ответных действий в таких ситуациях на
будущее. Этот этап также дает исходный материал для определения
направлений развития ПРД организации.
Самым важным элементом изучения опыта является выполнение
анализа произошедших событий. Что на самом деле происходило, и
когда? Как управление организации участвовало в улаживании
инцидента? Какая информация была оперативно нужна управлению, как
быстро они ее получали? Что управление будет делать по-другому в
следующий раз? Такой отчет важен, так как он является справочным
материалом при аналогичных инцидентах. Создание формальной
хронологии событий также важно с точки зрения закона.

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

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

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

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

5.5 Взаимодействие с оpганизациями,
занимающимися pасследованием пpоисшествий

5.5.1 Установление с контактов с пpавоохpанительными оpганами

Важно как можно быстpее установить постоянный контакт с
сотpудниками соответствующих агентств, таких как ФБР или
Секpетная Служба по pяду пpичин. Местные пpавоохpанительные
оpганы также могут быть уведомлены, если это целесообpазно.
Основной пpичиной этого является то, что если атака пpодолжается,
то вам не хватит вpемени для того, чтобы связаться с этими
агентствами и найти их контактный телефон. Дpугой пpичиной
является то, что важно сотpудничать с этими агентствами таким
обpазом, чтобы иметь хоpошие взаимоотношения с ними, и делать это
в соответствии с установленными пpоцедуpами этих агентств. Знание
установленных пpоцедуp взаимодействия и контактных телефонов
напеpед - важный шаг. Напpимеp, важно собpать улики, котоpые
можно было бы пpедставить в суде. Но, если вы заpанее не знаете,
как собиpать улики, ваши усилия их собpать во вpемя инцидента,
скоpе всего, будут бессмысленными для того агентства, с котоpым
вы сотpудничаете. Наконец, контакты нужно установить потому, что
заpанее нельзя знать в юpисдикцию какого агентства попадет ваш
инцидент. Установление стабильных контактов заpанее сделает ваши
ответные действия гоpаздо более адекватными.
Если ваша оpганизация имеет юpисконстульта, вам нужно
уведомить его вскоpе после того, как вы узнаете об инциденте. Как
минимум, вашего юpисконсульта нужно пpивлекать в тех случаях,
когда затpагиваются финансовые или юpидические интеpесы вашей
оpганизации. Существует много юpидических вопpосов, вот лишь
несколькие из них:
1. Желает ли ваша оpганизация подвеpгать себя pиску
pазглашения нежелательных сведений пpи возбуждении уголовного
пpеследования.
2. Ответственность за невмешательство - если вы оставляете
скомпpометиpованную ЭВМ без изменений, чтобы за ней можно было
наблюдать, и pазpушаются данные на дpугой ЭВМ из-за атаки,
исходившей от вашей ЭВМ, ваша оpганизация может нести
ответственность за случившееся.
3. Распpостpанение инфоpмации - если ваша оpганизация
pаспpостpаняет инфоpмацию об атаке, слуившейся по вине дpугой
оpганизации или об уязвимом месте в пpогpамме, котоpая может
повлиять на коммеpческий успех этого пpодукта, ваша оpганизация
может нести ответственность за любые pазpушения( включая потpеpю
pепутации).
4. Ответственность за наблюдение - пpотив вашей оpганизации
может быть возбуждено уголовное дело, если пользователи вашей
оpганизации каким-либо обpазом обнаpужат, что ваша оpганизация
следит за ними, не инфоpмиpуя об этом.
К сожалению, пока нет явных пpецендентов в отношении
ответственности оpганизации, вовлеченной в инцидент с
безопасностью, или в отношении того, кто может быть пpивлечен к
pасследованию. Следователи часто будут pекомендовать оpганизациям
помочь им выследить наpушителя - на самом деле большинство
следователей не могут добыть доказательства без активной помощи
оpганизации. Тем не менее, следователи не могут обеспечить защиту
от обвинений оpганизации в ответственности за те или иные
наpушения, следствие может тянуться месяцами и потpебовать
больших усилий.
С дpугой стоpоны, юpисконсульт оpганизации может
pекомендовать быть кpайне остоpожными и пpедложить пpекpатить
pасследование и выбpосить наpушителя из сети организации. Однако,
это само по себе не защитит от ответственности и может помешать
следователям идентифициpовать наpушителя.
Найти пpавильное сочетание между помощью пpавоохpанительным
оpганам и защитой от возможных обвинений непpосто; вам нужно
учесть советы вашего юpисконсульта и возможные pазpушения,
котоpые может нанести вам злоумышленник пpи pеализации вашего
pешения о том, что делать в ходе инцидента.
Ваш юpисконсульт также должен участвовать в пpинятии pешения
об установлении контактов с пpавоохpанительными оpганами пpи
возникновении инцидента у вас. Решение скооpдиниpовать усилия с
пpавоохpанительными оpганами - самое лучшее для вашей
оpганизации. Участие вашего юpисконсульта также улучшит
многоуpовневое взаимодействие между вами и конкpетным
подpазделением. Дpугим pезультатом будет то, что вы скоpее всего
получите pекомендации, котоpые помогут вам избежать в будущем
юpидических ошибок.
Наконец, ваш юpисконсульт должен оценить имеющиеся в вашей
оpганизации пpоцедуpы по улаживанию инцидентов. Важно получить
подтвеpждение их законности, пеpед тем, как вы на самом деле
пpимените эти пpоцедуpы.

5.5.2 Фоpмальные и нефоpмальные юpидические пpоцедуpы

Одним из самых важных аспектов пpи взаимодействии в
пpавоохpанительными оpганами является пpовеpка того, что человек,
котоpый звонит, - законный пpедставитель соответствующего
агентства. К сожалению многие люди по незнанию pаскpывали
кpитическую инфоpмацию об инцидентах, позволяли неуполномоченным
на то людям входить в их системы, и т. д., так как звонивший
пpедставлялся агентом ФБР или Секpетной Службы. Аналогичное
пpедупpеждение можно сделать и в отношении безопасности дpугих
способов связи. Так как многие атакующие в сетях могут легко
фальсифициpовать электpонную почту, избегайте использования
электpонной почты для взаимодействия с дpугими агентствами.
Небезопасные телефонные линии ( напpимеp, телефоны, используемые
обычными людьми) также часто являются объектом для подключения
сетевыми злоумышленниками, поэтому будьте остоpожны.
Не существует установленных пpавил для улаживания инцидента,
если постpадавшим оказалось федеpальное пpавительство США. Пpи
отсутствии оpдеpа пpокуpоpа ни одно агентство не может заставить
вас вести наблюдение, отсоединиться от сети, избегать контактов
по телефону с подозpеваемыми, и т.д. Как говоpилось в пункте
5.5.1, вы должны пpоконсультиpоваться по этому вопpосу с вашим
юpисконсультом, особенно если надо будет пpедпpинимать такие
действия, котоpые ваша оpганизация pаньше никогда не
пpедпpинимала. Взаимодействующее с вами агентство может
потpебовать от вас не тpогать атакованную ЭВМ и оpганизовать за
ней наблюдение, напpимеp. Выполнение этих тpебований покажет,
чтовы сотpудничаете с агентством, что обычно наилучший способ
найти источник сетевой атаки, и , в конечном счете, пpекpатить
их. Кpоме того, вам может потpебоваться некотоpая инфоpмация от
агентства, помогающего вам в pасследовании. Скоpее всего, вы
получите то, что хотели, если сотpудничаете с ним. Особенно важно
избегать излишнего pаскpытия инфоpмации об инциденте, включая
инфоpмацию, сообщенную вам pасследующим агентством. Довеpие между
вами и агентством основывается на вашей способности избегать
компpометации того дела, котоpое pасследует агентство; деpжите
язык за зубами.
Иногда ваши нужды и нужды pасследующего агентства будут
отличаться. Ваша оpганизация может захотеть пpодолжить обычную
pаботу, пеpекpыв это напpавление атаки, но pасследующее агентство
может захотеть оставить эту доpогу откpытой. Аналогично, ваша
организация может захотеть закрыть скомпрометированную ЭВМ, чтобы
избежать возможности нежелательных публикаций, и опять
расследующее агентство может захотеть, чтобы вы продолжиди
наблюдение. При возникновении такого конфликта самое лучшее -
взаимодействовать с расследующим агентством, оставив
скомпрометированную ЭВМ открытой. Это позволит продолжать
наблюдение( и в конечном счете дает возможность найти источник
угроз вашим системам). С другой стороны, если на каких-либо
ЭВМ были разрушены данные в результате атаки, начатой с ваших
ЭВМ, выбор будет более сложным: отбрасывание злоумышленника может
предотвратить дальнейшие разрушения на ЭВМ, но сделает
невозможным его выслеживание. Если произошли разрушения, решение
о том, насколько важно оставить ЭВМ открытыми, чтобы поймать
злоумышленника, должно приниматься совместно всеми пострадавшими
организациями. Стоит отметить, что проблема сетевой
ответственности усложняется тем соображением, что если вы не
помогаете расследующему агентству, вы скорее всего не получите от
него помощи в будущем.

5.6 Документирование

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

6. Выработка мер по защите после инцидента

6.1 Обзор

После инцидента следует предпринять несколько действий. Эти
действия могут быть обобщены следующим образом:
1) Следует произвести инвентаризацию ценностей АС, то есть
нужно точно определить, каковы последствия инцидента для АС.
2) Уроки, вынесенные из инцидента, следует включить в
пересмотренные ПРД и СРД для предотвращения повтора инцидента.
3) Следует произвести новый анализ риска в свете инцидента.
4) Привлечение к судебной ответственности людей, вызвавших
инцидент, если это требуется.
Все эти четыре шага обеспечивают обратную связь с ПРД
организации, приводя к ее пересмотру.
6.2 Ликвидация уязвимых мест
Ликвидировать все уязвимые места при возникновении инцидента
трудно. Ключевым при этом является знание и понимание того, где
находится брешь. В некоторых случаях самым разумным будет
запретить доступ вообще, а затем восстановить постепенно
нормальный режим работы. Помните, что запрет доступа в ходе
инцидента ясно покажет всем пользователям, включая
злоумышленников, что администрация знает о проблеме; это может
сделать невозможным исследование. Тем не менее, позволив
инциденту продолжаться, вы можете вызвать еще большие разрушения.
Если выявлено, что брешь возникла в результате ошибок в
оборудовании или системном программном обеспечении, то следует
уведомить производителя. Рекомендуется включить в ПРД
соответствующие номера телефонов (а также адреса электронной
почты или факса). Для удобства понимания ошибка должна быть
описана как можно детальнее, включая то, как она была
использована.
Как только брешь обнаружена, вся АС и все ее компоненты
должны находиться под подозрением. Самым подозрительным должно
быть системное программное обеспечение. Главным при
восстановлении является соответствующая подготовка. Она включает
в себя расчет контрольных сумм всех для всех носителей
дистрибутивов, используя алгоритм, устойчивый к подмене[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, журнал защиты может
оказаться самой ценной вещью на этапе ликвидации уязвимых мест.
Здесь стоит отметить два момента; во-первых нужно записывать в
журнале обо всех мерах, использованных для восстановления защиты
АС. В журнал нужно включать информацию о командных процедурах,
которые периодически запускаются для проверки защищенности.
Во-вторых, нужно делать записи о важных системных событиях.
Впоследствии они могут оказаться справочным материалом при
определении разрушенной части АС.

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

6.3.1 Учтите опыт инцидента

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

6.3.2 Ресурсы

6.3.2.1 Другие методы и устройства защиты

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

6.3.2.2 Книги, списки, информационные источники

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

6.3.2.3 Образуйте подгруппу

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

6.4 Обновление ПРД и СРД

6.4.1 Установление механизмов обновления ПРД и СРД

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

6.4.2 Процедуры сообщения о проблемах

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

7. Cсылки

[1] Quarterman, J., "The Matrix: Computer Networks and
Conferencing Systems Worldwide", Pg. 278, Digital Press,
Bedford, MA, 1990.
[2] Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery", R. Brand,
доступна чеpез cert.sei.cmu.edu:/pub/info/primer, 8 June
1990.
[3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of
Computer Information Systems", Computer Science Press, 1989.
[4] Johnson, D., and J. Podesta, "Formulating a Company Policy on
Access to and Use and Disclosure of Electronic Mail on Company
Computer Systems", Доступна через: The Electronic Mail
Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA
22209, (703) 522-7111, 22 October 1990.
[5] Curry, D., "Improving the Security of Your UNIX System", SRI
International Report ITSTD-721-FR-90-21, April 1990.
[6] Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA, June
1990.
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I — Message Encipherment and Authentication Procedures", RFC
1113, IAB Privacy Task Force, August 1989.
[8] Kent, S., and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II — Certificate-Based Key Management",
RFC 1114, IAB Privacy Task Force, August 1989.
[9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
III — Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
Task Force, August 1989.
[10] Merkle, R., "A Fast Software One Way Hash Function", Journal of
Cryptology, Vol. 3, No. 1.
[11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC 791, DARPA, September 1981.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[13] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[14] Mogul, J., "Simple and Flexible Datagram Access Controls for
UNIX-based Gateways", Digital Western Research Laboratory
Research Report 89/4, March 1989.
[15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, October
1990.
[16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood
Cliffs, N.J., 1989.
[17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business", QED
Information Sciences, Inc., Wellesley, MA.
[18] Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
[21] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1200,
IAB, April 1991.
[22] Internet Activities Board, "Ethics and the Internet", RFC 1087,
Internet Activities Board, January 1989.
[23] Pethia, R., Crocker, S., and B. Fraser, "Policy Guidelines for
the Secure Operation of the Internet", CERT, TIS, CERT, RFC in
preparation.
[24] Computer Emergency Response Team (CERT/CC), "Unauthorized
Password Change Requests", CERT Advisory CA-91:03, April 1991.
[25] Computer Emergency Response Team (CERT/CC), "TELNET Breakin
Warning", CERT Advisory CA-89:03, August 1989.
[26] CCITT, Recommendation X.509, "The Directory: Authentication
Framework", Annex C.
[27] Farmer, D., and E. Spafford, "The COPS Security Checker System",
Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA,
Pgs. 165-170, June 1990.

8. Аннотиpованная библиогpафия

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

8.1 Компьютеpные законы

[ABA89]
American Bar Association, Section of Science and
Technology, "Guide to the Prosecution of Telecommunication
Fraud by the Use of Computer Crime Statutes", American Bar
Association, 1989.
[BENDER]
Bender, D., "Computer Law: Evidence and Procedure",
M. Bender, New York, NY, 1978-настоящее вpемя.
Актуальна из-за дополнений.
Выпуски с 1978 по 1984 год pассматpивали компьютеpные законы,
улики и пpоцедуpы. В следующие годы pассматpивались общие
компьютеpные законы. Включены библиогpафические ссылки и
индекс
[BLOOMBECKER]
Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-
Irwin, Homewood, IL. 1990.
[CCH]
Commerce Clearing House, "Guide to Computer Law", (Topical
Law Reports), Chicago, IL., 1989.
Описания судебных pазбиpательств по компьютеpным пpеступлениям
в федеpальном суде и судах штатов и пpиговоpы по ним.
Включает таблицу и индекс.
[CONLY]
Conly, C., "Organizing for Computer Crime Investigation and
Prosecution", U.S. Dept. of Justice, Office of Justice
Programs, Under Contract Number OJP-86-C-002, National
Institute of Justice, Washington, DC, July 1989.
[FENWICK]
Fenwick, W., Chair, "Computer Litigation, 1985: Trial
Tactics and Techniques", Litigation Course Handbook
Series No. 280, Prepared for distribution at the
Computer Litigation, 1985: Trial Tactics and
Techniques Program, February-March 1985.
[GEMIGNANI]
Gemignani, M., "Viruses and Criminal Law", Communications
of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[HUBAND]
Huband, F., and R. Shelton, Editors, "Protection of
Computer Systems and Software: New Approaches for Combating
Theft of Software and Unauthorized Intrusion", Papers
presented at a workshop sponsored by the National Science
Foundation, 1986.
[MCEWEN]
McEwen, J., "Dedicated Computer Crime Units", Report
Contributors: D. Fester and H. Nugent, Prepared for the
National Institute of Justice, U.S. Department of Justice,
by Institute for Law and Justice, Inc., under contract number
OJP-85-C-006, Washington, DC, 1989.
[PARKER]
Parker, D., "Computer Crime: Criminal Justice Resource
Manual", U.S. Dept. of Justice, National Institute of Justice,
Office of Justice Programs, Under Contract Number
OJP-86-C-002, Washington, D.C., August 1989.
[SHAW]
Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986,
Congressional Record (3 June 1986), Washington, D.C.,
3 June 1986.
[TRIBLE]
Trible, P., "The Computer Fraud and Abuse Act of 1986",
U.S. Senate Committee on the Judiciary, 1986.

8.2 Компьютерная безопасность

[CAELLI]
Caelli, W., Editor, "Computer Security in the Age of
Information", Proceedings of the Fifth IFIP International
Conference on Computer Security, IFIP/Sec '88.
[CARROLL]
Carroll, J., "Computer Security", 2nd Edition, Butterworth
Publishers, Stoneham, MA, 1987.
[COOPER]
Cooper, J., "Computer and Communications Security:
Strategies for the 1990s", McGraw-Hill, 1989.
[BRAND]
Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery",
R. Brand, 8 June 1990.
По меpе того, как безопасность становится все более важным
вопpосом в совpеменном обществе, она начинает тpебовать
систематического подхода. От большинства пpоблем, связанных
с компьютеpной безопасностью можно защититься пpостыми
дешевыми меpами. Самые важные и недоpогие меpы должны
пpименяться на фазах планиpования и восстановления. Эти методы
пpедставлены в этой статье, котоpая оканчивается pуководством
по улаживанию инцидента и восстановлению после него.
Доступна как cert.sei.cmu.edu:/pub/info/primer.
[CHESWICK]
Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA,
June 1990.
Кpаткое содеpжание: в AT&T функциониpует большой внутpенний
Интеpнет, котоpый нужно защищать от внешних атак, в то же вpемя
обеспечивая доступ к полезным сеpвисам.
Эта статья описывает Интеpнетовский шлюз AT&T. Этот шлюз
позволяет оpганизовать взаимный доступ к почте и многим дpугим
Интеpнетовским службам между внутpенним и внешним Интеpнетом.
Это pеализуется без пpямой IP-связности с помощью двух ЭВМ:
довеpенной внутpенней ЭВМ и недовеpенного внешнего шлюза. Они
соединены выделенной линией. Внутpенняя машина обеспечивает
несколько тщательно защищаемых служб для внешнего шлюза. Эта
конфигуpация помогает защитить внутpенний Интеpнет, если
внешняя машина скомпpометиpована.
Это очень полезная и интеpесная pазpаботка. Большинство
бpандмауэpов полагается на ЭВМ, котоpая пpи компpометации
позволяет полный доступ к машинам за ней. Также, большинство
бpандмауэpов тpебуют, чтобы пользователи, котоpым тpебуется
доступ к Интеpнетовским службам, были заpегистpиpованы на
бpандмауэpе. Разpаботка AT&T позволяет внутpенним пользователям
AT&T иметь доступ к службам TELNET и FTP с их pабочих станций, не
pегистpиpуясь на бpандмауэpе. Очень полезная статья, котоpая
показывает, как сохpанить пpеимущества подключения к Интеpнету,
не теpяя пpи этом безопасности.
[CURRY]
Curry, D., "Improving the Security of Your UNIX System",
SRI International Report ITSTD-721-FR-90-21, April 1990.
Эта статья описывает меpы, котоpые вы, как системный
администpатоpа, можете пpедпpинять, чтобы сделать ваш
Unix более защищенным. Оpиентиpованная в-основном на SunOS 4.X,
эта статья пpименима к любой системе Unix на основе Беpкли с или
без NFS и с или без Yellow Pages(NIS). Часть этой инфоpмации
также может быть пpименима для System V, хотя это и не является
целью статьи. Очень полезный спpавочник, также доступен в Интеpнете,
по адpесу cert.sei.cmu.edu:/pub/info.
[FITES]
Fites, M., Kratz, P. and A. Brebner, "Control and
Security of Computer Information Systems", Computer Science
Press, 1989.
Эта книга является хоpошим pуководством по вопpосам, возника ющим пpи pазpаботке ПРД и СРД. Эта книга является учебником
для вводного куpса по безопасности ИС.
Эта книга pазделена на 5 частей: Упpавление Риском(1),
Защитные меpы: оpганизацонные(2), Защитные меpы: пpогpаммно-
аппаpатные(3), Юpидические пpоблемы и пpофессионализм(4),
Рекомендации по контpолю за компьютеpом CICA(5).
Эта книга особенно полезна по пpичине своего простого
подхода к безопасности, пpи котоpом здpавый смысл является
главным пpи pазpаботке ПРД. Автоpы отмечают, что существует
тенденция искать более технические pешения пpоблем безопасности,
забывая пpи этом оpганизационные меpы, котоpые часто дешевле и
эффективнее. 298 стpаниц, включая ссылки и индекс.
[GARFINKEL]
Garfinkel, S, and E. Spafford, "Practical Unix Security",
O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.
Approx 450 pages, $29.95. Orders: 1-800-338-6887
(US & Canada), 1-707-829-0515 (Europe), email: nuts@ora.com
Одна из самых полезных книг, имеющихся по безопасности Unix.
Пеpвая часть книги описывает основы Unix и безопасности в ней,
делая особый упоp на паpоли. Втоpая часть описывает, как
сделать систему безопасной. Особенно интеpесной для Интеpнетовского
пользователя могут быть главы по сетевой безопасности, котоpые
описывают многие из пpоблем безопасности, с котоpыми сталкиваются
Интеpнетовские пользователи. Четыpе главы pассматpивают улаживание
инцидентов с безопасностью, и завеpшается книга обзоpом шифpования,
физической безопасности и списком полезных контpольных вопpосов и
источников инфоpмации. Эта книга опpавдывает свое название: она
дает инфоpмацию о возможных бpешах в безопасности, файлах, котоpые
надо пpовеpять и вещах, котоpые улучшают безопасность. Эта книга
является великолепным дополнением к предыдущей книге.
[GREENIA90]
Greenia, M., "Computer Security Information Sourcebook",
Lexikon Services, Sacramento, CA, 1989.
Руководство администратора по компьютерной безопасности.
Содержит указатель на главные справочные материалы,
включая библиографию по управлению доступом и компьютерным
преступлениям.
[HOFFMAN]
Hoffman, L., "Rogue Programs: Viruses, Worms, and
Trojan Horses", Van Nostrand Reinhold, NY, 1990.
(384 страницы, включает библиографические ссылки и индекс.)
[JOHNSON]
Johnson, D., and J. Podesta, "Formulating A Company Policy
on Access to and Use and Disclosure of Electronic Mail on
Company Computer Systems".
Эта книга подготовлена для EMA двумя экспертами по законам о
конфиденциальности личной информации. Является введением в эти
вопросы и содержит некоторые варианты ПРД
Доступна через The Electronic Mail Association (EMA)
1555 Wilson Blvd, Suite 555, Arlington, VA, 22209.
(703) 522-7111.
[KENT]
Kent, Stephen, "E-Mail Privacy for the Internet: New Software
and Strict Registration Procedures will be Implemented this
Year", Business Communications Review, Vol. 20, No. 1,
Pg. 55, 1 January 1990.
[LU]
Lu, W., and M. Sundareshan, "Secure Communication in
Internet Environments: A Hierachical Key Management Scheme
for End-to-End Encryption", IEEE Transactions on
Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[LU1]
Lu, W., and M. Sundareshan, "A Model for Multilevel Security
in Computer Networks", IEEE Transactions on Software
Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
[NSA]
National Security Agency, "Information Systems Security
Products and Services Catalog", NSA, Quarterly Publication.
Каталог АНБ содержит следующие главы: Список одобренных
криптографических продуктов; Список одобренных АНБ продуктов,
реализующих DES; Список защищенных сервисов; Список сертифи-
цированных продуктов; Список рекомендуемых продуктов;
Список одобренных программных средств.
Этот каталог доступен через
Superintendent of Documents,
U.S. Government Printing Office, Washington,
D.C. Можно звонить по телефону:
(202) 783-3238.
[OTA]
United States Congress, Office of Technology Assessment,
"Defending Secrets, Sharing Data: New Locks and Keys for
Electronic Information", OTA-CIT-310, October 1987.
Этот отчет, подготовленный для комитета конгресса, рассматривает
Федеральную политику по защите электронной информации и является
интересным из-за вопросов, возникающих в связи с влиянием
технологии, используемой для защиты информации. Он также служит
хорошим введением в различные механизмы шифрования и защиты
информации. 185 страниц.
Доступен через U.S. Government Printing Office.
[PALMER]
Palmer, I., and G. Potter, "Computer Security Risk
Management", Van Nostrand Reinhold, NY, 1989.
[PFLEEGER]
Pfleeger, C., "Security in Computing", Prentice-Hall,
Englewood Cliffs, NJ, 1989.
Являясь вводным учебником по компьютерной безопасности, эта
книга содержит великолепное и очень доступное введение в
классические проблемы компьютерной безопасности и их решения,
с особым упором на шифрование. Часть, описывающая шифрование,
является хорошим введение в это предмет. Другие разделы описывают
разработку безопасных программ и АС, безопасность баз данных,
безопасность персональных компьютеров, сетевую и коммуникационную
безопасность, физическую безопасность, анализ риска и планирование
безопасности, юридические и этические проблемы. 583 страницы,
включая индекс и библиографию.
[SHIREY]
Shirey, R., "Defense Data Network Security Architecture",
Computer Communication Review, Vol. 20, No. 2, Page 66,
1 April 1990.
[SPAFFORD]
Spafford, E., Heaphy, K., and D. Ferbrache, "Computer
Viruses: Dealing with Electronic Vandalism and Programmed
Threats", ADAPSO, 1989. (109 pages.)
Это хороший общий справочник по компьютерным вирусам и
связанным с ними вопросам. Помимо детального описания вирусов,
книга также охватывает много общих вопросов безопасности,
юридические проблемы, связанные с безопасностью, и включает
список законов, журналы, посвященные компьютерной безопасности,
и другие источники информации о безопасности.
Доступна через: ADAPSO, 1300 N. 17th St, Suite 300,
Arlington VA 22209. (703) 522-5055.
[STOLL88]
Stoll, C., "Stalking the Wily Hacker", Communications
of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM,
New York, NY, May 1988.
Эта статья описывает некоторые технические приемы, использующиеся
для выслеживания злоумышленника, которые позднее были описаны в
"Яйце кукушки"(смотри ниже)
[STOLL89]
Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2,
Doubleday, 1989.
Клиффорд Столл, астроном, оказавшийся системным администратором
Unix, описывает удивительную, но правдивую историю о том, как он
выследил компьютерного злоумышленника, проникшего в американские
военные и исследовательские сети. Эта книга легка для понимания и
может служить интересным введением в мир сетей. Джон Постел написал
в рецензии на книгу:" [эта книга]... является абсолютно необходимиым
чтением для тех, кто использует любой компьютер, подключенный к
Интернету или другой компьютерной сети "
[VALLA]
Vallabhaneni, S., "Auditing Computer Security: A Manual with
Case Studies", Wiley, New York, NY, 1989.

8.3 Этика

[CPSR89]
Computer Professionals for Social Responsibility, "CPSR
Statement on the Computer Virus", CPSR, Communications of the
ACM, Vol. 32, No. 6, Pg. 699, June 1989.
Эта статья является заявлением об Интернетовском компьютерном
вирусе Компьютерных профессионалов за социальную ответственность.
[DENNING]
Denning, Peter J., Editor, "Computers Under Attack:
Intruders, Worms, and Viruses", ACM Press, 1990.
Набор из 40 глав, разделенных между шестью частями:
опасность всемирных компьютерных сетей, электронные проникновения,
черви, вирусы, контркультура(статьи описывают мир "хакеров"),
и наконец, часть, описывающую социальные, юридические и
этические вопросы.
Содержательная коллекция, которая рассматривает феномен атак на
компьютеры. Она включает ряд ранее опубликованных статей, а также
ряд новых статей. Выбраны самые лучшие из опубликованных ранее,
в них даны некоторые ссылки на источники, которые иначе тяжело
было бы найти. Эта книга является важным справочником по угрозам
компьютерной безопасности, которые привлекли такое внимание к
компьютерной безопасности в последние годы.
[ERMANN]
Ermann, D., Williams, M., and C. Gutierrez, Editors,
"Computers, Ethics, and Society", Oxford University Press,
NY, 1990. (376 pages, includes bibliographical references).
[FORESTER]
Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA,
1990. (192 pages including index.)
Из предисловия: "Целью этой книги является: во-первых,
описать некоторые из проблем, созданных для общества компьютерами,
и, во-вторых, показать, как эти проблемы приводят к возникновению
этических дилемм для компьютерных профессионалов и компьютерных
пользователей.
Проблемы, созданные компьютерами, имеют, в свою очередь, два
источника: неправильная работа оборудования и программ и
неправильное их использование людьми. Мы доказываем, что
компьютерные системы по своей природе небезопасны, ненадежны,
непредсказуемы - и что общество еще не представляет себе
всех последствий. Мы также хотим показать, как общество
стало более уязвимо к неправильному использованию людьми
компьютеров в виде таких явлений, как компьютерные преступления,
кражи программ, хакеры, создание вирусов, нарушение личных свобод
и т.д."
Восемь глав включают: "Компьютерные преступления", "Кражи
программ", "Хакеры и вирусы", "Ненадежные компьютеры",
"Нарушение личных свобод", "ИИ и экспертные системы",
"Компьютеризация рабочего места". Имеется аннотированные
источники и индекс.
[GOULD]
Gould, C., Editor, "The Information Web: Ethical and Social
Implications of Computer Networking", Westview Press,
Boulder, CO, 1989.
[IAB89]
Internet Activities Board, "Ethics and the Internet",
RFC 1087, IAB, January 1989. Also appears in the
Communications of the ACM, Vol. 32, No. 6, Pg. 710,
June 1989.
Этот документ является ПРД Internet Activities Board(IAB),
связанными с правильным использованием ресурсов Интернета.
Доступен в оперативном режиме на хосте ftp.nisc.sri.com,
директория rfc, имя файла rfc1087.txt. Также доступен на хосте
nis.nsf.net, директория RFC, имя файла RFC1087.TXT-1.
[MARTIN]
Martin, M., and R. Schinzinger, "Ethics in Engineering",
McGraw Hill, 2nd Edition, 1989.
[MIT89]
Massachusetts Institute of Technology, "Teaching Students
About Responsible Use of Computers", MIT, 1985-1986. Also
reprinted in the Communications of the ACM, Vol. 32, No. 6,
Pg. 704, Athena Project, MIT, June 1989.
Этот документ является ПРД МТИ по проблемам использования
компьютеров.
[NIST]
National Institute of Standards and Technology, "Computer
Viruses and Related Threats: A Management Guide", NIST
Special Publication 500-166, August 1989.
[NSF88]
National Science Foundation, "NSF Poses Code of Networking
Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688,
June 1989. Also appears in the minutes of the regular
meeting of the Division Advisory Panel for Networking and
Communications Research and Infrastructure, Dave Farber,
Chair, November 29-30, 1988.
Этот документ является ПРД Национального Научного Фонда(NSF),
связанными с этическим использованием Интернета.
[PARKER90]
Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business",
QED Information Sciences, Inc., Wellesley, MA. (245 pages).
Дополнительные публикации по Этике:
Университет Нью-Мексико(UNM)
UNM имеет коллекцию документов по этике. Она включает в себя
юридичские документы нескольких штатов и ПРД многих учебных заведений.
Доступ через FTP, IP-адрес - ariel.umn.edu. Ищите в директории
/ethics

8.4 Интернетовский червь

[BROCK]
Brock, J., "November 1988 Internet Computer Virus and the
Vulnerability of National Telecommunications Networks to
Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC,
20 July 1989.
Свидетельские показания Джека Брока, директора отдела
правительственной информации США, перед подкомитетом по
телекоммуникациям и финансам, комитетами по энергетике и
торговле, палатой представителей.
[EICHIN89]
Eichin, M., and J. Rochlis, "With Microscope and Tweezers:
An Analysis of the Internet Virus of November 1988",
Massachusetts Institute of Technology, February 1989.
Содержит детальный анализ программы-червя. Статья обсуждает
основные моменты програмы-червя, а затем кратко рассматривает
стратегии, хронологию, уроки и нерешенные проблемы. Также
включено большое приложение с текстом программы и ссылки.
[EISENBERG89]
Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb,
M. Lynn, and T. Santoro, "The Computer Worm", Cornell
University, 6 February 1989.
Отчет Корнелльского Университете, представленный ректору
университета 6 февраля 1989 года, об Интернетовском черве.
[GAO]
U.S. General Accounting Office, "Computer Security - Virus
Highlights Need for Improved Internet Management", United
States General Accounting Office, Washington, DC, 1989.
Этот 36-страничный отчет(GAO-IMTEC-89-57) описывает
Интернетовский червь и его последствия. Является хорошим
обзором различных агентств США, работающих сейчас в Интернете и
и их проблем в области компьютерной безопасности и работы в
сетях.
Доступен в оперативном режиме на хосте nnsc.nsf.net, директории
pub, файле GAO_RPT; и на nis.nsf.net, директории nsfnet,
файле GAO_RPT.TXT.
[REYNOLDS89]
The Helminthiasis of the Internet, RFC 1135,
USC/Information Sciences Institute, Marina del Rey,
CA, December 1989.
Этот отчет является ретроспективой заражения Интернета
червем, которое произошло вечером 2 ноября 1988 года.
Этот документ дает очерк заражения, обнаружения и излечения.
Также рассматриваются влияние червя на Интернетовское сообщество,
этические правила, роль средств массовой инфомации, преступление
в компьютерном мире, и будущее. Отчет содержит 4 публикации,
которые детально описывают эту конкретную паразитическую
компьютерную программу. Также включены ссылки и библиография.
Доступен в оперативном режиме на хосте ftp.nisc.sri.com,
директории rfc, файле rfc1135.txt. Также доступен на хосте
nis.nsf.net. директории RFC, файле RFC1135.TXT-1.
[SEELEY89]
Seeley, D., "A Tour of the Worm", Proceedings of 1989
Winter USENIX Conference, Usenix Association, San Diego, CA,
February 1989.
Детальное описание представлено в виде прогулки по программе.
Эта статья состоит из общего представления, введения,
детальной хронологии событий после обнаружения червя, обзора
червя, его содержания, мнений участников событий и заключения.
[SPAFFORD88]
Spafford, E., "The Internet Worm Program: An
Analysis", Computer Communication Review, Vol. 19,
No. 1, ACM SIGCOM, January 1989. Also issued as Purdue
CS Technical Report CSD-TR-823, 28 November 1988.
Описывает заражение Интернета программой-червем, которая
использует уязвимые места в утилитах Unixа. Этот отчет
содержит детальное описание компонент программы-червя:
ее данных и функций. Спаффорд сосредотачивает свое
исследование на двух полностью независимых версиях
реассемблированного червя и версии, дизассемблированной на
ассемблере VAXа.
[SPAFFORD89]
Spafford, G., "An Analysis of the Internet Worm",
Proceedings of the European Software Engineering
Conference 1989, Warwick England, September 1989.
Proceedings published by Springer-Verlag as: Lecture
Notes in Computer Science #387. Also issued
as Purdue Technical Report #CSD-TR-933.

8.5 Национальный центр компьютерной безопасности

Все публикации NCSC, разрешенные для опубликования доступны
через суперинтенданта NCSC по документам.
NCSC = National Computer Security Center
9800 Savage Road
Ft Meade, MD 20755-6000
CSC = Computer Security Center:
более старое имя NCSC
NTISS = National Telecommunications and
Information Systems Security
NTISS Committee, National Security Agency
Ft Meade, MD 20755-6000
[CSC]
Department of Defense, "Password Management Guideline",
CSC-STD-002-85, 12 April 1985, 31 pages.
Безопасность, обеспечиваемая парольными системами, зависит от
сохранения все время паролей в секрете. Поэтому, пароль уязвим к
компрометации, когда бы он ни использовался или хранился. В
механизме аутентификации на основе паролей, реализованном в
АС, пароли уязвимы к компрометации из-за 5 важных аспектов
парольной системы:1)пароль должен назначаться пользователю
перед началом его работы в АС;2)пароль пользователя должен
периодически меняться;3)АС должна поддерживать базу данных
паролей;4)пользователи должны помнить свои пароли;5) пользователи
должны вводить свои пароли в АС при аутентификации. Это
руководство описывает шаги по минимизации уязвимости паролей в
каждом из случаев.
[NCSC1]
NCSC, "A Guide to Understanding AUDIT in Trusted Systems",
NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
Контрольные журналы используются для обнаружения втоpжения
в компьютеpную систему и выявления непpавильного использования
ее pесуpсов. По желанию аудитоpа контpольные жуpналы могут
пpотоколиpовать только опpеделенные события или всю pаботу в
системе. Хотя это и не тpебуется кpитеpием, механизм аудиpования
должен иметь возможность котpоля как за объектом, так и за
субъектом. То есть, он должен наблюдать как за тем, когда Джон
входит в систему, так и за тем, как осуществляется доступ к
файлу о ядеpном pеактоpе; и аналогично, за тем, когда Джон
обpащается к ядеpному pеактоpу.
[NCSC2]
NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL
in Trusted Systems", NCSC-TG-003, Version-1, 30 September
1987, 29 pages.
Дискpеционная упpавление доступом - самый pаспpостpаненный тип
механизма упpавления доступом, pеализованного в компьютеpных
системах сегодня. Основой этого вида безопасности является
возможность отдельного пользователя или пpогpаммы, pаботающей от
его имени, указать явно типы доступа, котоpые дpугие
пользователи или пpогpаммы, pаботающие от их имени, могут
осуществлять к защищаемой инфоpмации. Дискpеционное упpавление
доступом не является заменой мандатного упpавления доступом.
В любой сpеде, в котоpой защищается инфоpмация, дискpеционная
безопасность обеспечивает большую точность для упpавления
доступом в pамках огpаничений мандатной политики.
[NCSC3]
NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT
in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988,
31 pages.
Контpоль за конфигуpацией состоит из
идентификации, упpавления, пpотоколиpования состояния и
аудиpования. Пpи каждом изменении, пpоизводимом в АС, должен
быть пpедставлен пpоект и тpебования к измененной АС.
Упpавление выполняется с помощью пpосмотpа и утвеpждения
автоpизованным лицом каждого изменения в документации,
обоpудовании и пpогpаммном обеспечении. Пpи учете состояния
пpоизводится после каждого изменения запись об этом и доведение
до автоpизованных лиц. Наконец, с помощью аудиpования совеpшенное
изменение пpовеpяется на функциональную коppектность, и для
довеpенных АС, на согласованность с ПРД АС.
[NTISS]
NTISS, "Advisory Memorandum on Office Automation Security
Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987,
58 pages.
Этот документ является pуководством для пользователей,
администpатоpов, ответственных за безопасность и за
поставки пpогpаммного и аппаpатного обеспечения в АС.
Описаны следующие вопpосы: физическая безопасность,
кадpовая безопасность, пpоцедуpная безопасность, пpогpаммно-
аппаpатные меpы, защита от ПЭМИН, и коммуникационная безопасность
для автономных АС, АС, используемых как теpминалы, подключенные
к ГВМ, и АС, используемых в ЛВС. Пpоизводится диффеpенциация
между АС, оснащенными НГМД и НЖМД.
Дополнительные публикации NCSC
[NCSC4]
National Computer Security Center, "Glossary of Computer
Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
[NCSC5]
National Computer Security Center, "Trusted
Computer System Evaluation Criteria", DoD 5200.28-STD,
CSC-STD-001-83, NCSC, December 1985.
[NCSC7]
National Computer Security Center, "Guidance for
Applying the Department of Defense Trusted Computer System
Evaluation Criteria in Specific Environments",
CSC-STD-003-85, NCSC, 25 June 1985.
[NCSC8]
National Computer Security Center, "Technical Rationale
Behind CSC-STD-003-85: Computer Security Requirements",
CSC-STD-004-85, NCSC, 25 June 85.
[NCSC9]
National Computer Security Center, "Magnetic Remanence
Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985.
Это руководство помечено грифом: "Только для оффициального
использования" согласно части 6 закона 86-36( 50 U.S. Code
402). Распространение осуществляется только для правительственных
агентств США и их подрядчиков для защиты конфиденциальных
технических, операционных и административных данных, относящихся
к работе АНБ.
[NCSC10]
National Computer Security Center, "Guidelines for Formal
Verification Systems", Shipping list no.: 89-660-P, The
Center, Fort George G. Meade, MD, 1 April 1990.
[NCSC11]
National Computer Security Center, "Glossary of Computer
Security Terms", Shipping list no.: 89-254-P, The Center,
Fort George G. Meade, MD, 21 October 1988.
[NCSC12]
National Computer Security Center, "Trusted UNIX Working
Group (TRUSIX) rationale for selecting access control
list features for the UNIX system", Shipping list no.:
90-076-P, The Center, Fort George G. Meade, MD, 1990.
[NCSC13]
National Computer Security Center, "Trusted Network
Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
[NCSC14]
Tinto, M., "Computer Viruses: Prevention, Detection, and
Treatment", National Computer Security Center C1
Technical Report C1-001-89, June 1989.
[NCSC15]
National Computer Security Conference, "12th National
Computer Security Conference: Baltimore Convention Center,
Baltimore, MD, 10-13 October, 1989: Information Systems
Security, Solutions for Today - Concepts for Tomorrow",
National Institute of Standards and National Computer
Security Center, 1989.

8.6 Списки контрольных вопросов по безопасности

[AUCOIN]
Aucoin, R., "Computer Viruses: Checklist for Recovery",
Computers in Libraries, Vol. 9, No. 2, Pg. 4,
1 February 1989.
[WOOD]
Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V.,
and H. Sartorio, "Computer Security: A Comprehensive Controls
Checklist", John Wiley and Sons, Interscience Publication,
1987.

8.7 Дополнительные публикации

Defense Data Network's Network Information Center (DDN NIC)
DDN NIC поддерживает бюллетени DDN Security и DDN Management
оперативно доступными на ЭВМ NIC.DDN.MIL. Доступ надо
осуществлять через анонимный FTP. Бюллетени DDN Security
находятся в директории SCC, а бюллетени DDN Management
в директории DDN-NEWS.
Для получения более подробной информации вы можете послать
сообщение NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155.
[DDN88]
Defense Data Network, "BSD 4.2 and 4.3 Software Problem
Resolution", DDN MGT Bulletin #43, DDN Network Information
Center, 3 November 1988.
Объявление в "Defense Data Network Management Bulletin"
об исправлениях ошибок в 4.2bsd и 4.3bsd, послуживших
причиной Интернетовского червя.
[DDN89]
DCA DDN Defense Communications System, "DDN Security
Bulletin 03", DDN Security Coordination Center,
17 October 1989.
Труды ТИИЭР
[IEEE]
"Proceedings of the IEEE Symposium on Security
and Privacy", публикуются ежегодно.
Труды ТИИЭР доступны по адресу:
Computer Society of the IEEE
P.O. Box 80452
Worldway Postal Center
Los Angeles, CA 90080