реклама
ЭКСПЕРТИЗА САЙТОВ НА СЛИВ ИНФОРМАЦИИ

ВОССТАНОВЛЕНИЕ ИНФОРМАЦИИ С РАЗЛИЧНЫХ НАКОПИТЕЛЕЙ В КИЕВЕ
уход за растениями - озеленение - фитодизайн
реклама

proxy  статьи  библиотека  softice  free_юр.консультация  hard  iptv
рекламодателям  фирмы/add  расшифровка штрих-кодов  links/add

http://kiev-security.org.ua

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афию.

Вперед

Содержание

HOME


Если у вас есть сайт или домашняя страничка - поддержите пожайлуста наш ресурс, поставьте себе кнопочку, скопировав этот код:

<a href="http://kiev-security.org.ua" title="Самый большой объем в сети онлайн инф-ции по безопасности на rus" target="_blank"><img src="http://kiev-security.org.ua/88x31.gif" width="88" height="31" border="0" alt="security,безопасность,библиотека"></a>

Идея проекта(C)Anton Morozov, Kiev, Ukraine, 1999-2021, security2001@mail.ru