Страница:
которые не являются их собственными, даже если они имеют
право записи в них?
- можно ли нескольким пользователям использовать одно и то же
регистрационное имя и пароль?
Ответом на большинство этих вопросов будет "НЕТ".
Вы можете захотеть включить в ваши ПРД пункт, связанный с
программным обеспечением, защищенным авторскими правами или
лицензированным. Лицензионное соглашение с производителями может
потребовать некоторых усилий от вас для того чтобы гарантировать
отсутствие нарушений лицензии. Кроме того, вы можете захотеть
проинформировать пользователей, что копирование программ,
защищенных авторскими правами, является нарушением законов об
авторских правах и запрещено.
В отношении программного обеспечения, которое является
лицензионным или защищено авторскими правами, вы можете захотеть
включить в ПРД следующую информацию:
- какое лицензионное и защищенное авторскими правами
программное обеспечение не может копироваться за исключением
случая, когда явно сказано, что вы можете делать это;
- методы доведения информации о статусе разрешения
копирования программ;
- фразу "Когда у вас возникли сомнения, НЕ КОПИРУЙТЕ".
Ваши правила допустимого использования очень важны. ПРД,
которые явно не определяют, что запрещено, могут впоследствии не
позволить вам доказать, что пользователь нарушает ПРД.
Существуют исключения, такие как пользователи или
администраторы, желающие иметь "лицензию на хэккерство" - вы
можете столкнуться с ситуацией, когда пользователи захотят
исследовать ваши АС ради тестирования защищенности. Вы должны
разработать ПРД, которые будут определять, можно ли вам разрешать
такой тип исследований ваших сетевых служб и, если это так,
каковы рекомендации при проведении таких исследований.
Что вам следует отразить в этой части ПРД:
- можно ли это делать вообще;
- какой тип деятельности разрешен: доступ к информации,
запуск сетевых вирусов, запуск вирусов, и т.д.;
- какой контроль должен осуществляться при этом, чтобы
гарантировать, что ситуация не вышла из-под контроля (например,
выделить сегмент вашей сети для этих тестов);
- каким образом вы будете защищать остальных пользователей,
чтобы они не стали жертвами этих процессов, включая внешних
пользователей и сети;
- процесс получения разрешения на проведение этих тестов.
В тех случаях, когда вы разрешили проведение таких
исследований, вы должны изолировать тестируемую часть сети от
основной сети. Сетевые вирусы и просто вирусы никогда не должны
запускаться в реальной сети.
Вы можете также захотеть подрядить кого-либо для оценки
защищенности ваших АС, что может включать их исследование. Вы
можете захотеть отразить этот момент в ваших ПРД.
Ваши ПРД должны устанавливать, кто отвечает за предоставление
разрешения на доступ к вашим службам. Более того, должно быть
определено, какой тип доступа они могут предоставлять. Если вы не
контролируете, кто дает разрешение на доступ к вашим АС, вы не
контролируете, кто использует ваши АС. Контроль за тем, кто имеет
право давать доступ, позволит также вам узнать, кто имел или не
имел разрешение на доступ при последующих проблемах с защитой.
Существует много схем, которые можно использовать для
управления распределением доступа к вашим службам. Далее
приводятся факторы, которые вы должны учитывать при определении
того, кто распределяет доступ к вашим службам:
- Будете вы управлять предоставлением доступа из одного места
или дадите это право нескольким местам?
У вас может быть одно центральное место для предоставления
полномочий на доступ в распределенной системе, в которой
различные ведомства независимо отвечают за предоставление
полномочий на доступ. Нужен компромисс между защищенностью и
удобством. Чем более это процесс централизован, тем более он
защищен.
- Какие методы вы будете использовать для регистрации новых
пользователей и прекращения доступа?
С точки зрения безопасности вам нужно знать механизм, который
будет использован при регистрации новых пользователей. При самом
незащищенном варианте люди, которые отвечают за регистрацию
пользователей, могут просто войти в систему и создать нового
пользователя вручную или с помощью механизма, определенного
производителем. В общем случае эти механизмы доверяют человеку,
запускающему их, и человек, запускающий их, обычно имеет большие
привилегии. Если вы выбрали этот способ, вам нужно выбрать
кого-либо, кто не подведет вас при решении этой задачи. Другим
способом будет создание интегрированной системы, которая
запускается людьми, отвечающими за регистрацию, или самими
пользователями. Помните, что даже наличие самого защищенного
средства создания новых пользователей не избавляет вас от
возможности злоупотреблений им.
У вас должны быть разработаны специфические процедуры для
добавления новых пользователей в АС. Эти процедуры должны быть
хорошо документированы для предотвращения неоднозначных
толкований и уменьшения числа ошибок. Уязвимость защиты при
создании новых пользователей возникает не только из-за возможных
злоупотреблений, но также из-за возможных ошибок. Просто и хорошо
документированная процедура поможет быть уверенным, что ошибок не
будет. Вы также должны быть уверены, что люди, которые исполняют
эти процедуры, понимают вас.
Предоставление полномочий пользователю на доступ к АС - один
из самых уязвимых моментов. Вы должны быть уверены, что пароль,
выбранный вначале, не может быть легко угадан. Вы должны избегать
использования в качестве начального пароля слова, производного от
имени пользователя, являющегося частью имени пользователя, или
некоторого алгоритмически сгенерированного пароля, который может
быть легко угадан. Кроме того, вам не следует позволять
пользователям продолжать использовать начальный пароль
неопределенно долгое время. Если это возможно, вы должны
заставлять пользователей менять начальный пароль при первом
сеансе работы с АС. Учитывайте то, что некоторые пользователи
могут так никогда и не войти в АС, что делает их пароли уязвимыми
неопределенно долгое время. Некоторые организации приняли решение
удалять пользователей, которые никогда не пользовались АС, и
заставлять владельцев этих имен заново регистрироваться в списке
пользователей.
Одним из решений в области защиты, которое нужно принимать
очень тщательно, - это кто будет иметь привилегии системного
администратора и доступ к паролям ваших служб. Естественно, что
системные администраторы будут иметь такие права, но неизбежно и
другие пользователи будут просить специальных привилегий. Ваши
ПРД должны так или иначе решать эту проблему. Ограничение выдачи
привилегий - один из способов защиты от угроз, исходящих от
местных пользователей. Целью является компромисс между
ограничением доступа ради большей безопасности и предоставлением
привилегий тем людям, кому на самом деле нужны такие привилегии,
чтобы они могли решать свои задачи. Одним из подходов к решению
является предоставление только тех привилегий, которые необходимы
для выполнения своих задач пользователем.
Кроме того, люди, владеющие особыми привилегиями, должны быть
учтены специальным органом, и эта информация также должна
зафиксирована в ПРД организации. Если человек, которому вы
предоставили особые привилегии, не учтен сам по себе где-либо, вы
рискуете потерять контроль за вашей АС и у вас возникнут
трудности при управлении безопасностью.
Ваши ПРД должны включать пункты о правах и обязанностях
пользователей в отношении использования СВТ и сервисов
организации. Должно быть явно установлено, что пользователи
отвечают за понимание и соблюдение правил безопасности в АС,
которые они используют. Далее приводится список моментов, которые
вы можете захотеть зафиксировать в этой области ПРД:
- каковы рекомендации в отношении использования ресурсов
(ограничиваются ли пользователи в чем-либо, и если это так,
то каковы эти ограничения);
- что может явиться злоупотреблением с точки зрения
производительности АС;
- разрешается ли нескольким пользователям использовать одно
регистрационное имя или позволять другим использовать их
имена;
- как "секретным" пользователям следует хранить свои пароли;
- как часто пользователям следует менять свои пароли, а также
любые другие ограничения или требования в отношении паролей;
- будете ли вы производить резервные копии, или пользователям
следует самим делать свои копии;
- запрет на разглашение информации, которая может являться
частной собственностью;
- пункт о безопасности электронной почты(Акт о конфиденциальности
электpонных коммуникаций);
- политика в отношении электронных коммуникаций:
фальсификация почты.
Ассоциация электpонной почты финансиpовала публикацию о
конфиденциальности электpонной почты в компаниях[4]. Их базовой
рекомендацией в отношении электронной почты является
то, что каждая организация должна иметь политику по защите
частной собственности своих служащих. Также рекомендуется, чтобы
организации установили политику в отношении частной собственности
при использовании всех сред передачи информации, а не только
электронной почты.
Предлагается пять критериев для оценки любой политики:
1) Согласуется ли политика с законами и требованиями
общественных организаций?
2) Пытается ли политика найти компромисс между интересами
служащих, руководства организации и общественных организаций?
3) Действует ли эта политика в жизни и требуют ли ее
соблюдения?
4) Касается ли эта политика различных форм взаимодействия и
хранения информации, имеющих место в организации?
5) Была ли эта политика известна заранее и согласована со
всеми заинтересованными лицами?
Существует компромисс между правами пользователя на
абсолютную частную собственность и необходимостью системным
администраторам собирать информацию, необходимую для выявления
причин возникновения проблемы. Также существует различие между
необходимостью системного администратора собирать информацию для
решения проблемы и исследованием причин нарушения защиты.
ПРД должны определять, в какой степени системные администраторы
могут исследовать пользовательские файлы для диагностики проблем
или других целей, и какие права вы гарантируете пользователям. Вы
можете также захотеть добавить утверждение относительно
обязательств системных администраторов по сохранению в тайне
информации, полученной ими при таких исследованиях. Для этого
надо ответить на несколько вопросов:
- может ли администратор наблюдать за состоянием файлов
пользователя или читать их по какой-либо причине?
- каковы при этом его обязательства?
- имеют ли право сетевые администраторы просматривать траффик
сети или СВТ?
Перед тем, как предоставить пользователям доступ к вашим
службам, вам нужно определить, на каком уровне вы обеспечиваете
секретность данных в вашей АС. Определив это, вы определите
уровень секретности данных, которые пользователи могут хранить в
вашей АС. Вы не должны позволять пользователям хранить очень
важную информацию в АС, которую вы не собираетесь делать очень
защищенной. Вам нужно сообщить пользователям, которые могут
хранить конфиденциальную информацию, о том, какие службы, если
они есть, более подходят для хранения конфиденциальной
информации. Эта часть должна включать хранение данных различными
способами (диски, магнитные ленты, файл-серверы и т.д.). Ваши ПРД
в этой области должны быть скоординированы с ПРД в отношении прав
системных администраторов (смотри раздел 2.3.6).
Понятно, что когда определен любой тип официальных ПРД,
независимо от того, связаны они с компьютерной секретностью или
нет, рано или поздно они будут нарушены. Нарушение может
произойти из-за нерадивости людей, случайной ошибки, неверной
информации о текущих ПРД, или их непонимания. Также вполне
возможно, что человек (или группа людей) специально совершат
действия, которые являются прямым нарушением ПРД.
При обнаружении нарушения ПРД действия, предпринимаемые сразу
же после нарушения, должны быть определены заранее, для того
чтобы быть уверенным в том, что будет сделано все, что
необходимо. Нужно провести расследование, чтобы выявить то, как
и почему произошло нарушение. Затем следует выполнить ряд
корректирующих действий. Что и в каком объеме нужно будет
сделать, зависит от типа произошедшего нарушения.
Нарушения ПРД могут совершаться самыми разными
пользователями. Некоторые из них могут быть местными
пользователями, а другие - людьми со стороны. Организация может
найти полезным определение того, кого считать "своим" и "чужим"
на базе административных или политических границ. Эти границы
косвенно определят, что нужно сделать для исправления ситуации;
от выговора до наложения штрафа. Поэтому вам надо не только
определить предпринимаемые шаги на основе типа нарушения, но
также иметь четко определенные последовательности действий для
каждого типа пользователя. Это может показаться слишком сложным,
но лучше сделать это заранее, чем второпях после нарушения.
Стоит запомнить один момент в отношении ваших ПРД -
правильное обучение является наилучшей защитой. Когда "чужие"
легально используют ваши СВТ, вы обязаны проверить, что они
ознакомлены с ПРД, которые вы установили. Эта информация может
пригодиться вам в будущем, когда понадобится применить уголовные
санкции.
Для пользователей, использующих ваши СВТ нелегально, проблема
по существу остается той же. Пользователь какого типа нарушил
ПРД, почему и как он это сделал? В зависимости от результатов
расследования вы можете просто заделать брешь в защите и занести
ее в вашу копилку опыта. Или, если в результате нарушения вы
потерпели большие убытки, вы можете сделать что-либо более
жесткое.
2.4.2 Что делать, когда ваши местные пользователи
нарушают ПРД другой организации?
В случае, когда местный пользователь нарушил ПРД другой
организации, ваша организация должна иметь четко определенный
набор административных действий, применяемых к этому
пользователю. Организация также должна быть готовой к защите
самой от возможных действий этой другой организации. Такие
ситуации приводят к проблемам, которые должны быть отражены при
разработке ПРД.
ПРД должны включать процедуры для взаимодействия со внешними
организациями. Они включают в себя пpавоохpанительные оpганы,
другие организации( напpимеp, CERT, CIAC), специальные
организации по противодействию промышленному шпионажу и агентства
печати. Эти процедуры должны устанавливать, кто имеет право
связываться с ними, как это надо делать. Заранее надо продумать
ответы на следующие вопросы:
- Кто может выступать перед прессой?
- Когда надо связываться с органами внутренних дел и
специальными организациями?
- Если инициатором такого контакта является другая
организация, уполномочен ли системный администратор участвовать в
такого рода контактах?
- Можно ли сообщать какие-либо данные? Какого рода?
Детальная информация о том, с кем связываться, должна быть
общедоступна вместе с четко определенными процедурами, которым
надо следовать.
Рабочая группа по политике секретности в IETF работает над
документом, имеющим название "Политические рекомендации по
безопасной работе в Интернете"[23]. Он связан с тем, что Интернет
это единое целое, и что организации должны оказывать друг другу
помощь. Это момент также следует отразить при разработке ПРД
организации. В основном нужно определить, какой объем информации
можно сообщать другим организациям. Он будет меняться от
организации к организации в зависимости от типа организации
(например, военная, образовательная, коммерческая), а также от
типа произошедшего нарушения секретности.
Помимо утверждений относительно политики разрабатываемый
документ должен включать процедуры улаживания конфликта. Они
детально описываются в следующей главе. Должны существовать
процедуры, применимые ко всем видам нарушения ПРД.
Всякий раз, когда в организации происходит инцидент, который
может скомпрометировать компьютерную безопасность, на стратегию
ответных действий могут повлиять два противоположных фактора.
Если управление организации боится, что она сильно уязвима,
то может применять стратегию "Защити и Работай". Основной целью
такого подхода является защита и сохранение служб организации
и как можно более быстрое их восстановление после нарушений для
пользователей. Будет производиться активное противодействие
злоумышленникам, защита от дальнейших попыток их доступа и
немедленное восстановление после разрушений. Этот процесс может
включать отключение служб, прекращение доступа к сети, или
другие жесткие меры. Недостатком является то, что если
злоумышленника не удалось установить, он может проникнуть в АС
другим путем или атаковать другую организацию.
Альтернативный подход, "Проследи и Накажи" исповедует другую
философию и цели. Основной целью является позволить
злоумышленникам продолжать свою деятельность в организации до тех
пор, пока организация не сможет установить, кто это такой. Этот
подход практикуется органами внутренних дел. Недостатком его
является то, что МВД не может защитить организацию от возможных
судебных процессов с пользователями из-за разрушений их АС и
данных.
Уголовная ответственность - не единственное возможное
наказание после определения злоумышленника. Если виновником
является служащий или студент, организация может использовать
административные наказания. В ПРД следует указать возможные
варианты наказаний, и какой из них выбрать после поимки
преступника.
Управление организацией должно проявить особую осторожность
при выборе подхода, который будет использоваться для решения
данной проблемы, и выбрать его до того, как произойдет нарушение.
Используемая стратегия может зависеть от ситуации. Или может быть
принята глобальная политика, которая регламентирует один подход
во всех случаях жизни. Следует тщательно взвесить все за и против
и довести принятую политику до пользователей, чтобы они знали
насколько они уязвимы, независимо от того, какой подход
используется.
Далее приводится условий, чтобы помочь организации
определить, какую стратегию избрать: "Защищай и Работай" или
"Проследи и Накажи".
Защищай и Работай
1) Если ценности не очень хорошо защищены
2) Если продолжение работы злоумышленника может привести к
большому финансовому риску
3) Если нет возможности наказать нарушителя в уголовном
порядке
4) Если местонахождение пользователей тяжело определить
5) Если пользователи неопытны и их работа уязвима
6) Если организация уязвима в отношении судебных процессов с
пользователями, например, если ее ресурсы невелики
Проследи и Накажи
1) Если ценности и системы хорошо защищены
2) Если имеются хорошие архивные копии
3) Если риск для ценностей перевешивается возможными
разрушениями в результате будущих проникновений
4) Если это большая атака, возникающая с большой частотой и
интенсивностью
5) Если организация привлекательна для злоумышленников, и
вследствие этого регулярно атакуется ими.
6) Если организация согласна подвергать ценности финансовому
риску в результате продолжающегося проникновения.
7) Если доступ злоумышленника контролируется
8) Если средства наблюдения так хорошо разработаны, что
делают слежение безопасным.
- 21 -
9) Если программисты организации настолько хорошо разбираются
в операционной системе, утилитах и системах, что слежение
становится безопасным
10) Если есть согласие части управления организации на
судебное преследование нарушителя
11) Если системные администраторы хорошо знают, что является
уликами для суда
12) Если есть контакт со знающими сотрудниками внутренних дел
13) Если есть человек в организации, разбирающийся в
связанных с этим вопросах законности
14) Если организация готова к судебным процессам с
пользователями, если их данные или системы будут
скомпрометированы в процессе слежки за злоумышленником
Важно определить, кто будет интерпретировать ПРД. Это может
быть человек или комитет. Независимо от того, насколько хорошо
они написаны, ПРД время от времени будут требовать интерпретации,
и это поможет впоследствии пересмотреть их при необходимости.
Как только ПРД организации выработаны и описаны, должен
начаться энергичный процесс их доведения, чтобы быть уверенным в
том, что их положения стали повсеместно известны и обсуждаются.
Недостаточно просто вывесить ПРД на доске объявлений. Нужно
разрешить в течение некоторого периода давать свои комментарии до
того, как ПРД начнут действовать, чтобы быть уверенным в том, что
все заинтересованные пользователи имели возможность высказать
свое мнение и пожелания. В идеале ПРД должны найти золотую
середину между защищенностью и производительностью.
Нужно провести несколько собраний, чтобы узнать все
замечания, а также удостовериться, что ПРД правильно поняты. (Те,
кто отвечает за публикацию ПРД, могут быть хорошими
специалистами, но не уметь писать документы). На этих собрания
должны присутствовать как верхнее звено управления организацией,
так и простые служащие. Защита - коллективное дело.
Помимо публикации ПРД перед их внедрением организации важно
поддерживать осведомленность служащих о ПРД. Текущим
пользователям надо периодически напоминать их положения. Новым
пользователям следует узнавать о ПРД при ознакомлении с
организацией. Было бы желательно, чтобы перед тем, как
использовать службы организации, пользователи бы давали подписку
о том, что они ознакомлены с ПРД и уяснили их. Если впоследствии
к этим пользователям необходимо будет применить санкции с точки
зрения закона, эта подписка может сыграть важную роль.
ПРД определяют, что требуется защищать. Эта часть
рассматривает СРД и специфицирующие шаги, которые нужно
предпринять для проведения в жизнь ПРД.
ПРД определяют: что нужно защищать, что является наиболее
важным, каковы приоритеты, и каким должен быть общий подход при
решении проблем защиты.
ПРД сами по себе не определяют, КАК защищать. Это - задача
СРД, которым и посвящен этот раздел. ПРД должны быть документом
концептуального уровня, описывающим общую стратегию. СРД же нужны
для того, чтобы детально описать, какие конкретные шаги должна
предпринять организация для собственной защиты.
ПРД должны включать анализ риска угроз, которым может
подвергаться организация, и последствия этих угроз (смотри раздел
2.2). Анализ риска должен включать общий список ценностей,
которые нужно защищать (раздел 2.2.2). Эта информация важна для
создания наиболее эффективной СРД.
Часто возникает соблазн начать создание СРД сразу с описания
механизмов: "наша организация должна зарегистрировать
пользователей компьютеров, модемов и смарт-карт". Это подход
может привести к тому, что некоторые области будут слишком
защищены, а некоторые недостаточно. Если же вы начали с создания
ПРД и описания в ней всех рисков, то можете быть уверенным, что
ваша СРД обеспечит нужную степень защиты для всех ценностей.
Чтобы определить риск, нужно выявить уязвимые места. Эта
часть ПРД должна помочь при их выявлении, и следовательно
уменьшить риск в как можно большем числе областей. Некоторые из
наиболее общих проблем приведены ниже. Этот список, естественно,
не полон. Кроме того, каждая организация, весьма вероятно, имеет
свои уникальные уязвимые места.
Точки вхождения обычно используются для входа
несанкционированными пользователями. Наличие большого числа точек
вхождения увеличивает риск доступа к СВТ и сетевым службам
право записи в них?
- можно ли нескольким пользователям использовать одно и то же
регистрационное имя и пароль?
Ответом на большинство этих вопросов будет "НЕТ".
Вы можете захотеть включить в ваши ПРД пункт, связанный с
программным обеспечением, защищенным авторскими правами или
лицензированным. Лицензионное соглашение с производителями может
потребовать некоторых усилий от вас для того чтобы гарантировать
отсутствие нарушений лицензии. Кроме того, вы можете захотеть
проинформировать пользователей, что копирование программ,
защищенных авторскими правами, является нарушением законов об
авторских правах и запрещено.
В отношении программного обеспечения, которое является
лицензионным или защищено авторскими правами, вы можете захотеть
включить в ПРД следующую информацию:
- какое лицензионное и защищенное авторскими правами
программное обеспечение не может копироваться за исключением
случая, когда явно сказано, что вы можете делать это;
- методы доведения информации о статусе разрешения
копирования программ;
- фразу "Когда у вас возникли сомнения, НЕ КОПИРУЙТЕ".
Ваши правила допустимого использования очень важны. ПРД,
которые явно не определяют, что запрещено, могут впоследствии не
позволить вам доказать, что пользователь нарушает ПРД.
Существуют исключения, такие как пользователи или
администраторы, желающие иметь "лицензию на хэккерство" - вы
можете столкнуться с ситуацией, когда пользователи захотят
исследовать ваши АС ради тестирования защищенности. Вы должны
разработать ПРД, которые будут определять, можно ли вам разрешать
такой тип исследований ваших сетевых служб и, если это так,
каковы рекомендации при проведении таких исследований.
Что вам следует отразить в этой части ПРД:
- можно ли это делать вообще;
- какой тип деятельности разрешен: доступ к информации,
запуск сетевых вирусов, запуск вирусов, и т.д.;
- какой контроль должен осуществляться при этом, чтобы
гарантировать, что ситуация не вышла из-под контроля (например,
выделить сегмент вашей сети для этих тестов);
- каким образом вы будете защищать остальных пользователей,
чтобы они не стали жертвами этих процессов, включая внешних
пользователей и сети;
- процесс получения разрешения на проведение этих тестов.
В тех случаях, когда вы разрешили проведение таких
исследований, вы должны изолировать тестируемую часть сети от
основной сети. Сетевые вирусы и просто вирусы никогда не должны
запускаться в реальной сети.
Вы можете также захотеть подрядить кого-либо для оценки
защищенности ваших АС, что может включать их исследование. Вы
можете захотеть отразить этот момент в ваших ПРД.
Ваши ПРД должны устанавливать, кто отвечает за предоставление
разрешения на доступ к вашим службам. Более того, должно быть
определено, какой тип доступа они могут предоставлять. Если вы не
контролируете, кто дает разрешение на доступ к вашим АС, вы не
контролируете, кто использует ваши АС. Контроль за тем, кто имеет
право давать доступ, позволит также вам узнать, кто имел или не
имел разрешение на доступ при последующих проблемах с защитой.
Существует много схем, которые можно использовать для
управления распределением доступа к вашим службам. Далее
приводятся факторы, которые вы должны учитывать при определении
того, кто распределяет доступ к вашим службам:
- Будете вы управлять предоставлением доступа из одного места
или дадите это право нескольким местам?
У вас может быть одно центральное место для предоставления
полномочий на доступ в распределенной системе, в которой
различные ведомства независимо отвечают за предоставление
полномочий на доступ. Нужен компромисс между защищенностью и
удобством. Чем более это процесс централизован, тем более он
защищен.
- Какие методы вы будете использовать для регистрации новых
пользователей и прекращения доступа?
С точки зрения безопасности вам нужно знать механизм, который
будет использован при регистрации новых пользователей. При самом
незащищенном варианте люди, которые отвечают за регистрацию
пользователей, могут просто войти в систему и создать нового
пользователя вручную или с помощью механизма, определенного
производителем. В общем случае эти механизмы доверяют человеку,
запускающему их, и человек, запускающий их, обычно имеет большие
привилегии. Если вы выбрали этот способ, вам нужно выбрать
кого-либо, кто не подведет вас при решении этой задачи. Другим
способом будет создание интегрированной системы, которая
запускается людьми, отвечающими за регистрацию, или самими
пользователями. Помните, что даже наличие самого защищенного
средства создания новых пользователей не избавляет вас от
возможности злоупотреблений им.
У вас должны быть разработаны специфические процедуры для
добавления новых пользователей в АС. Эти процедуры должны быть
хорошо документированы для предотвращения неоднозначных
толкований и уменьшения числа ошибок. Уязвимость защиты при
создании новых пользователей возникает не только из-за возможных
злоупотреблений, но также из-за возможных ошибок. Просто и хорошо
документированная процедура поможет быть уверенным, что ошибок не
будет. Вы также должны быть уверены, что люди, которые исполняют
эти процедуры, понимают вас.
Предоставление полномочий пользователю на доступ к АС - один
из самых уязвимых моментов. Вы должны быть уверены, что пароль,
выбранный вначале, не может быть легко угадан. Вы должны избегать
использования в качестве начального пароля слова, производного от
имени пользователя, являющегося частью имени пользователя, или
некоторого алгоритмически сгенерированного пароля, который может
быть легко угадан. Кроме того, вам не следует позволять
пользователям продолжать использовать начальный пароль
неопределенно долгое время. Если это возможно, вы должны
заставлять пользователей менять начальный пароль при первом
сеансе работы с АС. Учитывайте то, что некоторые пользователи
могут так никогда и не войти в АС, что делает их пароли уязвимыми
неопределенно долгое время. Некоторые организации приняли решение
удалять пользователей, которые никогда не пользовались АС, и
заставлять владельцев этих имен заново регистрироваться в списке
пользователей.
Одним из решений в области защиты, которое нужно принимать
очень тщательно, - это кто будет иметь привилегии системного
администратора и доступ к паролям ваших служб. Естественно, что
системные администраторы будут иметь такие права, но неизбежно и
другие пользователи будут просить специальных привилегий. Ваши
ПРД должны так или иначе решать эту проблему. Ограничение выдачи
привилегий - один из способов защиты от угроз, исходящих от
местных пользователей. Целью является компромисс между
ограничением доступа ради большей безопасности и предоставлением
привилегий тем людям, кому на самом деле нужны такие привилегии,
чтобы они могли решать свои задачи. Одним из подходов к решению
является предоставление только тех привилегий, которые необходимы
для выполнения своих задач пользователем.
Кроме того, люди, владеющие особыми привилегиями, должны быть
учтены специальным органом, и эта информация также должна
зафиксирована в ПРД организации. Если человек, которому вы
предоставили особые привилегии, не учтен сам по себе где-либо, вы
рискуете потерять контроль за вашей АС и у вас возникнут
трудности при управлении безопасностью.
Ваши ПРД должны включать пункты о правах и обязанностях
пользователей в отношении использования СВТ и сервисов
организации. Должно быть явно установлено, что пользователи
отвечают за понимание и соблюдение правил безопасности в АС,
которые они используют. Далее приводится список моментов, которые
вы можете захотеть зафиксировать в этой области ПРД:
- каковы рекомендации в отношении использования ресурсов
(ограничиваются ли пользователи в чем-либо, и если это так,
то каковы эти ограничения);
- что может явиться злоупотреблением с точки зрения
производительности АС;
- разрешается ли нескольким пользователям использовать одно
регистрационное имя или позволять другим использовать их
имена;
- как "секретным" пользователям следует хранить свои пароли;
- как часто пользователям следует менять свои пароли, а также
любые другие ограничения или требования в отношении паролей;
- будете ли вы производить резервные копии, или пользователям
следует самим делать свои копии;
- запрет на разглашение информации, которая может являться
частной собственностью;
- пункт о безопасности электронной почты(Акт о конфиденциальности
электpонных коммуникаций);
- политика в отношении электронных коммуникаций:
фальсификация почты.
Ассоциация электpонной почты финансиpовала публикацию о
конфиденциальности электpонной почты в компаниях[4]. Их базовой
рекомендацией в отношении электронной почты является
то, что каждая организация должна иметь политику по защите
частной собственности своих служащих. Также рекомендуется, чтобы
организации установили политику в отношении частной собственности
при использовании всех сред передачи информации, а не только
электронной почты.
Предлагается пять критериев для оценки любой политики:
1) Согласуется ли политика с законами и требованиями
общественных организаций?
2) Пытается ли политика найти компромисс между интересами
служащих, руководства организации и общественных организаций?
3) Действует ли эта политика в жизни и требуют ли ее
соблюдения?
4) Касается ли эта политика различных форм взаимодействия и
хранения информации, имеющих место в организации?
5) Была ли эта политика известна заранее и согласована со
всеми заинтересованными лицами?
Существует компромисс между правами пользователя на
абсолютную частную собственность и необходимостью системным
администраторам собирать информацию, необходимую для выявления
причин возникновения проблемы. Также существует различие между
необходимостью системного администратора собирать информацию для
решения проблемы и исследованием причин нарушения защиты.
ПРД должны определять, в какой степени системные администраторы
могут исследовать пользовательские файлы для диагностики проблем
или других целей, и какие права вы гарантируете пользователям. Вы
можете также захотеть добавить утверждение относительно
обязательств системных администраторов по сохранению в тайне
информации, полученной ими при таких исследованиях. Для этого
надо ответить на несколько вопросов:
- может ли администратор наблюдать за состоянием файлов
пользователя или читать их по какой-либо причине?
- каковы при этом его обязательства?
- имеют ли право сетевые администраторы просматривать траффик
сети или СВТ?
Перед тем, как предоставить пользователям доступ к вашим
службам, вам нужно определить, на каком уровне вы обеспечиваете
секретность данных в вашей АС. Определив это, вы определите
уровень секретности данных, которые пользователи могут хранить в
вашей АС. Вы не должны позволять пользователям хранить очень
важную информацию в АС, которую вы не собираетесь делать очень
защищенной. Вам нужно сообщить пользователям, которые могут
хранить конфиденциальную информацию, о том, какие службы, если
они есть, более подходят для хранения конфиденциальной
информации. Эта часть должна включать хранение данных различными
способами (диски, магнитные ленты, файл-серверы и т.д.). Ваши ПРД
в этой области должны быть скоординированы с ПРД в отношении прав
системных администраторов (смотри раздел 2.3.6).
Понятно, что когда определен любой тип официальных ПРД,
независимо от того, связаны они с компьютерной секретностью или
нет, рано или поздно они будут нарушены. Нарушение может
произойти из-за нерадивости людей, случайной ошибки, неверной
информации о текущих ПРД, или их непонимания. Также вполне
возможно, что человек (или группа людей) специально совершат
действия, которые являются прямым нарушением ПРД.
При обнаружении нарушения ПРД действия, предпринимаемые сразу
же после нарушения, должны быть определены заранее, для того
чтобы быть уверенным в том, что будет сделано все, что
необходимо. Нужно провести расследование, чтобы выявить то, как
и почему произошло нарушение. Затем следует выполнить ряд
корректирующих действий. Что и в каком объеме нужно будет
сделать, зависит от типа произошедшего нарушения.
Нарушения ПРД могут совершаться самыми разными
пользователями. Некоторые из них могут быть местными
пользователями, а другие - людьми со стороны. Организация может
найти полезным определение того, кого считать "своим" и "чужим"
на базе административных или политических границ. Эти границы
косвенно определят, что нужно сделать для исправления ситуации;
от выговора до наложения штрафа. Поэтому вам надо не только
определить предпринимаемые шаги на основе типа нарушения, но
также иметь четко определенные последовательности действий для
каждого типа пользователя. Это может показаться слишком сложным,
но лучше сделать это заранее, чем второпях после нарушения.
Стоит запомнить один момент в отношении ваших ПРД -
правильное обучение является наилучшей защитой. Когда "чужие"
легально используют ваши СВТ, вы обязаны проверить, что они
ознакомлены с ПРД, которые вы установили. Эта информация может
пригодиться вам в будущем, когда понадобится применить уголовные
санкции.
Для пользователей, использующих ваши СВТ нелегально, проблема
по существу остается той же. Пользователь какого типа нарушил
ПРД, почему и как он это сделал? В зависимости от результатов
расследования вы можете просто заделать брешь в защите и занести
ее в вашу копилку опыта. Или, если в результате нарушения вы
потерпели большие убытки, вы можете сделать что-либо более
жесткое.
2.4.2 Что делать, когда ваши местные пользователи
нарушают ПРД другой организации?
В случае, когда местный пользователь нарушил ПРД другой
организации, ваша организация должна иметь четко определенный
набор административных действий, применяемых к этому
пользователю. Организация также должна быть готовой к защите
самой от возможных действий этой другой организации. Такие
ситуации приводят к проблемам, которые должны быть отражены при
разработке ПРД.
ПРД должны включать процедуры для взаимодействия со внешними
организациями. Они включают в себя пpавоохpанительные оpганы,
другие организации( напpимеp, CERT, CIAC), специальные
организации по противодействию промышленному шпионажу и агентства
печати. Эти процедуры должны устанавливать, кто имеет право
связываться с ними, как это надо делать. Заранее надо продумать
ответы на следующие вопросы:
- Кто может выступать перед прессой?
- Когда надо связываться с органами внутренних дел и
специальными организациями?
- Если инициатором такого контакта является другая
организация, уполномочен ли системный администратор участвовать в
такого рода контактах?
- Можно ли сообщать какие-либо данные? Какого рода?
Детальная информация о том, с кем связываться, должна быть
общедоступна вместе с четко определенными процедурами, которым
надо следовать.
Рабочая группа по политике секретности в IETF работает над
документом, имеющим название "Политические рекомендации по
безопасной работе в Интернете"[23]. Он связан с тем, что Интернет
это единое целое, и что организации должны оказывать друг другу
помощь. Это момент также следует отразить при разработке ПРД
организации. В основном нужно определить, какой объем информации
можно сообщать другим организациям. Он будет меняться от
организации к организации в зависимости от типа организации
(например, военная, образовательная, коммерческая), а также от
типа произошедшего нарушения секретности.
Помимо утверждений относительно политики разрабатываемый
документ должен включать процедуры улаживания конфликта. Они
детально описываются в следующей главе. Должны существовать
процедуры, применимые ко всем видам нарушения ПРД.
Всякий раз, когда в организации происходит инцидент, который
может скомпрометировать компьютерную безопасность, на стратегию
ответных действий могут повлиять два противоположных фактора.
Если управление организации боится, что она сильно уязвима,
то может применять стратегию "Защити и Работай". Основной целью
такого подхода является защита и сохранение служб организации
и как можно более быстрое их восстановление после нарушений для
пользователей. Будет производиться активное противодействие
злоумышленникам, защита от дальнейших попыток их доступа и
немедленное восстановление после разрушений. Этот процесс может
включать отключение служб, прекращение доступа к сети, или
другие жесткие меры. Недостатком является то, что если
злоумышленника не удалось установить, он может проникнуть в АС
другим путем или атаковать другую организацию.
Альтернативный подход, "Проследи и Накажи" исповедует другую
философию и цели. Основной целью является позволить
злоумышленникам продолжать свою деятельность в организации до тех
пор, пока организация не сможет установить, кто это такой. Этот
подход практикуется органами внутренних дел. Недостатком его
является то, что МВД не может защитить организацию от возможных
судебных процессов с пользователями из-за разрушений их АС и
данных.
Уголовная ответственность - не единственное возможное
наказание после определения злоумышленника. Если виновником
является служащий или студент, организация может использовать
административные наказания. В ПРД следует указать возможные
варианты наказаний, и какой из них выбрать после поимки
преступника.
Управление организацией должно проявить особую осторожность
при выборе подхода, который будет использоваться для решения
данной проблемы, и выбрать его до того, как произойдет нарушение.
Используемая стратегия может зависеть от ситуации. Или может быть
принята глобальная политика, которая регламентирует один подход
во всех случаях жизни. Следует тщательно взвесить все за и против
и довести принятую политику до пользователей, чтобы они знали
насколько они уязвимы, независимо от того, какой подход
используется.
Далее приводится условий, чтобы помочь организации
определить, какую стратегию избрать: "Защищай и Работай" или
"Проследи и Накажи".
Защищай и Работай
1) Если ценности не очень хорошо защищены
2) Если продолжение работы злоумышленника может привести к
большому финансовому риску
3) Если нет возможности наказать нарушителя в уголовном
порядке
4) Если местонахождение пользователей тяжело определить
5) Если пользователи неопытны и их работа уязвима
6) Если организация уязвима в отношении судебных процессов с
пользователями, например, если ее ресурсы невелики
Проследи и Накажи
1) Если ценности и системы хорошо защищены
2) Если имеются хорошие архивные копии
3) Если риск для ценностей перевешивается возможными
разрушениями в результате будущих проникновений
4) Если это большая атака, возникающая с большой частотой и
интенсивностью
5) Если организация привлекательна для злоумышленников, и
вследствие этого регулярно атакуется ими.
6) Если организация согласна подвергать ценности финансовому
риску в результате продолжающегося проникновения.
7) Если доступ злоумышленника контролируется
8) Если средства наблюдения так хорошо разработаны, что
делают слежение безопасным.
- 21 -
9) Если программисты организации настолько хорошо разбираются
в операционной системе, утилитах и системах, что слежение
становится безопасным
10) Если есть согласие части управления организации на
судебное преследование нарушителя
11) Если системные администраторы хорошо знают, что является
уликами для суда
12) Если есть контакт со знающими сотрудниками внутренних дел
13) Если есть человек в организации, разбирающийся в
связанных с этим вопросах законности
14) Если организация готова к судебным процессам с
пользователями, если их данные или системы будут
скомпрометированы в процессе слежки за злоумышленником
Важно определить, кто будет интерпретировать ПРД. Это может
быть человек или комитет. Независимо от того, насколько хорошо
они написаны, ПРД время от времени будут требовать интерпретации,
и это поможет впоследствии пересмотреть их при необходимости.
Как только ПРД организации выработаны и описаны, должен
начаться энергичный процесс их доведения, чтобы быть уверенным в
том, что их положения стали повсеместно известны и обсуждаются.
Недостаточно просто вывесить ПРД на доске объявлений. Нужно
разрешить в течение некоторого периода давать свои комментарии до
того, как ПРД начнут действовать, чтобы быть уверенным в том, что
все заинтересованные пользователи имели возможность высказать
свое мнение и пожелания. В идеале ПРД должны найти золотую
середину между защищенностью и производительностью.
Нужно провести несколько собраний, чтобы узнать все
замечания, а также удостовериться, что ПРД правильно поняты. (Те,
кто отвечает за публикацию ПРД, могут быть хорошими
специалистами, но не уметь писать документы). На этих собрания
должны присутствовать как верхнее звено управления организацией,
так и простые служащие. Защита - коллективное дело.
Помимо публикации ПРД перед их внедрением организации важно
поддерживать осведомленность служащих о ПРД. Текущим
пользователям надо периодически напоминать их положения. Новым
пользователям следует узнавать о ПРД при ознакомлении с
организацией. Было бы желательно, чтобы перед тем, как
использовать службы организации, пользователи бы давали подписку
о том, что они ознакомлены с ПРД и уяснили их. Если впоследствии
к этим пользователям необходимо будет применить санкции с точки
зрения закона, эта подписка может сыграть важную роль.
ПРД определяют, что требуется защищать. Эта часть
рассматривает СРД и специфицирующие шаги, которые нужно
предпринять для проведения в жизнь ПРД.
ПРД определяют: что нужно защищать, что является наиболее
важным, каковы приоритеты, и каким должен быть общий подход при
решении проблем защиты.
ПРД сами по себе не определяют, КАК защищать. Это - задача
СРД, которым и посвящен этот раздел. ПРД должны быть документом
концептуального уровня, описывающим общую стратегию. СРД же нужны
для того, чтобы детально описать, какие конкретные шаги должна
предпринять организация для собственной защиты.
ПРД должны включать анализ риска угроз, которым может
подвергаться организация, и последствия этих угроз (смотри раздел
2.2). Анализ риска должен включать общий список ценностей,
которые нужно защищать (раздел 2.2.2). Эта информация важна для
создания наиболее эффективной СРД.
Часто возникает соблазн начать создание СРД сразу с описания
механизмов: "наша организация должна зарегистрировать
пользователей компьютеров, модемов и смарт-карт". Это подход
может привести к тому, что некоторые области будут слишком
защищены, а некоторые недостаточно. Если же вы начали с создания
ПРД и описания в ней всех рисков, то можете быть уверенным, что
ваша СРД обеспечит нужную степень защиты для всех ценностей.
Чтобы определить риск, нужно выявить уязвимые места. Эта
часть ПРД должна помочь при их выявлении, и следовательно
уменьшить риск в как можно большем числе областей. Некоторые из
наиболее общих проблем приведены ниже. Этот список, естественно,
не полон. Кроме того, каждая организация, весьма вероятно, имеет
свои уникальные уязвимые места.
Точки вхождения обычно используются для входа
несанкционированными пользователями. Наличие большого числа точек
вхождения увеличивает риск доступа к СВТ и сетевым службам